La clé ssh doit-elle s'appeler id_rsa?


130

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

Je me demandais si quelqu'un d'autre a déjà expérimenté cela. J'ai quelques clés pour mon utilisateur actuel qui peuvent se connecter à différentes machines. Laissez dire machine1 et machine2. J'ai collé ma clé publique dans leur fichier allowed_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, la sortie suivante est fournie avec ma connexion ssh verbose

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).

Comme vous pouvez le voir ci-dessus, il n’offre que la clé id_rsa. Est-ce correct? Si oui, pourquoi? Comment puis-je l'obtenir pour offrir plus de clés? Je sais que c'est un problème que je vois par intermittence, car chez moi, j'ai plusieurs clés sans trop de peine.

J'apprécierais également un aperçu de la manière dont la clé publique et la clé privée interagissent avec le client et le serveur. Je pensais que j'avais une idée assez décente, mais apparemment, il me manque quelque chose.

S'il te plaît et merci.

Réponses:


157

Par défaut, SSH recherche id_dsaet id_rsafichiers. Les clés ne doivent pas obligatoirement être nommées ainsi, vous pouvez également le nommer mykey, ou même le placer dans un autre répertoire. Cependant, si vous utilisez l'une de ces méthodes, vous devez explicitement référencer la clé dans la commande ssh comme suit:

ssh user@server -i /path/to/mykey

Si une commande n'accepte pas , utilisez -ipar exemple sshfsl' IdentityFileoption:

sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint

Comment ça fonctionne

Lors de la génération d'une clé, vous obtiendrez 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.

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

Lorsque vous (client) vous connectez à un serveur, des clés publiques sont échangées. Vous recevrez les serveurs un, et le vôtre. 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 en serez averti car une éventuelle attaque MITM (homme au milieu) 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 ~/.ssh/authorized_keysfichier. Raisons possibles pour lesquelles la clé publique est refusée:

  • /etc/ssh/sshd_config:
    • AllowUsersou AllowGroupsest spécifié, mais votre utilisateur de serveur ne figure pas dans la liste des groupes ou des utilisateurs (par défaut, il n'est pas défini, aucune restriction n'empêche les utilisateurs ou les groupes de se connecter).
    • DenyUsersou DenyGroupsest spécifié et que vous êtes dans la liste des utilisateurs ou des groupes.
    • Vous essayez de vous connecter en tant que root, mais il PermitRootLoginest défini sur No(par défaut yes).
    • PubkeyAuthenticationest réglé sur No(par défaut yes).
    • AuthorizedKeysFileest 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 personnel)
  • ~/.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 de courir ssh user@host -i /path/to/identity_file, vous pouvez utiliser un fichier de configuration, ~/.ssh/config.

Les paramètres communs sont IdentityFile (les clés) et le port. La prochaine configuration vérifiera "id_dsa" et "bender" uniquement lors de la connexion avec ssh youruser@yourhost:

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 ce match d'accueil, comme User youruser, Port 2222, etc. Cela vous permettra de vous connecter avec le raccourci au ssh yourhostlieu de ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.


1
pourquoi dois-je spécifier la clé? le but est que je puisse ssh à la machine plus facilement.
myusuf3

2
@StevenRoose from ssh_config(5): 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 '(nom d'hôte local),'% h '(nom d'hôte distant) ou'% r '(nom d'utilisateur distant). Il n'est pas possible de spécifier des caractères génériques, mais cela devrait être assez pratique, je suppose. Sachez qu'un serveur doit analyser chaque clé que vous avez envoyée. Il est donc préférable de spécifier moins de clés. Caractères génériques sur le travail hôte, voir à nouveau la page de manuel de ssh_config(5).
Lekensteyn

2
@therobyouknow Il n'est pas nécessaire de créer une paire de clés unique pour chaque machine. Habituellement, vous avez peu de clés et ajoutez la clé publique de l'une des clés au .ssh/authorized_keysfichier sur les ordinateurs distants. Si vous utilisez le .ssh/id_rsanom de fichier standard (ou id_dsa, id_ecdsa ou le récent id_ed25519), ssh essaiera cette opération automatiquement et vous n'avez pas besoin de spécifier IdentityFilevotre configuration (ou le -i path/to/id_fileparamètre for ssh).
Lekensteyn

4
J'aime les réponses qui vont au-delà des détails requis et prennent le temps d'expliquer le concept. Merveilleux travail! +1
user2490003

1
@landed C'est l'hôte du serveur SSH (il peut s'agir d'une adresse IP ou d'un nom DNS). J'ai essayé de clarifier cet article, j'espère que cela aidera.
Lekensteyn

40

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

IdentityFile ~/.ssh/%l_%r@%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. Par conséquent, si je souhaite me connecter à partir de ma machine appelée foo pour interdire à l'utilisateur, je lance:

ssh bar

Et ssh utiliserait automatiquement:

~/.ssh/foo_user@bar_id_rsa

Comme l'hôte local est également stocké, cela permet de créer des répertoires personnels partagés sur NFS (clé différente par machine!) Ou même d'identifier la machine sur laquelle la clé était censée être placée ...


1

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, j'aimerais proposer ma solution personnelle.

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

Ici, j'ai 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 aussi ajouter un script très rapide pour passer à un autre jeu sans avoir à taper à nouveau 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.


1
Je viens d'ajouter un alias dans bash_profile pour chaque serveur avec lequel je travaille. Donc, pour un serveur appelé bob, j’ai juste ceci ... alias bob = "ssh bob.example.com -l pete -i / chemin / à / clé" - alors je viens de taper bob - et j’en fais partie!
Peter Bagnall

2
Bien qu'il soit parfois plus facile de "faire les choses comme vous le savez déjà", il existe des approches plus faciles si vous configurez les clés et les hôtes .ssh / configs. Ce commentaire est dirigé vers l'affiche et le commentateur de commentaires @ Peter-Bagnall
Scott Prive
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.