Mamadou Sow a écrit :

S'il y a quelqu'un qui se rappelle du mot de passe de lipn.

Moi.

Après connexion à lipn, il faut éditer

/etc/ssh/sshd_config

et remplacer

RSAAuthentication no PubkeyAuthentication no

par

RSAAuthentication yes PubkeyAuthentication yes

et relancer le service ssh

sinon je vais à partir de mon domicile ce soir je l'ai noté qq part

J'ai fait la chose. Voici la situation actuelle: Nous avons une machine (lipn) qui est dans une distribution qui n'a plus aucun support de sécurité (sarge). Et qui est ouverte sur l'extérieur par ssh et web. Quelqu'un (qui?) avait désactivé la connexion par clé (fait 1). Pas forcément une mauvaise idée au départ. Par contre, comme personne ne l'a fait, c'est toujours cette machine qui reçoit toutes les communications web (avec, rappelons-le, aucune garantie de sécurité depuis je crois un an) de l'intranet. Comme l'intranet n'est plus sur cette machine (qui gérait également le mail avant, je ne sais pas si cette configuration a été enlevée), on faisait lancer (au lancement de cette machine) un tunnel ssh vers lipn-sf4 (qui gère l'intranet, et qui est également la machine omnipotente au laboratoire). Pour cela, jusqu'en début mai, cette machine avait le droit de se connecter sans mot de passe sur le serveur. Elle lançait alors le script createsshtunnellipnsf4 (ou un nom du genre). lipn-sf4, à cause de __fait 1__ ne pouvait pas se connecter sur lipn par clé publique (omnipotence partielle donc). Depuis le mois de mai, et le changement à marche forcée des clés (parce que toutes les clés étaient compromises, et n'importe qui en cinq minutes pouvait accéder à ces clés, sauf que __fait 1__ (heureusement)), lipn ne pouvait plus accéder sans mot de passe à lipn-sf4 (qui lui, était bien obligé d'avoir l'accès par clé de toute façon). Ça marchait encore, parce que lipn n'avait pas redémarré depuis. Donc, je récapitule: Avant mon intervention, on voulait donc qu'une machine sans sécurité et connectée directement à l'extérieur par web et ssh ait un accès sans mot de passe sur le serveur omnipotent du laboratoire. Ce n'est pas bien (pour mieux le dire: c'est MAL(tm)). Après mon intervention (aujourd'hui), le tunnel est créé directement par lipn-sf4. On peut maintenant accéder à lipn avec clés publiques (mais il serait bon de « retirer » lipn de la circulation, une simple reconfiguration du pare-feu permet de s'en passer complètement). Il est créé par le programme autossh, qui, lorsqu'il n'arrive pas à faire la connexion (par exemple, parce que lipn est éteinte), réessaye un peu plus tard : If the ssh connection fails and attempts to restart it fail in quick succession, autossh will start delaying its attempts to restart, gradually backing farther and farther off up to a maximum interval of the autossh poll time (usually 10 minutes). autossh can be "prodded" to retry by signalling it, perhaps with SIGHUP ("kill -HUP"). Donc, il n'y a plus d'ordre pour relancer l'intranet. lipn-sf4 a à nouveau accès à toutes les machines. Pour les intéressés, j'ai mis l'autossh dans /etc/rc.local (lancé par /etc/init.d/rc.local start) Par contre, lipn est toujours un trou de sécurité ambulant à retardement (et avec une mèche très courte). On remarquera que cette machine ne fait absolument rien, à part de la redirection d'information vers lipn-sf4 (et un accès ssh non publicisé, non surveillé). Voilà, voilà. Correction du wiki à venir. -- JCD