Par défaut, SSH recherche id_dsa
et id_rsa
fichiers. 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 -i
par exemple sshfs
l' IdentityFile
option:
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-server
du 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_keys
fichier. 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 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).
DenyUsers
ou DenyGroups
est 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
PermitRootLogin
est défini sur No
(par défaut yes
).
PubkeyAuthentication
est réglé sur No
(par 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)
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 yourhost
lieu de ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender
.