Comment configurer SSH pour qu'il n'essaye pas automatiquement tous les fichiers d'identité ?

Vous pouvez utiliser le IdentitiesOnly=yes option avec IdentityFile (voir la page de manuel ssh_config). De cette façon, vous pouvez spécifier quel(s) fichier(s) il doit rechercher.

Dans cet exemple, ssh va seulement regarder dans les identités données dans les fichiers ssh_config + les 4 listées en ligne de commande (les identités fournies par l'agent seront ignorées) :

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    [email protected]

Les formes -i et -o IdentityFile= sont interchangeables.

En .ssh/config , vous pouvez inclure une configuration comme celle-ci :

Host example
User user123
Hostname example.com
IdentityFile ~/.ssh/id_rsa_example
IdentityFile ~/.ssh/id_rsa_example2
IdentitiesOnly yes

La réponse courte de user76528 est correcte, mais je viens d'avoir ce problème et j'ai pensé que des précisions seraient utiles. Cette solution peut également vous intéresser si vous vous êtes demandé "Pourquoi ssh ignore-t-il l'option de configuration de mon fichier d'identité" ?

Tout d'abord, contrairement à toutes les autres options de ssh_config, ssh n'utilise pas le premier IdentityFile qu'il trouve. Au lieu de cela, le IdentityFile L'option ajoute ce fichier à une liste d'identités utilisées. Vous pouvez empiler plusieurs IdentityFile options, et le client ssh les essaiera toutes jusqu'à ce que le serveur en accepte une ou rejette la connexion.

Deuxièmement, si vous utilisez un agent ssh, ssh essaiera automatiquement d'utiliser les clés de l'agent, même si vous ne les avez pas spécifiées avec l'option IdentityFile (ou -i) de ssh_config. C'est une raison courante pour laquelle vous pourriez obtenir le Too many authentication failures for user Erreur. Utilisation du IdentitiesOnly yes l'option désactivera ce comportement.

Si vous utilisez SSH en tant qu'utilisateurs multiples sur plusieurs systèmes, je vous recommande de mettre IdentitiesOnly yes dans votre section globale de ssh_config, et en mettant chaque IdentityFile dans les sous-sections Host appropriées.

Je le fais généralement comme ça :

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa [email protected]

Les options sont les suivantes :

• -o IdentitiesOnly=yes - indique à SSH de n'utiliser que les clés fournies via la CLI et aucune du $HOME/.ssh ou via ssh-agent
• -F /dev/null - désactive l'utilisation de $HOME/.ssh/config
• -i ~/path/to/some_id_rsa - la clé que vous souhaitez explicitement utiliser pour la connexion

Exemple

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa [email protected]
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

Notez dans la sortie ci-dessus que ssh n'a identifié que le my_id_rsa clé privée via la CLI et qu'il l'utilise pour se connecter à un serveur.

Plus précisément ces sections :

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

et :

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).