Come configuro SSH in modo che non provi automaticamente tutti i file di identità?

102

Ho inserito i miei file di identità ssh nella mia cartella ~ / .ssh /. Ho probabilmente circa 30 file lì dentro.

Quando mi collegherò ai server, specificherò il file di identità da usare, con qualcosa di simile

ssh -i ~ / .ssh / client1-identity client1@10.1.1.10

Tuttavia, se non specifico un file di identità e utilizzo semplicemente qualcosa del genere:

ssh user123@example.com

Ottengo l'errore

Troppi errori di autenticazione per user123

Capisco che è perché se non viene specificato alcun file di identità e ssh riesce a trovare i file di identità, allora proverà tutti.

Comprendo anche che posso modificare il ~/.ssh/configfile e specificare qualcosa come:

Host example.com
PreferredAuthentications tastiera interattiva, password

per impedire a quella connessione di provare file di identità noti.

Quindi, immagino di poter spostare i miei file di identità al di fuori della ~/.ssh/directory o di specificare ogni host per cui desidero disabilitare l'autenticazione del file di identità nel file di configurazione, ma esiste un modo per dire a SSH di acquistare i valori predefiniti e non cercare file di identità? O per specificare quelli che cercherà?

— cwd
fonte

4

Ri "Capisco che è perché ..." - usa ssh -vper scoprirlo di sicuro.

— Grawity

101

Puoi usare l' IdentitiesOnly=yesopzione insieme a IdentityFile(vedi la pagina man ssh_config ). In questo modo, puoi specificare quali file dovrebbero cercare.

In questo esempio, ssh cercherà solo nelle identità fornite nei file ssh_config + le 4 elencate nella riga di comando (le identità fornite dall'agente verranno ignorate):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    user123@example.com

Le forme -ie -o IdentityFile=sono intercambiabili.

— init_js
fonte

7

Un esempio sarebbe carino

— rubo77,

1

Non è: IdentitiesOnly yes(senza il "=")?

— Dimitrios Mistriotis,

3

@DimitriosMistriotis Secondo la pagina man ssh_config, uno dei due è accettabile:

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,

IdentitiesOnlypotrebbe non funzionare sempre, potrebbe essere necessario escludere un host in modo specifico; vedi superuser.com/questions/859661/…

— aexl

79

La risposta breve di user76528 è corretta, ma ho appena avuto questo problema e ho pensato che qualche elaborazione sarebbe stata utile. Potresti anche interessarti a questa soluzione se ti sei chiesto "Perché ssh ignora l'opzione di configurazione del mio file di identità"?

Innanzitutto, diversamente da ogni altra opzione in ssh_config, ssh non usa la prima IdentityFileche trova. Invece l' IdentityFileopzione aggiunge quel file a un elenco di identità utilizzate. È possibile impilare più IdentityFileopzioni e il client ssh le proverà tutte finché il server non ne accetterà una o rifiuterà la connessione.

In secondo luogo, se si utilizza un agente ssh, ssh proverà automaticamente a utilizzare le chiavi nell'agente, anche se non sono state specificate con l'opzione IdentityFile (o -i) di ssh_config. Questo è un motivo comune per cui potresti ricevere l' Too many authentication failures for usererrore. L'uso IdentitiesOnly yesdell'opzione disabiliterà questo comportamento.

Se usi più utenti su più sistemi, ti consiglio di inserire IdentitiesOnly yesla sezione globale di ssh_config e inserirli ciascuno IdentityFilenelle sottosezioni Host appropriate.

— chrishiestand
fonte

5

ben spiegato, grazie. Non è ovvio che quel parametro 'IdentitiesOnly' significhi TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword . E a quanto pare, la chiave ./ssh/id_rsa è ancora elencata.

— Imbus

Mettere IdentitiesOnly yesnella sezione globale di ssh_config è ciò che ha fatto per me. Grazie!

— Jamix,

1

Grazie per il commento dettagliato. Usavo ('\' per newline) Host * \ IdentityFile ~/.ssh/mykeycome opzione di configurazione, e all'inizio sembrava strano che avere una voce diversa per un sito specifico, ad esempio Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yescontinuasse a fornire mykeyinvece di specialkey. Non era certo chiaro, fino a quando non mi sono reso conto (dalla tua risposta) che le voci di IdentityFile sono raggruppate in un ordine di valutazione e verrà utilizzata l'ultima definita. La rimozione ha IdentityFile ~/.ssh/mykeyrisolto il problema ed è stata utilizzata la chiave singola corretta.

— Ryder,

1

Prima di provare questo, ho notato che i miei git pull/pushcomandi stavano provando ogni singola identità caricata nel mio agente. Non è stato un problema fino a quando non ho avuto troppe chiavi.

— sdkks,

21

In genere lo faccio così:

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

Le opzioni sono le seguenti:

-o IdentitiesOnly=yes- dice a SSH di usare solo le chiavi fornite tramite l'interfaccia della riga di comando e nessuna $HOME/.sshdall'agente o tramite ssh
-F /dev/null - disabilita l'uso di $HOME/.ssh/config
-i ~/path/to/some_id_rsa - la chiave che si desidera utilizzare esplicitamente per la connessione

Esempio

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

Si noti nell'output sopra che sshha identificato solo la my_id_rsachiave privata tramite l'interfaccia della riga di comando e che la utilizza per connettersi a someserver.

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

— SLM
fonte

1

Grazie, questa è l'unica soluzione completa. Apparentemente, -F /dev/nullè il pezzo mancante nelle altre risposte.

— Leden

10

Nello scenario in cui si hanno molte chiavi, si verificherà inevitabilmente l'errore "Troppi errori di autenticazione". Se si dispone di una password e si desidera semplicemente utilizzare la password per accedere, ecco come farlo.

Per usare SOLO l'autenticazione con password e NON usare la chiave pubblica e NON usare la "tastiera interattiva" in qualche modo fuorviante (che è un superset che include la password), puoi farlo dalla riga di comando:

ssh -o PreferredAuthentications=password user@example.com

— Greg Rundlett
fonte

7

Usa IdentityFile ma continua a usare ssh-agent per evitare reimpostazioni passphrase

La soluzione accettata dell'uso IdentitiesOnly yessignifica che non sarai mai in grado di sfruttare ssh-agent, risultando in ripetute istruzioni per la tua passphrase durante il caricamento della chiave.

Per continuare a utilizzare ssh-agented evitare gli errori "Troppi errori di autenticazione", provare questo:

Rimuovere eventuali script di avvio della console interattiva in cui caricare automaticamente le chiavi ssh-agent.
aggiungi AddKeysToAgent yesalla configurazione ssh del tuo cliente. Questo ti chiederà la passphrase alla prima connessione, ma poi aggiungi la chiave al tuo agente.
utilizzare ssh-add -Dquando si ottengono errori di "troppa autenticazione". Questo semplicemente "ripristina" (elimina) la cache di ssh-agent. Quindi tentare nuovamente la connessione nella stessa sessione. Ti verrà richiesta una passphrase e, una volta accettata, verrà aggiunta al tuo agente. Dal momento che avrai una sola chiave nel tuo agente, ti sarà permesso di connetterti. ssh-agent è quindi ancora lì per connessioni future durante la stessa sessione per evitare i re-prompt.
```
Host ex example.com
   User joe
   HostName example.com
   PreferredAuthentications publickey,password
   IdentityFile /path/to/id_rsa
   AddKeysToAgent yes
```

— AndrewD
fonte

Accetterà le chiavi aggiunte al portachiavi?

— vfclists,

2

Il client ssh e the ssh-agentstanno comunicando tramite un socket di dominio Unix il cui nome è specificato al client dalla SSH_AUTH_SOCKvariabile di ambiente (impostata dall'agente all'avvio).

Pertanto, per impedire a una singola invocazione del client di interrogare l'agente, questa variabile può essere impostata esplicitamente su qualcosa di non valido, come una stringa vuota;

$ SSH_AUTH_SOCK= ssh user@server

Un'invocazione client come questa non riuscirà a comunicare con l'agente e sarà in grado di offrire al server solo le identità disponibili come file ~/.ssh/o qualsiasi specificato sulla riga di comando utilizzando -i.

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

— mikini
fonte

Questa è un'ottima risposta È semplice e funziona quando si usano comandi che usano SSH "sotto il cofano", come git. Un peccato che non posso votarlo di più.

— rsuarez,

1

Hai sempre avuto la risposta (quasi):

Host *
PreferredAuthentications keyboard-interactive,password

Ha funzionato per me.

— Henry Grebler
fonte

8

La domanda è stata posta su come limitare le chiavi pubbliche utilizzate. Questa risposta disabilita completamente l'autenticazione con chiave pubblica.

— chrishiestand,

1

Ho fatto +1 perché era la risposta per cui cercavo su Google, grazie @Henry Grebler

— matiu

1

aggiungilo alla fine del ~/.ssh/configfile per impedire l'uso delle chiavi per i server non configurati:

Host *
IdentitiesOnly=yes

— Maxim Akristiniy
fonte