Mon mot de passe est-il compromis parce que j'ai oublié d'appuyer sur Entrée après le nom d'utilisateur ssh ?

Si je me souviens bien, il est effectivement enregistré dans le journal si le niveau du journal est défini sur DEBUG ou TRACE.

EDIT : C'est confirmé, j'ai essayé de me connecter à mon serveur et j'ai trouvé ceci dans mes logs.

Oct 19 14:34:24 sd-xxxx sshd[26563]: pam_unix(sshd:auth): authentication failure; logname=     uid=0 euid=0 tty=ssh ruser= rhost=xxx-xxx-xxx-xxx.rev.numericable.fr 
Oct 19 14:34:26 sd-xxxx sshd[26563]: Failed password for invalid user toto from xxx.xxx.xxx.xxx port 56685 ssh2

Note : Les IP sont cachées

Ou pour plus de sécurité et de commodité, vous devriez vraiment envisager de configurer des clés SSH...

\# ssh-keyget -t rsa
(accept all defaults)

et vous obtenez...

~/.ssh/id\_rsa
~/.ssh/id\_rsa.pub

Remarque : vous pouvez renommer vos fichiers de clés si vous ajoutez ~/.ssh/config avec quelque chose comme le contenu suivant :

\# cat ~/.ssh/config
Host \*
IdentityFile ~/.ssh/ddopson\_employer\_id\_rsa

Cat le contenu de votre clé publique (sera une seule ligne) :

\# cat ~/.ssh/id\_dsa.pub
ssh-rsa AAAAB3NzaC1kc3MAAACBAOOVBqYHAMQ8J ... BbCGGaeBpcqlALYvA== ddopson@hostname

Connectez-vous maintenant à la boîte cible et collez cette ligne dans ~/.ssh/authorized_keys.

Remarque : la ligne pubkey se termine par une chaîne lisible par l'homme comme "ddopson@hostname". Vous pouvez la modifier pour qu'elle soit plus descriptive de la clé que vous utilisez (par exemple, si vous avez beaucoup de clés). Cette chaîne n'est PAS utilisée dans le cadre de l'authentification, et sert uniquement à décrire la clé à d'autres êtres humains.

C'est ça. Maintenant, lorsque vous vous connecterez à l'hôte par ssh, vous ne serez même pas invité à saisir un mot de passe.

Si vous êtes préoccupé par le stockage de votre clé privée (id_rsa), vous pouvez ajouter une phrase de passe à la clé elle-même (voir ssh-keygen), la protégeant ainsi de l'utilisation par toute personne ayant accès à vos fichiers. Vous pouvez ensuite utiliser ssh-agent pour décrypter la clé et la stocker de manière sécurisée en mémoire afin qu'elle puisse être utilisée pour plusieurs connexions SSH.

Le mot de passe a été crypté lors de sa transmission. Oui, il est possible que votre mot de passe ait été compromis car il a été imprimé dans le journal du serveur de destination. Cependant, je dirais aussi que chaque fois que vous saisissez votre mot de passe sur votre ordinateur, il peut être compromis car il peut y avoir un logiciel espion sur votre ordinateur ou un enregistreur de frappe attaché à votre ordinateur.

Si vous êtes le seul administrateur de ce système et que vous pensez que ce système n'a pas été compromis, vous pouvez avec une relative certitude supposer que votre mot de passe n'a pas été compromis, tout comme vous supposez normalement qu'il n'y a pas de logiciel espion sur votre ordinateur parce que vous n'avez rien vu de suspect. Vous pouvez modifier le journal de ce serveur et supprimer la référence à votre mot de passe.

Cet incident est l'une des raisons pour lesquelles il est préférable d'utiliser des clés SSH plutôt que des mots de passe. Ainsi, même si quelqu'un obtient le mot de passe que vous saisissez sur votre ordinateur pour décrypter la clé privée sur votre ordinateur, il ne pourra toujours pas accéder au serveur distant ; il lui faut également le fichier de la clé privée. La sécurité est une question de couches. Rien n'est parfait, mais si vous ajoutez suffisamment de couches, la situation est suffisamment difficile pour que l'attaquant passe à autre chose ou que vous l'attrapiez, car cela prend plus de temps.

Je ne ferais pas ce qui précède si votre mot de passe protège des informations très sensibles ou des ressources critiques. Cela dépend de la sensibilité de votre mot de passe.