La clé ssh doit-elle être nommée id_rsa?

108

J'ai rencontré ce problème à plusieurs reprises lors de la création de serveurs de génération avec une authentification par clé.

Je me demandais si quelqu'un d'autre avait fait l'expérience de cela. J'ai quelques clés pour mon utilisateur actuel qui peuvent se connecter à différentes machines. Disons machine1 et machine2. J'ai collé ma clé publique dans leur fichier authorized_keys respectif. Le premier que j'ai nommé la première clé id_rsa et la deuxième clé bender.

Lorsque j'essaie de me connecter à Bender, j'obtiens la sortie suivante avec ma connexion ssh verbeuse

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Il ne propose que la clé id_rsa, comme vous pouvez le voir ci-dessus. Est-ce correct? Si oui, pourquoi? Comment puis-je obtenir plus de clés? Je sais que c'est un problème que je vois par intermittence, car à la maison, j'ai plusieurs clés sans trop de problèmes.

J'apprécierais également un aperçu de la manière dont la pub et les clés privées interagissent avec le client et le serveur. Je pensais avoir une bonne idée, mais apparemment, il me manque quelque chose.

Merci et merci.

    
posée myusuf3 17.03.2011 - 16:37
la source

3 réponses

134

Par défaut, ssh recherche les fichiers id_dsa et id_rsa . Il n'est pas nécessaire de nommer les clés comme ceci, vous pouvez aussi bien le nommer mykey ou même le placer dans un répertoire différent. Cependant, si vous effectuez l'une de ces opérations, vous devez explicitement référencer la clé dans la commande ssh comme suit:

ssh [email protected] -i /path/to/mykey

Si une commande n'accepte pas -i , par ex. sshfs , utilisez l'option IdentityFile :

sshfs -o IdentityFile=/path/to/mykey [email protected]:/path/on/remote /mountpoint

Comment ça marche

Lors de la génération d’une clé, vous obtenez deux fichiers: id_rsa (clé privée) et id_rsa.pub (clé publique). Comme leur nom l'indique, la clé privée doit rester secrète et la clé publique peut être publiée au public.

L'authentification par clé publique fonctionne avec une clé publique et une clé privée. Le client et le serveur ont tous deux leurs propres clés. Lors de l'installation de openssh-server , les clés publiques et privées du serveur sont générées automatiquement. Pour le client, vous devrez le faire vous-même.

Lorsque vous (client) vous connectez à un serveur, les clés publiques sont échangées. Vous recevrez les serveurs un et le serveur vous appartient. La première fois que vous recevez la clé publique du serveur, il vous sera demandé de l'accepter. Si cette clé publique change au fil du temps, vous serez averti car une éventuelle attaque MITM (Man in the middle) est en cours, interceptant le trafic entre le client et le serveur.

Le serveur vérifie si vous êtes autorisé à vous connecter (défini dans /etc/ssh/sshd_config ) et si votre clé publique est répertoriée dans le fichier ~/.ssh/authorized_keys . Raisons possibles pour lesquelles la clé publique est refusée:

  • /etc/ssh/sshd_config :
    • AllowUsers ou AllowGroups est spécifié, mais votre utilisateur de serveur n'est pas répertorié dans la liste des groupes ou des utilisateurs (par défaut, non défini, ne restreignant pas la connexion des utilisateurs ou des groupes).
    • DenyUsers ou DenyGroups est spécifié et vous êtes dans la liste des utilisateurs ou des groupes.
    • Vous essayez de vous connecter en tant que root, mais PermitRootLogin est défini sur No ( yes par défaut).
    • PubkeyAuthentication est défini sur No ( yes par défaut).
    • AuthorizedKeysFile est défini sur un autre emplacement et les clés publiques ne sont pas ajoutées à ce fichier (par défaut .ssh/authorized_keys , par rapport au répertoire de base)
  • ~/.ssh/authorized_keys : votre clé publique n'est pas ajoutée dans ce fichier (notez que ce fichier est lu en tant qu'utilisateur root)

Utilisation de plusieurs clés

Il n'est pas rare d'utiliser plusieurs clés. Au lieu d'exécuter ssh [email protected] -i /path/to/identity_file , vous pouvez utiliser un fichier de configuration, ~/.ssh/config .

Les paramètres courants sont IdentityFile (les clés) et le port. La prochaine configuration vérifiera "id_dsa" et "bender" uniquement lors de la connexion avec ssh [email protected] :

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

Si vous omettez Host yourhost , les paramètres s’appliqueront à toutes les connexions SSH. D'autres options peuvent également être spécifiées pour cette correspondance d'hôte, telles que User youruser , Port 2222 , etc. Cela vous permet de vous connecter avec le raccourci ssh yourhost au lieu de ssh -p2222 [email protected] -i ~/.ssh/id_dsa -i ~/.ssh/bender .

    
réponse donnée Lekensteyn 17.03.2011 - 16:58
la source
30

Ma méthode préférée permet de sélectionner automatiquement la clé privée

IdentityFile ~/.ssh/%l_%[email protected]%h_id_rsa

SSH remplacera% l par le nom de la machine locale,% r par le nom d'utilisateur distant et% h par l'hôte distant, donc si je voulais me connecter depuis ma machine appelée foo to bar en tant qu'utilisateur, je lance:

ssh bar

Et ssh utiliserait automatiquement:

~/.ssh/[email protected]_id_rsa

Comme l’hôte local est également stocké, cela permet aux répertoires d’accueil partagés sur NFS (une clé différente par machine!) ou même d’identifier la machine sur laquelle la clé devait être ...

    
réponse donnée Viperfang 19.02.2014 - 19:54
la source
0

Compte tenu du commentaire de StevenRoose selon lequel il faut plus de temps pour spécifier de nombreuses clés et que je joue avec beaucoup de clés, je voudrais suggérer ma solution personnelle.

Je crée un lien symbolique vers la clé que je veux utiliser à ce moment-là, et comme cela ne change que rarement selon le projet sur lequel je travaille, je suis content.

Ici, je suis lié à mes clés pour les machines fonctionnant sous virtualbox:

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

On pourrait également ajouter un script très rapide pour passer à un autre jeu sans avoir à taper manuellement la commande ln .

Encore une fois, ce n’est pas une solution pour deux clés seulement, mais pour un plus grand nombre, cela pourrait être réalisable.

    
réponse donnée ajhcasual 04.10.2013 - 16:43
la source

Lire d'autres questions sur les étiquettes