Comment configurer SSH afin de ne pas essayer tous les fichiers d'identité automatiquement?

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

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

 Ssh -i ~ / .ssh / client1-identité [email protected]

Cependant, si je ne spécifie pas de fichier d'identité, je n'utilise que ceci:

 Ssh [email protected]

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 ssh peut trouver des fichiers d'identité, il les tentera tous.

Je comprends également que je peux éditer le fichier ~/.ssh/config 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 répertoire ~/.ssh/ , ou je pourrais spécifier chaque hôte que je souhaite désactiver l'authentification du fichier d'identité dans le fichier de configuration, mais est-il possible de dire à SSH Acheter par défaut ne pas rechercher des fichiers d'identité? Ou pour spécifier ceux qu'il recherchera?

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

    La réponse courte de l'utilisateur76528 est correcte, mais j'ai juste eu ce problème et je pensais que l'élaboration serait utile. Vous pourriez également vous occuper de cette solution si vous vous êtes demandé "Pourquoi ssh ignore 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, l'option IdentityFile ajoute ce fichier à une liste d'identités utilisée. Vous pouvez empiler plusieurs options IdentityFile , et le client ssh les tentera jusqu'à ce que le serveur 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 dans l'option IdentityFile (ou -i) de ssh_config. C'est une raison commune pour laquelle vous pouvez obtenir les Too many authentication failures for user erreur de l' Too many authentication failures for user . L'utilisation de l'option IdentitiesOnly yes désactive ce comportement.

    Si vous ssh en tant qu'utilisateur multiple à plusieurs systèmes, je recommande de mettre IdentitiesOnly yes uniquement sur votre section globale de ssh_config et de mettre chaque IdentityFile dans les sous-sections hôtes 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 d'utiliser uniquement les clés fournies via CLI et aucune de $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 expressément 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 la my_id_rsa privée my_id_rsa via 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). 

    Dans le scénario 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 utiliser le mot de passe pour vous connecter, voici comment vous le faites.

    Pour utiliser SEULEMENT l'authentification par mot de passe et N'utilisez PAS la clé publique, et n'utilisez PAS le "clavier interactif" (qui est un superset incluant le mot de passe) qui est un peu trompeur, vous pouvez le faire à partir de la ligne de commande:

     ssh -o PreferredAuthentications=password [email protected] 

    Le client ssh et le ssh-agent 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 lors de son démarrage).

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

     $ SSH_AUTH_SOCK= ssh user@server 

    Une invocation client comme celle-ci échouera à communiquer avec l'agent et ne pourra que proposer les identités disponibles en tant que fichiers dans ~ / .ssh /, ou tout spécifié sur la ligne de commande à l'aide de -i, sur le serveur.

     debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused 

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

     Host * PreferredAuthentications keyboard-interactive,password 

    J'ai travaillé pour moi.