Que signifie cette erreur ssh?

C'est mon dernier recours. J'essaie de comprendre le problème ici depuis des heures.

Voici l'affaire: j'ai copié ma clé privée de la machine n ° 1 sur la machine n ° 2. La machine n ° 1 est capable de se connecter via ssh à un serveur avec ma clé publique très bien, mais la machine n ° 2 donne la sortie suivante, lorsqu'elle essaie de se connecter au serveur:

$ ssh -vvv -i /home/kevin/.ssh/kev_rsa user@192.168.1.244 -p 22312
OpenSSH_5.3p1 Debian-3ubuntu6, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.244 [192.168.1.244] port 22312.
debug1: Connection established.
debug3: Not a RSA1 key file /home/kevin/.ssh/kev_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace

...


Permission denied (publickey).

Il y a évidemment plus de sortie de débogage que j'ai omis et je peux fournir sur demande. Je suis convaincu cependant qu'il n'aime pas mon fichier de clé privée.

J'ai également soupçonné que cela avait à voir avec la façon dont je l'avais copié de la machine n ° 1 à la machine n ° 2. Je copie / colle le texte de la clé privée sur une clé USB. Cela pourrait être le problème, cependant, lorsque j'ai dupliqué cette méthode sur un autre fichier de clé privée de travail et fait une différence sur l'original, sur le copier / coller, ils sont identiques.

J'ai du mal avec ça. Si je pouvais simplement obtenir un peu plus d'informations sur les raisons pour lesquelles il n'aime pas ma clé, je pourrais le réparer, j'en suis sûr. Quelqu'un a une idée pour ça? Y a-t-il quelque part des métadonnées qui indiquent à ssh qu'un fichier est en fait une clé RSA?

D'après mon expérience, les deux erreurs d'authentification basées sur les clés les plus courantes sont

1. Autorisations inappropriées étendues sur le $HOME/.sshrépertoire
2. Une erreur lors de la copie de la clé publique sur le système distant

Autorisations de fichier

OpenSSH fait beaucoup pour vous protéger de vous-même. La manière la plus impactante pour les utilisateurs est d'appliquer des restrictions strictes sur les personnes ayant accès à votre dossier ssh local. Vous ne voulez vraiment que vous, et seulement vous, accéder au répertoire. Eh bien, et toute personne avec uid = 0, mais il n'y a pas de bon moyen de contourner cela. Donc, ce que vous devez faire est simplement de modifier vos autorisations: chmod -R go-rwx ~/.sshcela supprimera les droits de lecture, d'écriture et d'exécution sur tous les fichiers situés sous le répertoire .ssh de tous les utilisateurs sauf le propriétaire, c'est- à- dire vous .

Problèmes de clés autorisées

Le fichier contenant votre clé publique $HOME/.ssh/authorized_keysdoit généralement correspondre à un formulaire très spécifique pour que SSH comprenne comment accepter la clé privée. Chaque clé doit comprendre au moins 2 champs

1. Type de clé utilisée (RSA, DSA, RSA1, etc.)
2. Clé

Chaque clé, ainsi que toutes ses options et composants, doit être répertoriée une par ligne dans ce fichier. Étant donné que les clés ont tendance à être très longues, elles sont souvent enveloppées et apparaissent sous la forme de deux lignes sur votre terminal. Cela causera parfois des ravages lors de la tentative de copier / coller, car parfois un ou plusieurs sauts de ligne seront insérés partout où la clé passe sur votre écran. Résoudre ce problème peut être un peu plus délicat pour un débutant shell.

Essayez de
wc -l ~/.ssh/authorized_keys
lancer Ceci affichera le nombre de lignes dans le fichier. Comparez ce nombre avec le nombre de clés que vous attendez dans le fichier. Si vous n'acceptez que cette seule clé, vous pouvez également faire une copie du fichier de clé publique, car il s'agit du même format que votre fichier de clés autorisé. Quelque chose comme
scp -p ~/.ssh/kev_rsa.pub remotehost:~/.ssh/authorized_keys
ou, si vous avez votre clé publique sur le même système, vous pouvez le faire
cat ~/.ssh/kev_rsa.pub >> ~/.ssh/authorized_keys

En outre, consultez le fichier journal sur l'hôte distant et voyez si des erreurs y sont signalées. Les fichiers seront très probablement soit /var/log/secure.logou /var/log/auth.

Cependant, vous devrez probablement générer une nouvelle paire de clés pour que la machine 2 se connecte au serveur. Souvent, la clé publique répertorie les noms d'utilisateur et de machine de ceux qui les ont générés. Cela devrait apparaître dans votre fichier authorized_keys sur le serveur.

Les messages de débogage que vous donnez signifient qu'un fichier de clé privée est lu en supposant qu'il s'agit en fait d'un fichier de clé publique / d'hôtes autorisés. Ce n'est peut-être pas une erreur fatale (j'obtiens de tels messages même pour des connexions qui fonctionnent). Est-ce que cela dit quelque chose sur "Offrande" ou "nous avons envoyé"?

Essayez de comparer les fichiers de configuration ssh entre les deux serveurs.

c'est à dire. quelque chose comme cat / etc / sshd_config