Délai de connexion pour le serveur Ssh ?

J'essaie de configurer openssh-server, mais j'ai des problèmes de connexion. J'ai changé le port en quelque chose de non standard (57757), puis j'ai configuré mon routeur pour qu'il transmette à ce port. Sur mon réseau local, je peux me connecter correctement en ssh à ma machine en utilisant le port 57757, mais je ne peux pas le faire 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, j'obtiens immédiatement un message "connexion refusée". Cependant, avec le bon port, il se bloque, puis expire.

Que puis-je essayer pour déboguer le problème ? J'ai essayé un traceroute, mais il ne m'a rien dit d'utile.

EDIT :J'ai réalisé que mon problème était que mon routeur ne prenait pas en charge l'accès par IP WAN en interne. Je me suis connecté en ssh à un autre serveur et je suis revenu et cela a bien fonctionné.

Réponse acceptée :

Cela signifie généralement que vous avez redirigé 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 et un port particuliers sur le LAN.

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 du pare-feu dans Ubuntu, une tentative d'ouverture d'une connexion à n'importe quel port TCP, de 1 à 65535, sera :

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

Si les ports ont été filtrés par un pare-feu, vous obtiendrez alors 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 redirigez un port vers un port inexistant machine avec un routeur NAT, il envoie le 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 transféré à la bonne adresse IP sur le réseau local.

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

… alors vous devrez faire du 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 côté WAN est-il configuré pour être transféré au port 22 sur le serveur OpenSSH ? (Vous voudrez peut-être vé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 s'il y a un problème de réseau. Si cela ne résout pas le problème, essayez également 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 appareils, 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 redémarrer le service et (plus susceptible de résoudre ce problème) supprimer l'interface et la réactiver.

Pour redémarrer le serveur OpenSSH :
```
sudo restart ssh
```
Pour désactiver l'interface réseau, déterminez d'abord sur quelle interface elle se trouve :
```
ifconfig
```
Typiquement, pour une machine avec une seule carte Ethernet et/ou une seule carte sans fil, l'Ethernet est eth0 et le sans fil est wlan0 .

Si la connexion Ethernet câblée est ce que vous voulez supprimer et redémarrer, exécutez :
```
sudo ifdown eth0
```
Exécutez ensuite :
```
sudo ifup eth0
```
Vous pouvez également exécuter :
```
sudo ifconfig eth0 down
```
Suivi de :
```
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 le câble et de le rebrancher. Pour une connexion sans fil, essayez de l'éteindre avec l'interrupteur 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 très longtemps - il vaut la peine d'être minutieux avant d'entreprendre des étapes de dépannage plus minutieuses.
Comment tentez-vous d'y accéder du côté WAN ? Si vous utilisez une machine sur le LAN pour ce faire (il suffit de se connecter du réseau local à l'adresse IP WAN de votre routeur), cela n'est pris 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é vers lui-même. La prise en charge de la connexion aux ports transférés sur l'IP WAN depuis l'intérieur du LAN est en fait l'exception plutôt que la règle, bien que de nombreux routeurs domestiques/bureaux disposent de cette fonctionnalité.

Donc, si vous ne testez pas le transfert de port depuis un hôte 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, au travail, chez un ami ou similaire.
- Connectez la machine de test entre le routeur et tout ce qui fournit son Connexion Internet. Si vous avez un modem câble/DSL/RNIS avec un port Ethernet et que votre routeur y est branché, vous pouvez connecter un commutateur au modem et connecter le routeur au commutateur. Connectez un ordinateur au commutateur. Premier voyez si cette machine obtient simplement un accès Internet - de nos jours, de nombreux FAI fournissent deux ou plusieurs adresses IP distinctes. Si ce n'est pas le cas , accédez à la page de configuration de votre routeur et vérifiez son adresse IP WAN et son masque de sous-réseau WAN, puis attribuez de manière statique une adresse IP à la machine connectée au commutateur qui se trouve dans le même sous-réseau.
  
  Cette méthode présente certains inconvénients. C'est une douleur ! De plus, il est théoriquement possible pour un FAI 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 c'est l'intention de votre FAI de vous permettre de vous connecter avec plus d'une IP WAN et vous avez choisi une adresse IP WAN pour la machine de test que votre FAI vous a attribuée, le trafic entre celle-ci et un véritable hôte WAN doit être bloqué/abandonné par le FAI. Mais certains FAI ont des pratiques étranges, alors qui sait ?) Si cela se produit, cela ne causera probablement aucun problème sérieux à personne (et même si c'était le cas, vous ne l'avez connecté que pendant quelques minutes). Cependant, cela pourrait potentiellement ê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 adresse IP, cela pourrait interférer avec sa 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 LAN de bureau, sans consulter d'abord votre administrateur réseau. Ce n'est pas un FAI et il n'y a aucune hypothèse que les ressources sont provisionnées pour empêcher tout accès indésirable.)
  
  Il existe une variante de cette technique qui est parfois plus appropriée. Votre routeur obtient probablement ses informations de connexion - adresse IP, masque de sous-réseau, adresse IP de la passerelle (routeur) sur le WAN qu'il il utilise quand 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 brancher 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 se souviendra généralement de ces informations, tant qu'il est réellement connecté à un réseau côté WAN. Ainsi, vous pouvez connecter le routeur, le modem et la machine de test, mais ensuite, rapidement et avant de faire quoi que ce soit avec la machine de test en plus de vous assurer que le commutateur le considère 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 complexe - et qu'elle affichera un port comme accessible même s'il est inaccessible en raison d'un blocage par votre FAI (ce qui est également vrai pour la connexion au routeur IP WAN du côté LAN) :il est généralement préférable d'utiliser un service d'analyse 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 accès.) C'en est un. Si vous choisissez d'utiliser celui-ci, cliquez sur Continuer , saisissez 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). "Stealth" signifie que le port était inaccessible - c'est comme si aucune machine n'y était localisée (ou comme si le port était redirigé là où il n'y a pas de machine).
OK, vous avez donc déterminé qu'il 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 donne souvent pas d'informations utiles.

Si vous voulez faire cela, alors 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 qui y sont envoyés ne vont probablement nulle part (ou sont bloqués/abandonnés en cours de route).
Il vaut la peine 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 faire en sorte que les choses fonctionnent bien, mais peut-être que 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.

Vous ne pouvez probablement 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 rendre le serveur OpenSSH en fait écouter sur le port 57757.

Pour cela, 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
```
Changez simplement le Port 22 ligne 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 efficace la plus simple.
  
  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
```
Modifiez maintenant la redirection de port sur le routeur afin que le port 57757 soit redirigé vers 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 réseau local.

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

Exécuter :
```
sudo iptables -L
```
Par défaut, dans Ubuntu, la sortie ressemble à :
```
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 permissive simple, 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 le module iptables commande, qui interroge netfilter s, ne fonctionnerait pas bien sûr.)

Si votre configuration ne ressemble pas à ça, lisez man iptables pour comprendre ce qu'ils font, et/ou modifiez votre question (ou, si vous êtes une autre personne avec un problème similaire à lire ceci, postez une nouvelle question) pour les inclure. Veuillez noter que, potentiellement, votre iptables rè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, surtout pour une machine sur un LAN domestique/bureau derrière un routeur NAT , est minime.

En relation:Problème NVidia GeForce GTX970 Ubuntu 16.04?