[Linux-bruxelles] RESOLVED Was:Re:refonctionne au prix de ma sécurité Was:Re:gros problème de login par ssh

[Aldo]

Bonsoir Giovanni.

cette fois-ci c'est définitif, le problème est résolu;
pour autant je ne suis pas tout à fait heureux, car quand on résous un
problème on aime que ça soit cohérent, et qu'on comprenne plus précisément
d'où est sorti le problème:

ici la solution est tout aussi simple que absurde,

j'ai fait un cp de sshd_config.orig vers sshd_config (/etc/ssh/sshd_config
pour être précis),
puis j'ai re-modifié à la main PasswordAuthentication yes pour le re-mettre
en no comme il l'était quand ça ne marchait pas/plus!
et j'ai redémarré;

résultat:
- en sortie tj pas de problèmes, ça on s'en doute
- depuis l'Ubuntu de ma copine plus de problèmes
- et depuis networx.be plus de problèmes.

Avant de remettre l'option PasswordAuthentication en no j'avais essayé à
partir des deux mêms sources, et ça avait refonctionné;
donc me restait plus qu'à vérifier si en re-remettant PasswordAuthentication
no ça allait encore fonctionner!

Mais ça me laissera perplexe, c'est abusrde ce que je viens de faire, et la
seule différence est la date du sshd_config, sinon c'est à nouveau le même
fichier qu'il y avait quand ça ne fonctionnait pas.

Alors pour te répondre sur le reste:
 
On Mon, Nov 29, 2010 at 08:31:52PM +0100, Giovanni Rapagnani wrote:
> On 29/11/10 15:51, Aldo wrote:
>> Eh bien, je n'ai donc rien touché depuis le 3 mai, apparement, et tout à
>> coup un beau lundi matin j'ai plus accès:
>> - y a-t-il un lien avec mon set de clés id_rsa*
>> - ou es-ce un bug apparu récemment, où l'on doit autoriser que des hackers
>> sans clé puissent se loguer dans une machine que je souhaite protégéer ?
>
> On va d'abord essayer de voir si ce n'est pas un problème avec ton set de clé.
>
> Je vérifierais avant toute chose, sur jupiter, que le fichier  
> ~olr/.ssh/authorized_keys a bien les permissions mises à 600 

ça l'est.

>et que le  
> répertoire ~olr/.ssh a les permission à 700. 

C'est en 711 (sans doute par défaut) mais j'y touche plus vu que là ça
refonctionne. 

>Enfin, vérifie que ta clé 
> publique se trouve bien dans le fichier ~olr/.ssh/authorized_keys.

A coup de diff je vois que c tout à fait pareil.

> Si cela est bien vérifié et ne résoud rien alors tu peux générer sur 
> koala un set de clé RSA de test avec la commande:
> user at koala:~$ ssh-keygen -t rsa -b 2048 -f ./testkey
>
> Tu auras une clé privée dans le fichier ~/testkey et la clé publique dans 
> ~/testkey.pub

Ah! j'ignorais qu'on pouvait créer un fichier autre que id_rsa*
en guise de testkey.

> Tout en ayant laissé sur jupiter le /etc/ssh/sshd_config qui autorise  
> l'authentification par mot de passe, tu copies la clé publique de test 
> depuis koala vers jupiter avec la commande:
>
> user at koala:~$ ssh-copy-id -i ~/testkey olr at jupiter

Voilà une autre commande que j'ignorais; en général je recopiais id_rsa.pub
par scp vers authorized_keys sur la machine distante. 

> Ici tu devras introduire le mot de passe de l'utilisateur olr sur jupiter.
>
> Ensuite tu testes que ta nouvelles clé privée est prise en compte lors de 
> la connexion vers jupiter, càd qu'on te demande d'introduire le 
> passphrase de la clé privée ou bien que la connexion est immédiate si tu 
> n'as pas précisé de passphrase lors de la création du set de clé. 

>Tu 
> testeras donc avec la commande suivante:
>
> user at koala:~$ ssh -i ~/testkey olr at jupiter
>
> Si cela fonctionne, c'est qu'il y a un problème avec ton ancien set de clé.

Es-ce que on sait tester le set de clés actu, cad celui qui (re)fonctionne ?
J'ai par exemple sur koala les fichiers: 
~/.ssh/authorized_keys
~/.ssh/id_rsa
~/.ssh/known_hosts

C sans doute plus difficile de checker quand ça refonctionne ? à moins qu'il
y ait des infos (status) utiles pour voir que ça fonctionne bien ?

Enfin grand merci de ton aide, ça m'embête que ça se sois résolu d'une façon
pas cohérente... 

Aldo.