Comment annuler l'identité par défaut de SSH?

Version courte : comment puis-je désactiver / remplacer les emplacements de fichier d'identité SSH par défaut ~/.ssh/id_{rsa,dsa} et forcer SSH à utiliser un autre (premier)?

Version longue :

J'essaie de configurer gitolite avec l'accès à la clé ssh. De mon client, j'aimerais accéder au référentiel gitolite-admin avec mon identité par défaut ~/.ssh/id_rsa , alors que j'ai créé une identité distincte ~/.ssh/id_rsa_git pour accéder aux référentiels normaux.

En outre, j'ai créé un alias SSH dans ~/.ssh/config :

 Host git Hostname <servername> User gitolite ForwardX11 no ForwardAgent no GSSAPIAuthentication no IdentityFile ~/.ssh/id_rsa_git

Maintenant, lorsque j'essaie d'accéder au dépôt gitolite en tant qu'utilisateur non administrateur, je reçois

 $ ssh -v git true OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /home/jaap/.ssh/config debug1: /home/jaap/.ssh/config line 105: Applying options for git debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to <servername> port 22. debug1: Connection established. debug1: identity file /home/jaap/.ssh/id_rsa_git type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/jaap/.ssh/id_rsa_git-cert type -1 debug1: identity file /home/jaap/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024 debug1: identity file /home/jaap/.ssh/id_rsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze3 debug1: match: OpenSSH_5.5p1 Debian-6+squeeze3 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4 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 <...> debug1: Host '<servername>' is known and matches the RSA host key. debug1: Found key in /home/jaap/.ssh/known_hosts:19 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 debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/jaap/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 debug1: Authentication succeeded (publickey).

Cela montre que ma clé par défaut ./ssh/id_rsa est offerte en premier et est acceptée. Mais cette clé ne fournit pas d'accès aux dépôts non-administratifs, alors je souhaite que SSH n'offre que / first ./ssh/id_rsa_git . Comment puis-je faire ceci?

J'ai essayé d'ajouter IdentitiesOnly=yes , mais cela désactive uniquement les clés de ssh-agent. Il semble qu'il n'y ait aucune option dans la configuration de ssh (à l'échelle du site ou par utilisateur) pour désactiver les identités par défaut, mais je ne trouve pas non plus un moyen de spécifier leur commande.

Il existe un paramètre de configuration SSH appelé IdentitiesOnly qui par défaut "non". Réglez-le sur Oui dans votre fichier de configuration (globalement ou pour un hôte spécifique) et votre problème doit être résolu.

Par exemple, mettez ceci dans ~ / .ssh / config:

 Host your.server.com IdentityFile ~/example/your_new.key User your_user IdentitiesOnly yes

Dans la page Man pour ssh_config:

  IdentitiesOnly Specifies that ssh(1) should only use the authentication identity files configured in the ssh_config files, even if ssh-agent(1) or a PKCS11Provider offers more identities. The argument to this keyword must be ``yes'' or ``no''. This option is intended for situations where ssh-agent offers many different identities. The default is ``no''.

J'avais exactement le même problème (et je suis bloqué par fail2ban). Cela l'a corrigé.

Je trouve qu'il est préférable de ne pas stocker des fichiers d'identité (clés) dans le répertoire ~/.ssh , car il est connu du client SSH, qui (comme vous l'avez remarqué) a une tendance ennuyeuse à essayer toutes les identités qu'il trouve dans ce répertoire, Même lorsque vous spécifiez explicitement un seul fichier d'identité pour qu'il l'utilise.

Je stocke tous mes fichiers d'identité dans un autre répertoire ( ~/.ssh2 ) qui n'est pas directement connu du client SSH. Le seul fichier dans ~/.ssh est config , qui contient une série de strophes {host -> key-to-use}.

Avec cette configuration, la seule façon pour le client SSH de trouver un fichier d'identité donné est que vous le spécifiez sur la ligne de commande avec -i , ou pour que vous puissiez ajouter une strophe nommant le fichier d'identité dans ~/.ssh/config .

Vous ne savez pas vraiment pourquoi votre configuration ne fonctionne pas comme prévu, mais vous pouvez contourner cela en transmettant une identité spécifique à ssh :

 ssh -i ./ssh/id_rsa_git git

De la page man:

  -i identity_file Selects a file from which the identity (private key) for public key authentication is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2. Identity files may also be speci‐ fied on a per-host basis in the configuration file. It is possible to have multiple -i options (and multiple identities specified in configuration files). ssh will also try to load certificate information from the file‐ name obtained by appending -cert.pub to identity file‐ names.

Cela pourrait aussi être dû au fait que l'hôte est connu. Essayez de supprimer la ligne concernée (ligne 19) de votre fichier .ssh/known_hosts puis de vous connecter à nouveau.