Come configurare SSH in modo da non provare automaticamente tutti i file di identity framework;?

Ho messo i miei file di identity framework; ssh all'interno della mia cartella ~ / .ssh /. Ho probabilmente circa 30 file lì.

Quando si connette a server, specificherò il file di identity framework; da utilizzare, con qualcosa di simile

 ssh -i ~ / .ssh / client1-identity [email protected]

Tuttavia, se non specifico un file di identity framework; e utilizzi solo qualcosa di simile:

 ssh [email protected]

Ho l'errore

  Troppi errori di authentication per user123 

Capisco che è perché se non è specificato alcun file di identity framework;, e ssh può trovare i file di identity framework;, allora proverà tutti.

Capisco anche che posso modificare il file ~/.ssh/config e specificare qualcosa di simile:

 Host esempio.com
 PreferredAuthentications keyboard-interactive, password

al fine di impedire a tale connessione di provare i file di identity framework; noti.

Quindi, suppongo di spostare i miei file di identity framework; al di fuori della directory ~/.ssh/ o potrei specificare each host che voglio distriggersre l'authentication di file di identity framework; nel file di configuration, ma c'è qualche modo per informare SSH acquistare impostazione predefinita non cercare i file di identity framework;? O per specificare quelli che cercherà?

È ansible utilizzare l'opzione IdentitiesOnly=yes insieme a IdentityFile (vedere pagina man ssh_config ). In questo modo è ansible specificare quali file dovrebbero cercare.

La risposta breve di user76528 è corretta, ma ho appena avuto questo problema e ho pensato che un'elaborazione sarebbe utile. Potresti anche preoccuparsi di questa soluzione se ti sei chiesto "Perché ssh ignora la mia opzione di configuration del file di identity framework;"?

Innanzitutto, a differenza di each altra opzione in ssh_config, ssh non utilizza il primo IdentityFile che trova. Invece l'opzione IdentityFile aggiunge quel file ad un elenco di identity framework; utilizzate. È ansible impilare più opzioni di IdentityFile e il client ssh li proverà finché il server non accetta uno o rifiuta la connessione.

In secondo luogo, se si utilizza un agente ssh, ssh cercherà automaticamente di utilizzare le chiavi nell'agente, anche se non è stato specificato nell'opzione IdentityFile (o -i) di ssh_config. Questo è un motivo comune che potrebbe avere l'errore Too many authentication failures for user dell'errore Too many authentication failures for user . L'utilizzo dell'opzione IdentitiesOnly yes disabilita questo comportmento.

Se ssh come utenti multipli a più sisthemes, suggerisco di inserire IdentitiesOnly yes nella tua sezione globale di ssh_config e mettere each IdentityFile all'interno delle sottosezioni Host appropriate.

Generalmente lo faccio così:

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

Le opzioni sono le seguenti:

  • -o IdentitiesOnly=yes – dice a SSH di utilizzare solo le chiavi fornite tramite CLI e nessuna da $HOME/.ssh o tramite ssh-agent
  • -F /dev/null – distriggers l'utilizzo di $HOME/.ssh/config
  • -i ~/path/to/some_id_rsa – la chiave che si desidera esplicitamente utilizzare per la connessione

Esempio

 $ 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$ 

Notare nell'output precedente che ssh ha identificato solo la chiave privata my_id_rsa tramite il CLI e che lo usa per connettersi a un server.

In particolare queste sezioni:

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

e:

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

Nello scenario in cui si dispone di molte chiavi, si esegue invariabilmente l'errore "Troppe errori di authentication". Se hai una password e vuoi semplicemente utilizzare la password per accedere, ecco come farlo.

Per utilizzare l'authentication SOLO password e non utilizzare il tasto Public e NON utilizzare la "tastiera-intertriggers" (che è una password superset compresa la password) un po 'ingannevole, è ansible farlo dalla row di command:

 ssh -o PreferredAuthentications=password [email protected] 

Il client ssh e l'agente ssh si comunicano tramite una socket di dominio Unix il cui nome è specificato al client dalla variabile di ambiente SSH_AUTH_SOCK (impostata dall'agente all'avvio).

Quindi, per evitare che una sola invocazione del client di interrogare l'agente questa variabile può essere impostata esplicitamente su qualcosa di non valido, come una string vuota;

 $ SSH_AUTH_SOCK= ssh [email protected] 

Un richiamo del client come questo non riesce a comunicare con l'agente e solo essere in grado di offrire le identity framework; disponibili come file in ~ / .ssh / o qualsiasi specificato nella row di command utilizzando -i al server.

 debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused 

Utilizzare IdentityFile ma tenere l'utilizzo di ssh-agent per evitare i passphrase Reprompts

La soluzione accettata di utilizzare IdentitiesOnly yes significa che non sarai mai in grado di sfruttare l'utilità ssh-agent, provocando ripetuti prompt per la tua passphrase durante il caricamento della chiave.

Per continuare a utilizzare ssh-agent e evitare gli errori "Troppe errori di authentication", provare a:

  1. Rimuovere eventuali script di avvio della console intertriggers che caricheranno automaticamente i tasti in ssh-agent .

  2. aggiungere AddKeysToAgent yes alla configuration ssh del tuo client. In questo modo verrà richiesta la passphrase al primo collegamento, ma aggiunge la chiave al proprio agente.

  3. utilizzare ssh-add -D quando si ottengono errori "troppi authentication". Questo semplicemente "reimposta" (elimina) la tua cache agente ssh. Quindi tentare nuovamente la connessione nella stessa session. Verrà richiesto un passphrase e una volta accettato, verrà aggiunto al tuo agente. Dal momento che avrai solo una chiave nel tuo agente, ti sarà permesso di connettersi. L'agente ssh è ancora presente per le connessioni future durante la stessa session per evitare reprompt.

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

Hai avuto la risposta per tutta la durata (quasi):

 Host * PreferredAuthentications keyboard-interactive,password 

Ha lavorato per me.