Question Comment configurer SSH pour qu'il ne tente pas automatiquement tous les fichiers d'identité?


J'ai mis mes fichiers d'identité ssh dans mon dossier ~ / .ssh /. J'ai probablement environ 30 fichiers.

Lorsque je me connecte aux serveurs, je spécifierai le fichier d'identité à utiliser, avec quelque chose comme

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

Cependant, si je ne spécifie pas de fichier d’identité, et que vous utilisez simplement quelque chose comme ceci:

ssh user123@example.com

Je reçois l'erreur

Trop d'échecs d'authentification pour l'utilisateur123

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 essaiera tous.

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

Host example.com
PreferredAuthentications clavier interactif, 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é en dehors du ~/.ssh/ répertoire, ou je pourrais spécifier chaque hôte pour lequel je veux désactiver l'authentification du fichier d'identité dans le fichier de configuration, mais existe-t-il un moyen d'indiquer à SSH d'acheter par défaut une recherche de fichiers d'identité? Ou pour spécifier ceux qu'il recherchera?


82
2018-04-09 17:01


origine


Re "Je comprends que c'est parce que ..." - utiliser ssh -v pour savoir avec certitude. - grawity


Réponses:


Vous pouvez utiliser le IdentitiesOnly=yes option avec IdentityFile (voir Page de manuel de ssh_config). De cette façon, vous pouvez spécifier le ou les fichiers à rechercher.

Dans cet exemple, ssh va seulement chercher dans les identités données dans les fichiers ssh_config + les 4 répertoriés 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 formulaires -i et -o IdentityFile= sont interchangeables


75
2018-04-09 17:11



Un Exemple serait bien - rubo77
N'est-ce pas: IdentitiesOnly yes (sans le "=")? - Dimitrios Mistriotis
@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
@NickAnderegg merci - Dimitrios Mistriotis


La réponse courte de user76528 est correcte, mais je viens d'avoir ce problème et je pense qu'une élaboration serait utile. Vous pouvez également vous soucier de cette solution si vous vous demandez "Pourquoi ssh ignore-t-il mon option de configuration de 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 tous jusqu'à ce que le serveur en accepte un 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 commune pour laquelle vous pourriez obtenir le Too many authentication failures for user Erreur. En utilisant le IdentitiesOnly yes l'option désactivera ce comportement.

Si vous ssh en tant que plusieurs utilisateurs à 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 hôte appropriées.


69
2018-06-12 22:46



bien expliqué, merci. Il n'est pas évident que ce paramètre 'IdentitiesOnly' signifie TakeOnlyQu'est-ce queSpécifie explicitementThenFailoverToPassword. Et apparemment, la clé ./ssh/id_rsa est toujours répertoriée. - lImbus
En mettant IdentitiesOnly yes dans la section globale de ssh_config, c'est ce que j'ai fait pour moi. Merci! - jamix
Merci pour le commentaire détaillé. J'ai l'habitude d'utiliser ('\' pour newline) Host * \ IdentityFile ~/.ssh/mykeycomme une option de configuration, et au début, il semblait étrange d'avoir une entrée différente pour un site spécifique, par ex. Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yes continué à fournir mykey au lieu de specialkey. Ce n'était certainement pas clair, jusqu'à ce que je réalise (à partir de votre réponse) que les entrées IdentityFile sont empilées dans un ordre d'évaluation et que la dernière définie sera utilisée. Enlever IdentityFile ~/.ssh/mykey résolu le problème, et la seule clé correcte a été utilisée. - Ryder
Avant que j'essaye ceci, j'ai remarqué mon git pull/push les commandes essayaient chaque identité unique chargée dans mon agent. Ce n'était pas un problème jusqu'à ce que j'ai eu trop de clés à un moment donné. - sdkks


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 $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 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 ssh a seulement identifié le my_id_rsa clé privée via l'interface de ligne de commande et qu'il 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).

15
2017-12-09 00:18



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


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

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

ssh -o PreferredAuthentications=password user@example.com

9
2018-06-19 14:19





Utiliser IdentityFile mais continuez à utiliser ssh-agent pour éviter les reprogrammations de la phrase secrète

La solution acceptée de l'utilisation IdentitiesOnly yes Cela signifie 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é.

Continuer à utiliser ssh-agent et éviter les erreurs «Trop d’échecs d’authentification», essayez ceci:

  1. Supprimez tous les scripts de démarrage de la console interactive qui chargent automatiquement les clés dans ssh-agent.

  2. ajouter AddKeysToAgent yes à la configuration ssh de votre client. Cela vous invitera à saisir la phrase secrète lors de la première connexion, puis à ajouter la clé à votre agent.

  3. utilisation ssh-add -D lorsque vous obtenez des erreurs "trop ​​d'authentification". Cela réinitialise simplement (supprime) votre cache ssh-agent. Réessayez ensuite la connexion dans la même session. Vous serez invité à saisir une phrase secrète et, une fois acceptée, elle sera ajoutée à votre agent. Comme vous n’avez qu’une seule clé dans votre agent, vous serez autorisé à vous connecter. ssh-agent est alors toujours là pour les futures connexions au cours de la même session pour éviter les erreurs.

    Host ex example.com
       User joe
       HostName example.com
       PreferredAuthentications publickey,password
       IdentityFile /path/to/id_rsa
       AddKeysToAgent yes
    

4
2017-09-01 20:10



A accepter les clés ajoutées au trousseau? - vfclists


Vous avez eu la réponse tout au long (presque):

Host *
PreferredAuthentications keyboard-interactive,password

Travaillé pour moi


0
2017-08-14 22:57



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
J'ai + 1 parce que c'était la réponse que je cherchais, merci @Henry Grebler - matiu


Le client ssh et l'agent ssh communiquent via un socket de domaine Unix dont le nom est spécifié au client par la variable d'environnement SSH_AUTH_SOCK (définie par l'agent au démarrage).

Ainsi, pour empêcher un appel unique du client d'interroger l'agent, cette variable peut être définie explicitement sur quelque chose d'invalide, comme une chaîne vide;

$ SSH_AUTH_SOCK= ssh user@server

Une invocation de client comme celle-ci échouera lors de la communication avec l'agent et pourra uniquement offrir au serveur les identités disponibles sous forme de fichiers dans ~ / .ssh / ou dans la ligne de commande spécifiée avec -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

0
2018-06-02 17:57