Problème grave avec SSH/SFTP et PubkeyAuthentication : plus possible d’accéder à mes sites

WRInaute passionné
Je suis sous Ubuntu 12.04, le cas se présente avec l’hébergeur 1&1.

J’ai voulu mettre en place une authentification par clé publique pour l’accès SSH et SFTP, afin de ne pas avoir à ressaisir le mot de passe trop souvent en ligne de commande. La “passphrase” est plus longue, mais ne doit être entrée qu’une fois, au moins une fois par sessions Ubuntu, normalement.

À la racine du serveur j’ai créé un dossier `.ssh` contenant un fichier `authorized_keys` contenant la clé publique `ssh-rsa xx…xx xyzl@yyz.xyz`

J’ai le même fichier sur le machine locale, sous `~/.ssh/authorized_keys`

Quand j’ouvre le répertoire via Nautilus, celui‑ci me demande la “passphrase”, et ça fonctionne.

Si je fais ceci depuis une ligne de commande : `sftp -o PubkeyAuthentication=yes xxxxxxxx@xxxxxxxxxx.xxxxxxxxxx.fr` il me demande un mot de passe, alors que normalement il ne devrait plus, puisque je l’ai déjà donné à Nautilus et que je ne devrais plus avoir besoin de le redonner pendant au moins toute la session Ubuntu.

Je donne quand‑même la “passphrase”, et ça ne marche pas. Je donne le mot de passe normal SSH de 1&1, ça ne marche pas non‑plus.

Je retente alors d’ouvrir le dossier depuis Nautilus, mais il me dit que l’accès est refusé, j’imagine, suite au deux tentatives précédentes ayant échoué en ligne de commande (alors que la connexion avec Nautilus quelques minutes auparavant, a fonctionné).

Ce qui se produit alors est grave : non seulement je ne peux plus accéder à mon répertoire sur le serveur, mais en plus je ne peux même plus accéder à mes sites, et même le `ping` ne répond plus.

Je ne pensais pas qu’un échec de connexion SFTP pouvait avoir une telle conséquence, pas plus que je ne comprend pourquoi la connexion fonctionne depuis Nautilus et pas depuis la ligne de commande avec la commande `sftp`. Le serveur me prend‑t‑il pour un pirate et bloque‑t‑il mon IP ?

Qu’est‑ce qui me fait penser qu’il y a une relation entre l’impossibilité d’accéder à mes sites et cette histoire ? C’est qu’il m’est arrivé la même chose il y a deux heures. Je croyais que le serveur 1&1 était KO, mais je constate que le compteur de visite de AdSense continue d’augmenter, ce qui indique que les sites sont accessibles pour le reste du monde (ou du pays, cheese). Après avoir attendu environ 1h ou 2h, ça fonctionnait à nouveau, je pouvais à nouveau faire un ping, avoir un accès au site… jusqu’à ce que je retente la commande `sftp` pour constater son échec et immédiatement après, l’impossibilité pour moi d’accéder aux sites, même sans SFTP (même le ping échoue !).

Pourquoi la connexion ne fonctionne‑t‑elle ? Et surtout, comment expliquer une telle conséquence à l’échec de la connexion ? Ou n’y‑a‑t‑il juste aucune relation entre les deux et ce serait juste une coïncidence ? Mais alors comment expliquer que les sites semblent rester accessibles pour les autres et que moi je ne peux plus y accéder ?
 
WRInaute passionné
Je viens d’essayer, ça fonctionne parfaitement bien avec Alwaysdata, c’est KO seulement avec 1&1.

Après que GNOME m’ai demandé “Enter password to unlock the private key” (il dit password, mais c’est en fait une passphrase), je peux me connecter en SFTP à deux serveurs Alwaysdata, sans redonner de mot de passe, mais avec 1&1, j’ai ce message : “ssh: connect to host xxxxxxxxxx.xxxxxxxxxx.fr port 22: Connection refused
Couldn't read packet: Connection reset by peer
”. Et le ping qui échoue me dit “From kundenserver.de (xx.xxx.xx.xx) icmp_seq=1 Destination Port Unreachable”.

Il est bizarre le serveur de 1&1… c’est pourtant le même dossier `.ssh` contenant le même fichier `authorized_keys` et pas de problème avec Alwaysdata.

-- edit --

H.S., mais pourquoi mon avatar a disparu ?
 
WRInaute passionné
Suite de l’étrange aventure.

Je disais que l’accès était revenu après un délais. Mais j’ai oublié de dire que entre temps j’avais éteint le PC et la box avant de rallumer le tout, l’extinction étant pour changer d’IP.

Après le deuxième cas, j’ai retenté la même chose, et après le changement d’IP, l’accès fonctionne à nouveau.

Il semble alors que c’est effectivement l’IP qui est bloquée par 1&1 suite à une erreur éventuelle de ma part. C’est un peu gros ça et même sérieusement problématique :eek: .

Je viens de remarquer que j’avais oublié une lettre (la première) dans le nom d’utilisateur passé en argument à la commande. J’ai tenté une connexion SFTP sans authentification par clé publique, et ça a marché, après la correction du nom d’utilisateur.

Est‑il possible que chez 1&1, on puisse voir son IP filtrée et bloquée pour une simple erreur de ce genre ? Mais alors comment font les gens qui ont une IP fixe ? Et comment fait‑on si on retombe sur la même IP ? Je vais essayer de les contacter pour leur poser la question, parce que ça peut poser de sérieux problèmes ce genre de comportement de leur part (ou de configuration de leurs serveurs).

Je vais re‑essayer plus tard, avec l’authentification par clé publique, mais pas tout de suite, c’est assez de frayeur pour le moment.

En tous les cas, notez que apparemment une erreur de nom d’utilisateur SSH, peut, chez 1&1, vous poser un gros problème en vous bloquant totalement. Faites‑y attention… (je rapporterai leur réponse sur cette question, ici, quand je les aurai contacté).
 
WRInaute impliqué
C'est un vps "sauce 1&1" ou un "vrai" dédié ? si on parle bien de serveur dédié, le serveur ne peut bannir ton ip que si un programme comme fail2ban a été installé et configuré pour bannir les tentatives infructueuses sur le (s)ftp)..
 
WRInaute passionné
Marie-Aude a dit:
Pour ton avatar, il n'a pas disparu, c'est imageshack qui ne renvoie plus rien.
Ça fini toujours pas poser des problèmes ce genre de site :-/ . Je ne me souvenais plus qu’il était hébergé là.

honolulu a dit:
C'est un vps "sauce 1&1" ou un "vrai" dédié ? si on parle bien de serveur dédié, le serveur ne peut bannir ton ip que si un programme comme fail2ban a été installé et configuré pour bannir les tentatives infructueuses sur le (s)ftp)..
Chez 1&1, c’est un mutualisé.

Comme je l’ai testé ensuite, je confirme que l’authentification par clé publique fonctionne maintenant, et que c’était bien l’erreur dans le nom d’utilisateur qui me faisait apparemment bannir par l’IP.

Je n’ai pas encore contacté 1&1 à ce sujet. Je penserai à en parler quand ce sera fait, mais je ne peux pas dire quand j’aurai la tête à le faire.
 
Discussions similaires
Haut