Tunnel sur SSH


1

J'ai un serveur VPS exécutant CentOS 6.5 et un client exécutant également CentOS 6.5.

J'essaie d'établir une connexion de tunnel sur le protocole SSH.

J'utilise l'option -v pour déboguer, je ne trouve aucun problème mais je ne peux pas créer de tunnel. Merci également de me faire savoir si vous rencontrez un problème de sécurité dans le débogage.

ssh -vfN pmcode@198.23.xxx.xxx -p 3032 -L 8182:127.0.0.1:22

[root@localhost ~]# ssh -vfN pmcode@198.23.xxx.xxx -p 3032 -L 8182:127.0.0.1:22
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 198.23.xxx.xxx [198.23.xxx.xxx] port 3032.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '[198.23.xxx.xxx]:3032' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
pmcode@198.23.xxx.xxx's password: 
debug1: Authentication succeeded (password).
debug1: Local connections to LOCALHOST:8182 forwarded to remote address 127.0.0.1:22
debug1: Local forwarding listening on ::1 port 8182.
bind: Address already in use
debug1: Local forwarding listening on 127.0.0.1 port 8182.
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 8182
Could not request local forwarding.
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.

Réponses:


2
debug1: Local forwarding listening on ::1 port 8182. 
bind: Address already in use
debug1: Local forwarding listening on 127.0.0.1 port 8182.
bind: Address already in use

Cela signifie que vous avez déjà un processus lié au port 8182 sur le bouclage local.

Probablement l'un de vos autres essais. Lis

$ man netstat

pour l'une des façons de savoir quel processus est le coupable.

Si vous souhaitez lier plusieurs tunnels à la boucle locale, vous pouvez vous lier à d'autres numéros de port ou à d'autres adresses IP. Comme lodevrait avoir un masque de réseau de 255.0.0.0toute adresse commençant par 127.fonctionnera.

$ ssh -vfN pmcode@192.0.2.245 -p 3032 -L 127.0.0.2:8182:127.0.0.1:22

Merci également de me faire savoir si vous rencontrez un problème de sécurité dans le débogage.

Eh bien, ce n’est pas un problème pour votre ssh, mais vous avez lié votre OpenSSH à un OpenSSL vulnérable à heartbleed (OpenSSL 1.0.1e-fips). Si vous avez lié d'autres programmes qui font utiliser la mise en œuvre du protocole TLS, il peut être conseillé de patcher et de renouveler votre matériel clé.


Il n'y a pas d'autre programme pour écouter le port, juste SSH, mais chaque fois que je change le port pour un nouveau qui n'est pas à l'écoute (j'ai utilisé `netstat -tulpn`), veuillez remplacer IP par" xxx "-
Hamidreza

1
@ hamidreza66 n'hésitez pas à éditer, mais veuillez suivre RFC5737 au lieu de "xxx" lorsque vous utilisez des exemples d'adresses IP.
Chris Wesseling
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.