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


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 seconde clé bender.

Quand 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 une vue d'ensemble sur la façon 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.

S'il te plaît et merci.


110
2018-03-17 15:37


origine




Réponses:


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

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

Si une commande n'accepte pas -i, par exemple. sshfs, Utilisez le IdentityFile option:

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

Comment ça marche

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 être gardée 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 openssh-server les clés publique et privée 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 ~/.ssh/authorized_keys fichier. Raisons possibles pour lesquelles la clé publique est refusée:

  • /etc/ssh/sshd_config:
    • AllowUsers ou AllowGroups est spécifié, mais l'utilisateur de votre serveur n'est pas répertorié dans la liste des groupes ou des utilisateurs (par défaut, il n'est pas défini, ce qui empêche les utilisateurs ou les groupes de se connecter).
    • 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 réglé sur No (défaut yes).
    • PubkeyAuthentication est réglé sur No (défaut yes).
    • 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 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)

Utiliser 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 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 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 cette correspondance d'hôte, comme User youruser, Port 2222, etc. Cela vous permettrait de vous connecter à la sténographie ssh yourhost au lieu de ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.


136
2018-03-17 15:58



Pourquoi dois-je spécifier la clé? Le point est donc que je peux facilement ssh à la machine. - myusuf3
@StevenRoose de ssh_config(5): Le nom de fichier peut utiliser la syntaxe tilde pour faire référence au répertoire de base d'un utilisateur ou à l'un des caractères d'échappement suivants: '% d' (répertoire personnel de l'utilisateur local), '% u' (nom d'utilisateur local) nom d'hôte), '% h' (nom d'hôte distant) ou '% r' (nom d'utilisateur distant). Il est impossible de spécifier des caractères génériques, mais cela devrait être assez pratique, je suppose. Sachez qu'un serveur doit sonder chaque clé que vous avez envoyée. Il est donc préférable de spécifier moins de clés. Wildcards on Host work, revoyez la page de manuel de ssh_config(5). - Lekensteyn
@therobyouknow Vous n'avez pas besoin de créer une paire de clés unique pour chaque machine. Habituellement, vous avez peu de clés et ajoutez la clé publique d’une des clés .ssh/authorized_keys fichier sur les machines distantes. Si vous utilisez la norme .ssh/id_rsa nom de fichier (ou id_dsa, id_ecdsa ou le récent id_ed25519), alors ssh essaiera cela automatiquement et vous n'avez pas besoin de spécifier IdentityFile dans votre config (ou le -i path/to/id_file paramètre pour ssh). - Lekensteyn
J'aime les réponses qui vont au-delà des détails requis et prennent le temps d'expliquer le concept. Travail merveilleux! +1 - user2490003
@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 cette section, j'espère que cela aide. - Lekensteyn


Ma méthode favorite 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, 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/foo_user@bar_id_rsa

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


30
2018-02-19 18:54





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, j'en suis satisfait.

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 également ajouter un script très rapide pour passer à un autre ensemble sans avoir à taper manuellement le ln commande à nouveau.

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.


0
2017-10-04 14:43



Je viens d'ajouter un alias par bash_profile pour chaque serveur avec lequel je travaille. Donc, pour un serveur appelé bob, j'ai juste ça ... alias bob = "ssh bob.example.com -l pete -i / path / to / key" - alors je viens de taper bob - et je suis dedans! - Peter Bagnall
Bien qu'il soit parfois plus facile de "faire avancer les choses comme vous le savez", il existe des approches plus faciles si vous configurez des clés et des hôtes .ssh / configs. Ce commentaire s'adresse à la fois à l'affiche de commentaires et à l'intervenant @ Peter-Bagnall - Crossfit_and_Beer