Connexion SSH impossible à travers box SFR - Page 1

[edit] Problème résolu, cf. bas du message

J'essaie de sauvegarder périodiquement les fichiers d'un serveur OVH vers un Synology hébergé chez moi, en utilisant le fort pratique soft de flanker, sachant que j'ai mon accès internet via SFR. Malheureusement j'essaie de faire ça en SSH et pour le moment ça coince.

- Le serveur OVH a une paire de clés SSH générées : ~/.ssh/id_rsa en 0600 et ~/.ssh/id_rsa.pub en 0644, dans ~/.ssh/ en 0711. J'arrive à me connecter vers d'autres serveurs à partir de lui, donc a priori pas de problème ici.
- Le serveur Synology a un compte destiné à recevoir les fichiers, pour lequel j'ai créé un ~/.ssh/authorized_keys en 0600 avec la clé du serveur OVH.
- Depuis mon poste chez moi, j'arrive bien à me connecter au serveur Synology depuis une adresse locale (sans sortir de mon réseau local) et la clé SSH est acceptée.
- J'ai configuré la box SFR pour rediriger un port externe (pas le 22) vers le port 22 du Synology
- Depuis le serveur OVH si j'essaie de me connecter sur le Synology, j'obtiens simplement une erreur "ssh_exchange_identification: read: Connection reset by peer".
- Le port semble correctement redirigé, puisque si j'annule ce réglage j'ai bien un timeout à la place (j'ai également essayé d'ouvrir le port 22 mais le résultat est le même)

Une connexion SSH avec -vvv ne m'apporte pas beaucoup plus d'informations :

$ ssh -vvv -p <mon_port> <moi>@<mon_adresse>
OpenSSH_7.2p2 Ubuntu-4ubuntu1, OpenSSL 1.0.2g-fips  1 Mar 2016
debug1: Reading configuration data /home/<moi>/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "<mon_adresse>" port <mon_port>
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to <mon_adresse> [<mon_ip>] port <mon_port>.
debug1: Connection established.
debug1: identity file /home/<moi>/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/<moi>/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu1
ssh_exchange_identification: read: Connection reset by peer

L'erreur "no such file or directory" m'étonne puisque le fichier existe, et qu'il arrive même à l'utiliser quand je me connecte à d'autres machines. Est-ce que vous avez une idée de ce que je peux essayer ensuite pour localiser le problème ?

Bon j'ai compris : Synology a décidé de bloquer l'IP de ce serveur il y a des mois, pour une raison qui m'échappe. Je n'ai pas du voir l'avertissement au moment où c'est arrivé (et je ne sais pas très bien pourquoi c'est arrivé d'ailleurs), mais visiblement leur système de blacklisting coupe la connexion de façon un peu brutale donc forcément je ne trouvais rien dans les logs SSH. Problème résolu

est-ce que tu peux utiliser le même poste pour te connecter depuis le LAN et depuis le WAN (par exemple avec un téléphone portable comme modem) ?


édit : bon, je n'avais pas lu la dernière phrase
donc, dans chaque Synology il y a une blacklist d'IP ?

Il y a une fonction de blocage automatique des IP.
Zeph, tu pourrais activer l'expiration des blocages pour éviter ce genre de problème.

Ah oui, bonne suggestion, j'active ça tout de suite

Ceci dit ce n'est pas vrai dans tous les cas, mais ce manger un reseted by peer a la tentative de connection est souvent signe d'un problème de firewall et c'est bizarre comme configuration de firewall parce que ca veux dire que celui-ci est pas configurer pour complètement bloquer l'accès a l'IP, mais que sur le tard (après les premiers paquets de SYNC, sinon tu aurais un "serveur non accessible", la le serveur commence a répondre avant de se rendre compte qu'en fait il ne veux pas te parler)

Le soucis est que tu indique clairement a l'attaquant que le serveur est la, mais ne veux pas te parler, la ou un drop direct fait passer le serveur pour mort:

Je viens de forcer un ban a la connection sur un de mes serveurs le resultat est le suivant:

Maya:~ godzil$ ssh -vvv foo@server
OpenSSH_7.2p2, LibreSSL 2.4.1
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug2: resolving "server" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to server [serverip] port 22.
debug1: connect to address serverip port 22: Connection refused
debug1: Connecting to server [serverip6] port 22.
debug1: connect to address serverip6 port 22: No route to hostssh: connect to host server port 22: No route to host

Surprenant de bloquer aussi tard la connection TCP dans ton cas

Oui, c'est pour ça que j'ai mis un moment à faire le lien avec le bloquage Synology, si la machine n'était tout simplement pas joignable ça ne m'aurait pas enduit d'erreur comme ça