Délai de connexion pour le serveur ssh

Cela signifie généralement que vous avez transféré le port vers la mauvaise adresse IP sur le LAN.

Votre routeur NAT reçoit le trafic entrant sur le port 57757 et l'envoie à une adresse IP et un port particuliers sur le LAN.

Par défaut, Ubuntu ne filtre pas les tentatives de connexion entrantes avec un pare-feu. Donc, à moins que vous n'ayez modifié les paramètres du pare-feu dans Ubuntu, une tentative d'ouverture de connexion à n'importe quel port TCP, 1 à 65535, soit:

accepter la connexion, si le port est ouvert
rejeter la tentative de connexion, si le port est fermé

Si les ports étaient filtrés par un pare-feu, vous obtiendriez ce que vous voyez - aucune réponse à une tentative de connexion. Mais:

sauf si vous avez modifié les paramètres du pare-feu (par exemple ufw, iptables), aucun port n'est filtré et
dans tous les cas, vous pouvez vous connecter au port 22 sur le LAN, il est donc ouvert.

Lorsque vous transférez un port vers une machine inexistante avec un routeur NAT, il envoie du trafic entrant sur ce port vers la machine inexistante, c'est-à-dire qu'il l'envoie dans un trou noir ; il est effectivement abandonné.

Cela provoque exactement la situation que vous avez décrite. Vous pouvez donc très probablement résoudre ce problème en vous assurant que le port est redirigé vers la bonne adresse IP sur le LAN.

S'il s'avère que cela n'a pas été le problème ...

... alors vous devrez faire un dépannage.

Le port spécifié pour le côté LAN est-il correct? Autrement dit, en supposant que vous n'avez pas modifié la configuration du serveur SSH, le port 57757 du côté WAN est-il configuré pour être transmis au port 22 sur le serveur OpenSSH? (Vous voudrez peut-être revérifier cela.)
Il y a peut-être un problème avec le port spécifique que vous avez choisi (57757). Essayez-en un autre et voyez si cela fonctionne mieux.

(Si ce n'est pas le cas et que vous suivez ces instructions, modifiez-le ou remplacez "57757" ci-dessous par le nouveau numéro.)
Essayez de redémarrer le serveur OpenSSH. Cela peut aider en cas de problème de réseau. Si cela ne vous aide pas, essayez de redémarrer le routeur et le modem câble / DSL / RNIS également.

Si, pour une raison quelconque, vous ne pouvez pas redémarrer les trois appareils, je vous recommande de redémarrer tout ce que vous pouvez. Si vous ne pouvez pas redémarrer le service OpenSSH, au moins vous pouvez redémarrer le service et (plus susceptibles de résoudre ce problème) prendre l'interface vers le bas et l'amener à nouveau.

Pour redémarrer le serveur OpenSSH:
```
sudo restart ssh
```
Pour mettre l'interface réseau vers le bas, première figure de quelle interface il est sur:
```
ifconfig
```
En règle générale, pour une machine avec une seule carte Ethernet et / ou une seule carte sans fil, Ethernet est eth0et le sans fil est wlan0.

Si la connexion Ethernet filaire est ce que vous voulez prendre et de redémarrer, exécutez:
```
sudo ifdown eth0
```
Exécutez ensuite:
```
sudo ifup eth0
```
Vous pouvez également exécuter:
```
sudo ifconfig eth0 down
```
Suivi par:
```
sudo ifconfig eth0 up
```
Si la machine utilise NetworkManager pour gérer l'interface sur laquelle le serveur OpenSSH s'exécute, je recommande toujours d'essayer les méthodes ci-dessus, mais vous pouvez également essayer de vous déconnecter et de vous reconnecter dans NetworkManager.

Pour une connexion Ethernet, essayez également de débrancher et de rebrancher le câble. Pour une connexion sans fil, essayez de le désactiver avec le commutateur matériel (s'il y en a un), puis de le rallumer.

Quelque chose d'étrange se passe ici et rien de tout cela ne prend beaucoup de temps - cela vaut la peine d'être approfondi avant d'entreprendre des étapes de dépannage plus minutieuses.
Comment essayez - vous d'y accéder à partir du WAN? Si vous utilisez une machine sur le réseau local pour le faire (juste la connexion du réseau local IP WAN de votre routeur), cela est uniquement pris en charge pour certains routeurs. Après tout, le travail d'un routeur est d'acheminer le trafic entre les côtés WAN et LAN, pas d'acheminer le trafic d'un côté à lui - même. Prise en charge de la connexion à des ports redirigés sur le WAN IP à l' intérieur du réseau local est en fait l'exception plutôt que la règle, bien que beaucoup de routeurs maison / bureau ont cette fonction.

Donc, si vous ne testez pas le port en avant à partir d'un hôte du côté WAN, vous devez le faire. Vos options pour cela sont:
- Connectez-vous du côté WAN. Cela fonctionne si vous avez accès à une machine là - bas, par exemple, un accès SSH à une machine distante à l' école, le travail, la maison d'un ami, ou similaire.
- Connectez la machine de test entre le routeur et tout fournit la connexion Internet. Si vous avez un câble / DSL / modem RNIS avec un port Ethernet et votre routeur est branché sur, vous pouvez connecter un commutateur au modem et connecter le routeur au commutateur. Connectez un ordinateur au commutateur. Tout d' abord voir si cette machine obtient juste un accès Internet - ces jours -ci , beaucoup de FAI fournissent deux ou plusieurs adresses IP distinctes. Si elle n'a pas , allez à la page de configuration de votre routeur et vérifiez son IP WAN et WAN masque sous - réseau , puis attribuez - lui statiquement une adresse IP à la machine connectée-commutateur qui se trouve dans le même sous - réseau.
  
  Cette méthode présente certains inconvénients. C'est une douleur! Aussi, il est théoriquement possible pour un fournisseur de services Internet pour configurer leur réseau de manière incorrecte afin que la machine de test connecté au commutateur peut accéder à Internet. ( À moins que c'est l'intention de votre fournisseur d' accès Internet pour vous permettre de vous connecter avec plus d'un IP WAN etil se trouve que vous avez choisi une IP WAN pour la machine de test que votre FAI vous a attribuée, le trafic entre celui-ci et un véritable hôte WAN doit être bloqué / abandonné par le FAI. Mais certains de FAI ont des pratiques étranges, alors qui sait?) Dans ce cas, il ne sera probablement pas quelqu'un de causer de sérieux problèmes (et même si elle l'a fait, il suffit qu'il connecté jusqu'à quelques minutes). Toutefois, il pourrait être considéré comme une tentative d'obtenir un accès supplémentaire au - delà des limites de votre abonnement, et - plus important encore - si un autre utilisateur a la même IP, il pourrait intefere avec leur connexion. Par conséquent, si vous voulez essayer cette méthode, Ne pas essayer d'accéder à Internet depuis la machine de test, arrêtez immédiatement si vous trouvez la machine de test peut accéder à Internet, et ne tentez pas du tout si elle est interdite ou déconseillée par votre fournisseur d'accès Internet. (Et ne pas utiliser cette option si le côté WAN de votre routeur est un bureau LAN, sans consulter votre administrateur réseau en premier. Ce n'est pas un fournisseur de services Internet et il n'y a aucune hypothèse que les ressources sont provisionnées à l'accès non souhaité éviter.)
  
  Il existe une variation sur cette technique qui est parfois plus appropriée. Votre routeur obtient probablement ses informations de connexion - adresse IP, masque de sous-réseau, l'adresse IP de la passerelle (routeur) sur le WAN qu'il utilise lorsqu'il ne sait pas où envoyer quelque chose et des informations sur les serveurs DNS - de votre FAI, via DHCP, via le modem câble / DSL / RNIS. C'est pourquoi vous devez avoir le routeur branché sur le modem pour lui donner la configuration nécessaire pour donner un sens aux résultats des tests côté WAN. Mais le routeur se souviendra généralement de ces informations, tant qu'il est effectivement connecté à un réseau du côté WAN. Vous pouvez donc connecter le routeur, le modem et la machine de test, mais ensuite, rapidement etavant de faire quoi que ce soit avec la machine de test, en plus de vous assurer que le commutateur le voit comme connecté , déconnectez le modem.
- Utilisez un service gratuit sur Internet pour tester vos ports. Étant donné que l'insertion d'une machine de test entre l'interface WAN de votre routeur et Internet (ci-dessus) est très impliquée - et comme il affichera un port comme accessible même s'il est inaccessible en raison du blocage de votre FAI (ce qui est également vrai pour la connexion à la IP WAN du routeur du côté LAN) - il est généralement préférable d'utiliser un service de numérisation de port basé sur le Web.
  
  Il existe de nombreux services d'analyse de port. (Certains arborent l'expression «vérifiez votre pare-feu» avec l'idée que la plupart des gens essaient de bloquer plutôt que de faciliter l' accès.) En voici un. Si vous choisissez de l'utiliser, cliquez sur Continuer , tapez 57757 dans la zone de texte, puis cliquez sur Utiliser la sonde de port personnalisée spécifiée . Pour faire fonctionner un serveur, vous voulez qu'il soit "ouvert". "Fermé" signifie que le port est accessible mais que le serveur ne fonctionne pas (et donc la tentative de connexion a été rejetée). "Furtif" signifie que le port était inaccessible - c'est comme si aucune machine ne s'y trouvait (ou comme si le port était transféré là où il n'y a pas de machine).
OK, vous avez donc déterminé que ce n'est vraiment pas accessible depuis Internet. Vous pouvez potentiellement le scanner (idéalement du côté WAN) pour obtenir des détails, bien que cela ne fournisse souvent pas d'informations utiles.

Si vous voulez le faire, du côté WAN, vous pouvez exécuter:
```
sudo nmap -sS -sV -p57757 -vv WAN-IP
```
Si le port est affiché comme filtré, cela confirme que les paquets envoyés là ne vont probablement nulle part (ou sont bloqués / abandonnés en cours de route).
Il convient de vérifier si le problème provient du fait que le port exposé au WAN est différent du port sur lequel le serveur écoute réellement. Le transfert du port 55757 sur le WAN vers le port 22 sur la machine LAN devrait bien fonctionner, mais quelque part (le serveur, le client) quelque chose suppose que le numéro de port est le même du point de vue du serveur et du client.

Vraisemblablement, vous ne pouvez pas transférer le port 22 via le routeur. Peut-être que votre FAI bloque ce port. Mais si vous pouvez le faire, faites-le!

Sinon, vous pouvez faire le serveur OpenSSH réellement écouter sur le port 57757.

Pour ce faire, sauvegardez le fichier de configuration du serveur:
```
cd /etc/ssh
sudo cp sshd_config sshd_config.old
```
Modifiez-le ensuite:
```
gksu gedit sshd_config
```
Ou utilisez un éditeur de texte de console si la machine n'a pas d'interface graphique:
```
sudo nano -w sshd_config
```
En haut du fichier, ce bloc de texte apparaît:
```
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
```
Il suffit de changer la Port 22ligne en haut, pour dire à la Port 57757place.
- Vous pouvez ajouter un port plutôt que de le changer. Je recommande cependant de tester avec la configuration efficace la plus simple.
  
  Voir man sshd_configpour plus de détails sur la configuration du serveur OpenSSH.
Enregistrez le fichier, quittez l'éditeur de texte et redémarrez le serveur SSH avec:
```
sudo restart ssh
```
Maintenant, changez le port en avant sur le routeur pour que le port 57757 en avant sur le port 57757 (pas 22) sur le serveur OpenSSH, et voyez s'il est accessible depuis Internet.
Si cela ne fonctionne toujours pas, voyez si le pare-feu d'Ubuntu bloque réellement le trafic provenant de l'extérieur du LAN.

(Il est peu probable si vous n'avez pas configuré de cette façon vous-même, mais si tous vos paramètres sont corrects et aucune des étapes ci-dessus a révélé quoi que ce soit au sujet du problème, il est la vérification vaut la peine.)

Courir:
```
sudo iptables -L
```
Par défaut, dans Ubuntu, les regards de sortie comme:
```
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
```
Il s'agit d'une simple politique permissive, essentiellement équivalente à l'absence de pare-feu. (En effet, si le module de pare-feu netfilter n'était pas compilé dans votre noyau, votre système se comporterait de la même manière qu'avec les paramètres ci-dessus, bien que la iptablescommande, qui interroge netfilterles paramètres de, ne fonctionnerait pas bien sûr.)

Si votre configuration ne ressemble pas à cela, lisez man iptablespour comprendre ce qu'ils font et / ou modifiez votre question (ou, si vous êtes une personne différente avec un problème similaire en lisant ceci, postez une nouvelle question) à inclure leur. Veuillez noter que, potentiellement, vos iptablesrègles pourraient divulguer des informations sensibles sur votre configuration. En pratique, ce n'est généralement pas le cas - à l'exception peut-être des règles concernant des hôtes spécifiques qui sont bloqués, ou si votre configuration est très mauvaise / non sécurisée - généralement l'utilité de ces informations pour un attaquant, en particulier pour une machine sur un réseau local à domicile / bureau derrière un routeur NAT , est minime.

Eliah Kagan
la source

Délai de connexion pour le serveur ssh

Réponses:

S'il s'avère que cela n'a pas été le problème ...