sshd ne répond pas à la request de connection transmise par le port

Je configure le renvoi de port sur un routeur SonicWall NSA 220, pour le port 22. Il semble que le routeur transfère les packages TCP comme il se doit. Cependant, Wireshark s'exécutant sur le server montre que le sshd de mon server ignore ces requêtes de connection ssh et ne répond pas: il ne tente même pas d'envoyer des packages.

Je peux ssh directement sur le server via la même interface ethernet (d'un autre système sur le réseau local). Ce ne sont que les packages transférés du côté WAN qui ne reçoivent aucune réponse.

Il semble donc que le coupable soit sshd: pour une raison quelconque, il ignore les packages transférés.

Le server exécute RHEL 6. Le pare-feu est désactivé.

Toute idée pourquoi sshd ignore les requests de connection transmises? Ou le routeur est-il responsable?

Voici la sortie tcpdump (j'utilise le port 30002 ici, mais c'est le même que le port 22). L'adresse IP du server est 192.168.8.33.

08:52:12.350492 IP 192.168.1.32.52205 > 192.168.8.33.30002: Flags [S], seq 2460054041, win 14600, options [mss 1460,sackOK,TS val 453857378 ecr 0,nop,wscale 6], length 0 08:52:13.347513 IP 192.168.1.32.52205 > 192.168.8.33.30002: Flags [S], seq 2460054041, win 14600, options [mss 1460,sackOK,TS val 453857628 ecr 0,nop,wscale 6], length 0 08:52:15.351529 IP 192.168.1.32.52205 > 192.168.8.33.30002: Flags [S], seq 2460054041, win 14600, options [mss 1460,sackOK,TS val 453858129 ecr 0,nop,wscale 6], length 0 08:52:19.363565 IP 192.168.1.32.52205 > 192.168.8.33.30002: Flags [S], seq 2460054041, win 14600, options [mss 1460,sackOK,TS val 453859132 ecr 0,nop,wscale 6], length 0 

Voici la sortie tcpdump lorsque I ssh du LAN, qui est réussi:

 08:50:41.844945 IP 192.168.8.253.55442 > 192.168.8.33.30002: Flags [S], seq 2514711830, win 14600, options [mss 1460,sackOK,TS val 4294948065 ecr 0,nop,wscale 6], length 0 08:50:41.844983 IP 192.168.8.33.30002 > 192.168.8.253.55442: Flags [S.], seq 2291827547, ack 2514711831, win 14480, options [mss 1460,sackOK,TS val 6807100 ecr 4294948065,nop,wscale 7], length 0 08:50:41.845290 IP 192.168.8.253.55442 > 192.168.8.33.30002: Flags [.], ack 1, win 229, options [nop,nop,TS val 4294948065 ecr 6807100], length 0 etc.... 

Voici mon sshd_config sur le server:

 sudo grep ^[^'#'] /etc/ssh/sshd_config Port 22 Port 30002 Protocol 2 SyslogFacility AUTHPRIV PasswordAuthentication yes ChallengeResponseAuthentication no GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE AcceptEnv XMODIFIERS X11Forwarding yes Subsystem sftp /usr/libexec/openssh/sftp-server 

Voici iptables:

 sudo iptables -L -n -v Chain INPUT (policy ACCEPT 5350 packets, 314K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 2121 packets, 14M bytes) pkts bytes target prot opt in out source destination 

One Solution collect form web for “sshd ne répond pas à la request de connection transmise par le port”

Je l'ai enfin réussi. J'ai oublié que mon server possède deux interfaces réseau et que les deux étaient connectés: un au réseau LAN du routeur et un au réseau WAN.

Pour expliquer: le WAN du routeur est 192.168.8. *. Le LAN du routeur est 192.168.1. *. Le server est 192.168.8.32, et le client est 192.168.1.33.

Lorsque j'ai déconnecté le server du réseau WAN du routeur, tout d'un coup, tout a fonctionné. Je pense que RHEL sur le server doit avoir été confondue par les deux voies avec le client 192.168.1.33.

  • Impossible d'exécuter SSH ou d'envoyer des commands à /etc/init.d/ssh
  • L'ouverture de la key SSH ne fonctionne pas
  • Quel est le nombre maximal de keys privées que vous pouvez utiliser via SSH Agent (Pageant)
  • Journal de transfert SFTP simple
  • Comment vous connecter à votre server avec une session SSH?
  • tunneling 2 ssh
  • Un location central pour authorized_keys est-il une bonne idée?
  • Accès SSH sans ouvrir les ports de pare-feu
  • Sécurisation de NFS contre le tunneling SSH
  • Pourquoi mes shells à distance me parlent en italien?
  • ssh entrez la phrase de passe une ligne
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.