Comment configurer SSH pour ne pas essayer automatiquement tous les fichiers d’identité?

102

Je mets mes fichiers d’identité ssh dans mon dossier ~ / .ssh /. J'ai probablement environ 30 fichiers ici.

Lorsque je me connecte à des serveurs, je vais spécifier le fichier d’identité à utiliser, avec quelque chose comme:

ssh -i ~ / .ssh / client1-identité client1@10.1.1.10

Cependant, si je ne spécifie pas de fichier d'identité et que j'utilise quelque chose comme ceci:

ssh user123@example.com

Je reçois l'erreur

Trop d'échecs d'authentification pour user123

Je comprends que c’est parce que si aucun fichier d’identité n’est spécifié et que ssh peut trouver des fichiers d’identité, il les essayera tous.

Je comprends aussi que je peux éditer le ~/.ssh/configfichier et spécifier quelque chose comme:

Hôte example.com
PreferredAuthentications keyboard-interactive, mot de passe

afin d'empêcher cette connexion d'essayer des fichiers d'identité connus.

Donc, je suppose que je pourrais déplacer mes fichiers d’identité hors du ~/.ssh/répertoire ou spécifier chaque hôte pour lequel je souhaite désactiver l’authentification de fichier d’identité dans le fichier de configuration, mais existe-t-il un moyen de dire à SSH d’acheter par défaut de ne pas rechercher fichiers d'identité? Ou pour spécifier ceux qu'il recherchera?

— cwd
source

4

Re "Je comprends que c'est parce que ..." - utilisez ssh -vpour savoir à coup sûr.

— Grawity

102

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

Dans cet exemple, ssh ne recherchera que les identités données dans les fichiers ssh_config + les 4 identifiées sur la 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 \
    user123@example.com

Les formes -iet -o IdentityFile=sont interchangeables.

— init_js
source

7

Un exemple serait bien

— rubo77

1

N'est-ce pas: IdentitiesOnly yes(sans le "=")?

— Dimitrios Mistriotis

3

@DimitriosMistriotis Selon la page de manuel de ssh_config, l'une ou l'autre est acceptable:

Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.

— Nick Anderegg

IdentitiesOnlypeut ne pas toujours fonctionner, vous devrez peut-être exclure un hôte spécifiquement; voir superuser.com/questions/859661/…

— aexl

79

La réponse courte de user76528 est correcte, mais je viens d'avoir ce problème et pensais que quelques précisions seraient utiles. Vous pouvez également vous intéresser à cette solution si vous vous demandez "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 la première solution trouvée IdentityFile. Au lieu de cela, l' IdentityFileoption ajoute ce fichier à une liste d'identités utilisées. Vous pouvez empiler plusieurs IdentityFileoptions et le client ssh les testera 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 fréquente d’ Too many authentication failures for usererreur. L'utilisation de l' IdentitiesOnly yesoption désactivera ce comportement.

Si vous utilisez plusieurs utilisateurs sur plusieurs systèmes, je vous recommande de placer IdentitiesOnly yesvotre section globale de ssh_config IdentityFiledans chacun des sous-sections Host appropriées.

— chrishiestand
source

5

bien expliqué, merci. Il n'est pas évident que ce paramètre 'IdentitiesOnly' signifie TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword . Et apparemment, la clé ./ssh/id_rsa est toujours répertoriée.

— Imbus

Mettre IdentitiesOnly yesdans la section globale de ssh_config est ce qui me l’a fait. Merci!

— jamix

1

Merci pour le commentaire détaillé. J'avais l'habitude d'utiliser ('\' pour newline) Host * \ IdentityFile ~/.ssh/mykeycomme option de configuration, et au début il me semblait étrange d'avoir une entrée différente pour un site spécifique, par exemple, Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yescontinuer à fournir mykeyau lieu de specialkey. Il n'était certainement pas clair, jusqu'à ce que je réalise (d'après votre réponse) que les entrées d'IdentityFile sont empilées dans un ordre d'évaluation et que le dernier défini sera utilisé. Le IdentityFile ~/.ssh/mykeyproblème résolu a été résolu et la clé unique correcte a été utilisée.

— Ryder

1

Avant d’essayer, j’ai remarqué que mes git pull/pushcommandes essayaient toutes les identités chargées dans mon agent. Ce n'était pas un problème jusqu'à ce que j'ai eu trop de clés à un moment donné.

— sdkks

21

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

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

Les options sont les suivantes:

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

Exemple

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
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 no-more-sessions@openssh.com
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 sshla my_id_rsaclé privée n’a été identifiée que par l’intermédiaire de la CLI et qu’elle l’utilise pour se connecter à someserver.

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

— slm
source

1

Merci, c'est la seule solution complète. Apparemment, -F /dev/nullest la pièce manquante dans les autres réponses.

— Leden

10

Dans le cas où vous avez plusieurs clés, vous rencontrerez invariablement l'erreur "Trop d'échecs d'authentification". Si vous avez un mot de passe et souhaitez simplement vous en servir pour vous connecter, voici comment procéder.

Pour utiliser SEULEMENT l'authentification par mot de passe et NON pour utiliser la clé publique et NE PAS utiliser le "clavier interactif" quelque peu trompeur (qui est un sur-ensemble comprenant un mot de passe), vous pouvez le faire à partir de la ligne de commande:

ssh -o PreferredAuthentications=password user@example.com

— Greg Rundlett
source

7

Utilisez IdentityFile mais continuez à utiliser ssh-agent pour éviter les reprogrammes de phrase secrète

La solution acceptée d’utilisation IdentitiesOnly yessignifie que vous ne pourrez jamais tirer parti de ssh-agent, ce qui entraîne des invites répétées pour votre phrase secrète lors du chargement de votre clé.

Pour continuer à utiliser ssh-agentet éviter les erreurs "Trop d'échecs d'authentification", essayez ceci:

Supprimez tous les scripts de démarrage de la console interactive dans lesquels les clés sont automatiquement chargées ssh-agent.
ajouter AddKeysToAgent yesà la configuration ssh de votre client. Cela vous demandera la phrase secrète lors de la première connexion, mais ajoutera ensuite la clé à votre agent.
utilisez ssh-add -Dlorsque vous obtenez des erreurs de "trop d'authentification". Ceci simplement "réinitialise" (supprime) votre cache ssh-agent. Puis tentez à nouveau la connexion au cours de la même session. Une phrase secrète vous sera demandée et, une fois acceptée, elle sera ajoutée à votre agent. Comme vous n’avez qu’une clé dans votre agent, vous serez autorisé à vous connecter. ssh-agent est alors toujours là pour les connexions futures au cours de la même session afin d’éviter les reprogrammes.
```
Host ex example.com
   User joe
   HostName example.com
   PreferredAuthentications publickey,password
   IdentityFile /path/to/id_rsa
   AddKeysToAgent yes
```

— AndrewD
source

Acceptera-t-il les clés ajoutées au trousseau?

— vfclists le

2

Le client ssh et le ssh-agentcommuniquent via un socket de domaine Unix dont le nom est spécifié au client par la SSH_AUTH_SOCKvariable d'environnement (définie par l'agent lors de son démarrage).

Ainsi, pour empêcher une seule invocation du client d'interroger l'agent, cette variable peut être définie explicitement sur une valeur non valide, telle qu'une chaîne vide;

$ SSH_AUTH_SOCK= ssh user@server

Une telle invocation client échouera dans la communication avec l'agent et ne pourra offrir au serveur que les identités disponibles sous forme de fichiers ~/.ssh/ou spécifiées sur la ligne de commande -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

— mikini
source

C'est une excellente réponse. C'est simple et fonctionne lorsque vous utilisez des commandes qui utilisent SSH "sous le capot", comme git. Dommage que je ne puisse pas en dire plus.

— Rsuarez

1

Vous avez eu la réponse tout le temps (ou presque):

Host *
PreferredAuthentications keyboard-interactive,password

Travaillé pour moi

— Henry Grebler
source

8

La question posée sur la manière de limiter les clés publiques utilisées. Cette réponse désactive complètement l'authentification par clé publique.

— chrishiestand

1

J'ai +1 parce que c'était la réponse pour laquelle je cherchais, merci @Henry Grebler

— matiu

1

ajoutez ceci à la fin du ~/.ssh/configfichier pour empêcher l'utilisation de clés pour les serveurs non config:

Host *
IdentitiesOnly=yes

— Maxim Akristiniy
source