Délai de connexion au serveur ssh

Question

J'essaie de configurer openssh-server, mais j'ai des problèmes de connexion. J'ai remplacé le port par un élément non standard (57757), puis j'ai configuré mon routeur pour qu'il envoie à ce port. Sur mon réseau local, je suis en mesure d’effectuer une ssh sur ma machine en utilisant le port 57757, mais pas sur le réseau étendu.

Si je suis en dehors du réseau local et que j'essaie d'accéder à ma machine par un port incorrect, je reçois immédiatement un message "connexion refusée". Cependant, avec le port correct, il se bloque, puis des délais d'attente.

Que puis-je essayer de résoudre le problème? J'ai essayé un traceroute, mais cela ne m'a rien dit d'utile.

EDIT: J'ai réalisé que mon problème était que mon routeur ne permettait pas d'y accéder par WAN IP en interne. Je ssh'd à un serveur différent et en arrière et cela a bien fonctionné.

Eliah Kagan · Accepted Answer

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

Votre routeur NAT reçoit le trafic entrant sur le port 57757 et l’envoie à une adresse IP particulière et à un port du réseau local.

Par défaut, Ubuntu ne filtre pas les tentatives de connexion entrantes avec un pare-feu. Ainsi, à moins que vous n'ayez modifié les paramètres de pare-feu dans Ubuntu, une tentative d'ouverture de connexion à un port TCP, compris entre 1 et 65535, aura les effets suivants:

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

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

à moins que vous n'ayez 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 du réseau local, il est donc ouvert.

Lorsque vous transférez un port à un ordinateur inexistant avec un routeur NAT, il envoie le trafic entrant sur ce port à l'ordinateur non existant, ce qui signifie l'envoie dans un trou noir ; il est effectivement largué.

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

Si cela s'avère ne pas avoir été le problème ...

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

Le port spécifié pour le côté réseau local est-il correct? Autrement dit, si vous n’avez pas modifié la configuration du serveur SSH, le port 57757 du côté WAN est-il configuré pour le transfert vers le port 22 du serveur OpenSSH? (Vous voudrez peut-être vérifier cette information.)
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" par le nouveau numéro.)
Essayez de redémarrer le serveur OpenSSH. Cela peut aider s’il ya un problème de réseau. Si cela ne vous aide pas, essayez de redémarrer le routeur et le modem câble/DSL/RNIS.

Si, pour une raison quelconque, vous ne pouvez pas redémarrer les trois périphériques, je vous recommande de redémarrer tout ce que vous pouvez. Si vous ne pouvez pas redémarrer le service OpenSSH, vous pouvez au moins le redémarrer et (plus que probablement pour y remédier) démonter l'interface et la réactiver.

Pour redémarrer le serveur OpenSSH:
```
Sudo restart ssh 
```
Pour mettre l’interface réseau hors service, déterminez d’abord son interface:
```
ifconfig 
```
En règle générale, pour un ordinateur doté d'une seule carte Ethernet et/ou d'une seule carte sans fil, Ethernet est eth0 et le sans fil est wlan0.

Si vous souhaitez interrompre et redémarrer la connexion Ethernet filaire, exécutez:
```
Sudo ifdown eth0 
```
Puis lancez:
```
Sudo ifup eth0 
```
Alternativement, vous pouvez 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 est exécuté, je vous recommande néanmoins 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 le câble, puis de le rebrancher. Pour une connexion sans fil, essayez de l'éteindre à l'aide du commutateur matériel (le cas échéant), puis de le rallumer.

Quelque chose d'étrange se passe ici et rien de tout cela ne prend très longtemps - il vaut la peine d'être approfondi avant d'entreprendre des étapes de dépannage plus laborieuses.
Comment essayez-vous d'y accéder depuis le côté WAN? Si vous utilisez une machine sur le réseau local pour le faire (connectez-vous simplement du réseau local à l'adresse WAN de votre routeur), cette option n'est prise en charge que pour certains. routeurs. Après tout, le travail d'un routeur consiste à acheminer le trafic entre les côtés WAN et LAN, et non à acheminer le trafic d'un côté à lui-même. La prise en charge de la connexion aux ports transférés sur le WAN IP depuis le réseau local constitue l’exception plutôt que la règle, bien que de nombreux routeurs domestiques/de bureau disposent de cette fonctionnalité.

Donc, si vous ne testez pas le transfert de port à partir d'un hôte du côté WAN, vous devriez le faire. Vos options pour cela sont:
- Connectez-vous à partir du côté WAN. Cela fonctionne si vous avez accès à une machine, par exemple, l'accès SSH à une machine distante à l'école, au travail, la maison d'un ami, ou similaire.
- Connectez la machine de test entre le routeur et tout ce qui fournit sa connexion Internet . Si vous avez un modem câble/DSL/RNIS avec un port Ethernet et votre routeur y est branché, vous pouvez connecter un commutateur au modem et connecter le routeur au commutateur. Connectez un ordinateur au commutateur. D'abord voir si cette machine obtient seulement un accès Internet - de nos jours, de nombreux FAI fournissent deux adresses IP distinctes ou plus. Si ce n'est pas le cas , accédez à la page de configuration de votre routeur et vérifiez son WAN IP et masque de sous-réseau WAN , puis attribuez une adresse IP de manière statique. adresse à la machine connectée au commutateur qui se trouve dans le même sous-réseau.
  
  Cette méthode présente des inconvénients. C'est pénible! En outre, il est théoriquement possible pour un fournisseur de services Internet de configurer son réseau de manière incorrecte afin que la machine de test connectée au commutateur puisse accéder à Internet. (Sauf si votre fournisseur de services Internet a l'intention de vous permettre de vous connecter avec plus d'une WAN IP et vous avez choisi une adresse IP WAN pour la machine de test que votre FAI vous a assignée, le trafic entre elle et un véritable WAN hôte doit être bloqué/abandonné par le FAI, mais certains FAI ont des pratiques étranges, alors qui sait?) Si cela se produit, cela ne posera probablement pas de problèmes sérieux à quiconque (et même si c'est le cas, vous ne l'avez connecté que pendant quelques minutes). Cependant, cela pourrait potentiellement être perçu 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 dispose de la même adresse IP, cela pourrait perturber leur connexion. Par conséquent, si vous voulez essayer cette méthode , n'essayez pas d'accéder à Internet à partir de la machine de test, arrêtez-vous immédiatement si vous trouvez que la machine de test peut accéder à Internet et N'essayez pas du tout si cela est interdit ou déconseillé par votre FAI. (Et ne l'utilisez pas si le côté WAN de votre routeur est un réseau local de bureau, sans consulter au préalable votre administrateur réseau. Ce n'est pas un fournisseur de services Internet et il n'y a aucune hypothèse selon laquelle des ressources sont provisionnées pour empêcher un accès indésirable.)
  
  Il existe une variante de cette technique qui est parfois plus appropriée. Votre routeur reçoit probablement ses informations de connexion - adresse IP, masque de sous-réseau, adresse IP de la passerelle (routeur) sur le WAN que it utilise 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 connecter le routeur au modem pour lui donner la configuration nécessaire pour que les résultats des tests côté WAN soient significatifs. Mais le routeur retient généralement ces informations, tant qu'il est réellement connecté à un réseau du côté WAN. Vous pouvez donc connecter le routeur, modem , et testez la machine, mais rapidement, et avant 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. Depuis l'insertion d'une machine de test entre l'interface WAN de votre routeur et Internet (ci-dessus) est fortement impliquée - -et puisqu’il montrera 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 à l’IP WAN du routeur du côté réseau local) - il est généralement préférable de utiliser un service d'analyse de port basé sur le Web.
  
  Il existe de nombreux services d'analyse de port. (Certains utilisent l'expression "vérifiez votre pare-feu" avec l'idée que la plupart des gens essaient de block plutôt que facilit accès.) Ceci est un. Si vous choisissez d'utiliser celui-ci, cliquez sur Proceed , tapez 57757 dans la zone de texte, puis cliquez sur Utiliser Sonde de port personnalisée spécifiée . Pour faire fonctionner un serveur, vous voulez il doit être "ouvert". "Fermé" signifie que le port est accessible mais que le serveur n'est pas en cours d'exécution (la tentative de connexion a donc été rejetée). "Furtif" signifie que le port était inaccessible - c'est comme si aucune machine n'y était située (ou comme si le port avait été transféré là où il n'y avait pas de machine).
D'accord, vous avez donc déterminé qu'il n'était vraiment pas accessible depuis Internet. Potentiellement, vous pouvez le scanner (idéalement du côté WAN) pour obtenir des détails, bien que cela ne donne souvent pas d'informations utiles.

Si vous voulez faire cela, alors 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à-bas ne vont probablement nulle part (ou sont bloqués/abandonnés en cours de route).
Il est utile de vérifier si le problème provient du port exposé au fait que le 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 de la machine du réseau local devrait rendre les choses simples, mais peut-être que quelque part (le serveur, le client) suppose que le numéro de port est le même du serveur et du client la perspective.

Vous ne pouvez probablement pas transférer le port 22 via le routeur. Peut-être que votre fournisseur d'accès bloque ce port. Mais si tu peux faire ça, fais ça!

Sinon, vous pouvez faire en sorte que le serveur OpenSSH en fait sur le port 57757.

Pour ce faire, sauvegardez le fichier de configuration du serveur:
```
cd /etc/ssh Sudo cp sshd_config sshd_config.old 
```
Puis éditez-le:
```
gksu gedit sshd_config 
```
Ou utilisez un éditeur de texte de la console si la machine ne dispose 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 ligne Port 22 en haut pour dire Port 57757 à la place.
- Vous pourriez ajouter un port plutôt que de le changer. Je recommande cependant de tester avec la configuration la plus simple et efficace.
  
  Voir man sshd_config pour 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 forward sur le routeur afin que le port 57757 soit transféré sur le port 57757 (et non 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 effectivement le trafic provenant de l'extérieur du réseau local.

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

Courir:
```
Sudo iptables -L 
```
Par défaut, dans Ubuntu, le résultat est le suivant:
```
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 politique simple et permissive, qui équivaut essentiellement à ne pas utiliser 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 que les paramètres ci-dessus, bien que la commande iptables, qui interroge les paramètres de netfilter, ne fonctionne pas, bien sûr.)

Si votre configuration ne ressemble pas à celle-ci, lisez man iptables pour comprendre ce qu’elles font, et/ou modifiez votre question (ou, si vous êtes une personne différente avec un problème similaire, lisez ceci.) , postez une nouvelle question) pour les inclure. Veuillez noter que vos règles iptables pourraient éventuellement divulguer des informations sensibles sur votre configuration. En pratique, ce n’est généralement pas le cas - à l’exception possible des règles relatives à des hôtes spécifiques bloqués, ou si votre configuration est très mauvaise/précaire - à l’utilité de ces informations pour un attaquant, spécialement pour une machine sur un réseau domestique/de bureau derrière un NAT routeur , est minime.

guntbert · Answer

Comme cela fonctionne depuis votre réseau local, votre configuration du serveur semble être correcte. Vous devez dire à votre routeur de transférer depuis le port que vous voulez utiliser sur le extérieur vers le port 57757 sur votre machine.
Un traceroute ne sera d'aucune utilité dans ce cas.