web-dev-qa-db-fra.com

Quelles clés privées sont testées par ssh sans configuration?

Je sais qu'il y a plusieurs questions sur les clés SSH et sur la façon de les configurer. Mais je n'en ai trouvé aucun pour répondre à ma question.

Donc voici: j'ai plusieurs clés ssh dans mon répertoire .ssh. Pour certaines télécommandes différentes clés.

Maintenant, je n'ai pas configuré dans .ssh/config quelle clé utiliser pour quel hôte, je ne les ai pas ajoutées manuellement à un agent, ce que certaines questions ont déjà mentionné. Je viens de créer les clés avec ssh-keygen et cela fonctionne.

Maintenant, j'aimerais savoir qui est responsable de cela et quelles clés sont essayées automatiquement? J'ai dans la tête quelque chose qui dit que la compatibilité de cinq clés est automatiquement vérifiée, mais je ne trouve pas où j'ai trouvé cette information.

Est-ce que ssh-keygen ajoute automatiquement ces clés à un agent? Ou bien ssh recherche-t-il une clé correspondante par défaut?

sshssh-agent
5
Bertram Nudelbach

Le client ssh vérifiera toutes vos clés jusqu'à ce qu'il en trouve une qui correspond.

Voici comment cela fonctionne (ceci est très simplifié, avant cela, une danse assez complexe a été créée pour chiffrer tout cela):

  • Le serveur crée un jeton d'authentification.
  • Le jeton est crypté à l'aide de votre clé publique sur le serveur.
  • Le serveur envoie le jeton crypté au client.
  • Le client tente de déchiffrer le jeton en utilisant toutes les clés privées connues.
  • Si cela réussit, le jeton déchiffré sera renvoyé au serveur.
  • Si le jeton correspond, le serveur laissera le client entrer.

Ce que les fichiers sont des clés dépend du client.

Pour le client Openssh (client par défaut Ubuntu), selon sa page de manuel, les fichiers qui sont supposés être des clés privées sont ./sshid_rsa, .ssh/id_dsa, .ssh/id_ecdsa, ainsi que ceux donnés après prend en charge plusieurs fichiers) et ceux déclarés dans le fichier de configuration.

Vous pouvez lui donner l'option -v pour lui faire imprimer une ligne lorsqu'il essaie d'utiliser un fichier comme clé. Voici un exemple tiré d'une connexion sans clé:

$ ssh -v www.hostremoved.com
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
<...>
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/javier/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/javier/.ssh/id_dsa
debug1: Trying private key: /home/javier/.ssh/id_ecdsa
debug1: Next authentication method: password
<...>

Comme vous pouvez le constater, toutes les clés qu’il essaie sont imprimées. Vous pouvez l’utiliser dans votre système pour découvrir les fichiers que ssh utilise dans votre propre système.

Ci-dessous, vous pouvez voir le résultat si une clé existante est trouvée et essayée.

debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: user@xyz

user@xyz est l'information ajoutée à la clé publique.

Si vous vous demandez comment votre client ssh trouve vos clés privées, ce n'est pas magique. Sous Gnome (xfce et KDE également), il existe un agent spécial ssh qui ajoute automatiquement des clés dans le répertoire .ssh qui ont une clé publique correspondante avec la fin .pub.

Si vous n'avez pas un agent ssh aussi confortable, vous devrez ajouter vos clés privées avec ssh-add key.

6
Javier Rivera

En supposant que vous ayez copié la clé publique dans le fichier authorized_keys sur la machine distante, le client ssh vérifie quelle clé privée de la machine locale correspond à la clé publique de la machine distante.

2
jackweirdy

Copié/collé à partir de ssh_config (5) dans openssh-client 1: 5.3p1-3ubuntu7:

IdentityFile

Spécifie un fichier à partir duquel l'identité d'authentification RSA ou DSA de l'utilisateur est lue. La valeur par défaut est ~/.ssh/identity pour la version 1 du protocole et ~/.ssh/id_rsa et ~/.ssh/id_dsa pour la version 2 du protocole. En outre, toutes les identités représentées par l'agent d'authentification seront utilisées pour l'authentification.

Le nom de fichier peut utiliser la syntaxe tilde pour désigner le répertoire de base d'un utilisateur ou l'un des caractères d'échappement suivants: '% d' (répertoire de base de l'utilisateur local), '% u' (nom d'utilisateur local), '% l' (local Nom d'hôte), '% h' (nom d'hôte distant) ou '% r' (nom d'utilisateur distant).

Il est possible d'avoir plusieurs fichiers d'identité spécifiés dans les fichiers de configuration. toutes ces identités seront essayées en séquence.

En bout de ligne, cela dépend de la version du protocole. Pour la version 2 (probablement ces jours-ci), id_rsa et id_dsa sont essayés dans cet ordre conformément à la doc ci-dessus. Les versions les plus récentes peuvent inclure d'autres types de clés par défaut, comme id_ecdsa. Consultez cette page de manuel dans votre version pour plus de détails.

1
Wren T.