[SSH] Connection reset by peer

[lovepreacher]

Depuis quelques jours, il ne m'est plus possible de me connecter en SSH à mon serveur A que ce soit en local ou via Internet. J'ai 2 autres serveurs, B et C, avec une configuration quasi similaire. Je précise que tous les 3 appartiennent au même réseau. Malheureusement, je n'ai pas accès physiquement à A avant ce vendredi. Il y a une instance de minisatip sur chaque machine mais je n'arrive pas y accéder sur A, bien que l'instance soit toujours active.

code : Tout sélectionner

user@user-GF75-Thin-10UEK:~$ ssh -vvv user@serveur_A.com -p 11123
OpenSSH_8.2p1 Ubuntu-4ubuntu0.9, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug3: kex names ok: [ecdh-sha2-nistp521]
debug2: resolving "serveur_A.com" port 11123
debug2: ssh_connect_direct
debug1: Connecting to serveur_A.com [x.x.x.x] port 11123.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 0
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.9
kex_exchange_identification: read: Connection reset by peer

Si Mackguil me lit, docteur ès en expertise des tunnels SSH et consorts, aurais-tu une piste pour savoir atteindre mon serveur minisatip situé sur A ?

[rodrigue7973]

le port n'a pas la bonne

[Unix-Linux]

Connection Reset by peer signifie que TCP stream est anormalement fermé de l'autre coté.

Un TCP RST a été reçu et la connexion a été fermée.

La première chose à effectuer est un PING
Si pas de réponse de l'autre hote, deux possibilités : soit le serveur est fermé soit il y a un soucis de problème réseau, d'où le Packet Loss.

En console, essayer:

code : Tout sélectionner

nc -zv ip serveur A port

nc (Netcat) est un véritable couteau suisse !

[Mackguil]

Fail2ban, portsentry , Iptables un peu serrant, ou un truc du genre est-il installé sur la machine ?

B et C auraient-ils accès à la machine A ?

As-tu pensé à monter un tunnel reverse au boot pour te connecter en cas de soucis ?

Résultat du Netcat proposé par Unix-linux ?

Il serait bien aussi de t'envoyer les logs par mail ou sur un cloud journellement, afin de comprendre ce qu'il se passe.

[lovepreacher]

Fail2ban, portsentry , Iptables un peu serrant, ou un truc du genre est-il installé sur la machine ?

iptables est installé mais les règles utilisées ne sont pas restrictives

B et C auraient-ils accès à la machine A ?

Non, plus à l'heure actuelle

As-tu pensé à monter un tunnel reverse au boot pour te connecter en cas de soucis ?

J'avoue que j'ai négligé ce point et je m'en mords les doigts maintenant.

Résultat du Netcat proposé par Unix-linux ?

code : Tout sélectionner

Connection to serveur_A.com 11123 port [tcp/*] succeeded!

Il serait bien aussi de t'envoyer les logs par mail ou sur un cloud journellement, afin de comprendre ce qu'il se passe.

Merci pour le conseil avisé.

[Mackguil]

La première chose à faire quand tu auras accès à la machine, c'est de jeter un oeil dans /var/log histoire de comprendre ce qui c'est passé et de prendre les dispositions pour ne plus te retrouver dans la même situation.

Jette un oeil au fichier /etc/hosts.deny, c'est souvent très instructif.

Un iptables -L -n devrait aussi t'informer sur les ip bannies.

Je suppose que vu le résultat de NC, tu peux pinger la machine A à partir des serveurs B et C ?

Une prise connectée sur laquelle est branché le serveur permet aussi de reboot la machine à la hussarde (via wifi ou autre protocole réseau), mais il faut des sauvegardes régulières, car le système de fichier n'apprécie pas toujours.

[solar10]

Un server syslog sur un rpi 1 ou zero ce serait pas inutile.

[Mackguil]

Un server syslog sur un rpi 1 ou zero ce serait pas inutile.

Pas avec un OS sur carte SD alors, car c'est le premiers truc qui va planter.

[lovepreacher]

@ Mackguil, je vais patienter jusque ce vendredi et je suivrai tes recommandations. Je dois admettre que je suis une bille en matière de réseau mais bon je me soigne !

[Mackguil]

@ Mackguil, je vais patienter jusque ce vendredi et je suivrai tes recommandations. Je dois admettre que je suis une bille en matière de réseau mais bon je me soigne !

C'est le moment d'apprendre, il n'y a vraiment rien de compliqué.

Edit: Un script bacth déclenché via le cron toutes les 24H par exemple, ce script test le status du service sshd ou essaye une connexion sur sa propre adresse 127.0.0.1 au service ssh via son port, si problème la boucle du script redémarre le service via systemd ou service, c'est aussi un moyen efficace de se prémunir.

[lovepreacher]

Un énorme .

[Mackguil]

@ Mackguil, je vais patienter jusque ce vendredi et je suivrai tes recommandations. Je dois admettre que je suis une bille en matière de réseau mais bon je me soigne !

Si pas trop envie de te prendre la tête avec les tunnels reverse ssh, un proxy facile à installer et utiliser https://shadowsocks.org/

[lovepreacher]

Dans un premier temps, je vais tenter l'option via SSH et si cela s'avère au-delà du champ de mes compétences, je me rabattrai sur le proxy que tu m'as proposé.

[BelTNT]

tente de régénérer les clés du serveur ? (du genre ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key)

[Mackguil]

tente de régénérer les clés du serveur ? (du genre ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key)

Il doit avoir accès à la machine pour ça, il faut d’abord examiner les logs pour comprendre ce que c'est passé.

Ajouté après : 5 minutes 3 secondes:
C'est bien d’avoir des ports ssh ouverts sur le net, masi as tu pensé à installer un fail2ban pour protéger le trigu ?

[BelTNT]

tente de régénérer les clés du serveur ? (du genre ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key)

Il doit avoir accès à la machine pour ça, il faut d’abord examiner les logs pour comprendre ce que c'est passé.

Ajouté après : 5 minutes 3 secondes:
C'est bien d’avoir des ports ssh ouverts sur le net, masi as tu pensé à installer un fail2ban pour protéger le trigu ?

Tout bon administrateur système a toujours un accès OOB :)

[Mackguil]

Tout bon administrateur système a toujours un accès OOB :)

J'ai failli récupérer des switchs (mais only en 10/100) avec port rs232/ip chez un client, mais il s'en était débarrassé avant que je ne les reprenne.

[lovepreacher]

Petit retour sur mes pérégrinations; manque de pot pour moi, les fichiers journaux situés dans le dossier /var/log affichent des événements jusqu'au 12 août et puis plus rien. Après avoir consulté ceux-ci, il n'y avait aucun avertissement ou erreur permettant de trouver l'origine du problème. Heureusement, j'avais fait une sauvegarde du système sous forme d'une image disque et je l'ai restaurée. Clap de fin jusqu'à la prochaine fois...

[Mackguil]

/var/log/syslog mort aussi ?

[lovepreacher]

Oui. Il n'y avait aucun signe avant-coureur.