Impedisci al client ssh di offrire tutte le chiavi pubbliche che riesce a trovare?


32

Come la maggior parte dei amministratori di sistema, utilizzo continuamente openssh. Ho circa una dozzina di chiavi ssh, mi piace avere una chiave ssh diversa per ogni host. Tuttavia, ciò causa un problema quando mi connetto per la prima volta a un host e tutto ciò che ho è una password. Voglio solo connettermi all'host usando una password, nessuna chiave ssh in questo caso. Comunque il client ssh offrirà tutte le chiavi pubbliche nel mio ~/.ssh/(lo so guardando l'output di ssh -v). Dal momento che ne ho così tanti, mi disconnetterò per troppi errori di autenticazione.

C'è un modo per dire al mio client SSH di non offrire tutte le chiavi SSH?


2
Perché vorresti una chiave diversa per ogni host? Le chiavi possono anche essere condivise tra host all'interno di un singolo dominio amministrativo. Ovviamente, useresti una chiave per le tue macchine di lavoro e un'altra per le tue macchine private, ma qual è la logica dietro l'utilizzo di una chiave separata per ogni macchina al lavoro?
Alex Holst,

@AlexHolst Sto usando molti tasti. Ne ho uno predefinito criptato (che mi richiede di inserire una password) per l'infrastruttura interna. Ne ho un altro non crittografato (senza password) che utilizzo per un servizio specifico in cui non potevo usare un agente né volevo digitare ogni minuto la password. Ne ho altri per le connessioni che non fanno parte della nostra infrastruttura interna. È una buona pratica, perché anche se per qualcuno dovrebbe essere piuttosto difficile recuperare la chiave privata dalla chiave pubblica, è possibile farlo. ad esempio il bug di Debian openssh alcuni anni fa ...
Huygens,

@Huygens Mi piacerebbe vedere il tuo documento di analisi del rischio che ha portato alla conclusione che è necessario utilizzare più chiavi SSH ma avere un testo in chiaro va bene. Puoi postare un link?
Alex Holst,

@AlexHolst non devi essere così "diretto". Prima di tutto la mia risposta è stata sulle ragioni per avere più coppie di chiavi. Penso di averti dato diversi. Dopo, tutti abbiamo a che fare con le stranezze e cosa no. Ho un sistema di test per il quale non posso usare un'app che esegue il tunneling dei dati tramite SSH senza che mi venga richiesta continuamente la password chiave che rende il software non utilizzabile. Sembra essere un bug a causa dell'incompatibilità delle versioni o cosa no. Ricevo una notifica e-mail per qualsiasi accesso SSH e sono l'unico accesso a quella casella. Quindi il rischio è accettabile.
Huygens,

Risposte:


31

Questo è un comportamento previsto secondo la pagina man di ssh_config:

 IdentityFile
         Specifies a file from which the user's DSA, ECDSA or DSA authentica‐
         tion identity is read.  The default is ~/.ssh/identity for protocol
         version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for
         protocol version 2.  Additionally, any identities represented by the
         authentication agent will be used for authentication.  

         [...]

         It is possible to have multiple identity files specified in configu‐
         ration files; all these identities will be tried in sequence.  Mul‐
         tiple IdentityFile directives will add to the list of identities
         tried (this behaviour differs from that of other configuration
         directives).

Fondamentalmente, specificando IdentityFiles si aggiungono semplicemente le chiavi a un elenco corrente che l'agente SSH ha già presentato al client.

Prova a ignorare questo comportamento con questo nella parte inferiore del tuo .ssh/configfile:

Host *
  IdentitiesOnly yes

Puoi anche ignorare questa impostazione a livello di host, ad esempio:

Host foo
  User bar
  IdentityFile /path/to/key
  IdentitiesOnly yes

4
Puoi anche usare ssh -o "IdentitiesOnly true" -v -A user@hostqual è quello che uso per accedere a una macchina che non ha nessuna delle mie chiavi ma voglio offrire l'inoltro dell'agente per continuare. ( -vper il debug dettagliato).
Devo dire che il

1
@eckes questo è un bel consiglio, ma non dovrebbe essere yes(e non true) però?
aexl

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

38

Sebbene altri abbiano accennato a questo con soluzioni basate sulla configurazione, probabilmente vale la pena sottolineare che puoi farlo facilmente solo una volta sulla riga di comando con:

ssh -o 'PubkeyAuthentication no' myhostname.mydomain

3
Perfetto .. LA soluzione IMHO
drAlberT

1
Corretta, questa dovrebbe essere la risposta accettata.
JM Becker

11

Seguendo la soluzione di James Sneeringer, potresti semplicemente voler impostare un ssh_config sulla falsariga di:

Host *.mycompany.com
  IdentityFile .ssh/id_dsa_mycompany_main

Host *.mycustomer.com
  IdentityFile .ssh/id_dsa_mycustomer

Host *
  RSAAuthentication no #this should be up top, avoid ssh1 at all costs
  PubkeyAuthentication no

Se ti connetti con una chiave particolare a molte macchine non appartenenti a un dominio comune, prendi in considerazione l'idea di assegnare loro tutti i CNAME nel tuo DNS. Lo faccio con tutti i sistemi dei clienti.


2

Simile alla soluzione di user23413, è possibile disabilitare del tutto l'autenticazione con chiave pubblica per un determinato host (o modello jolly):

Host *.example.org
RSAAuthentication no        # SSHv1
PubkeyAuthentication no     # SSHv2

-1

Se si punta a un determinato file di chiavi con ssh -i / path / to / key, questo verrà utilizzato solo se altri sono caricati nell'agente e non verrà richiesta la password. Puoi anche modificare ~ / .ssh / config e aggiungere qualcosa come questo ...

Host foo.example.com
IdentityFile .ssh / id_rsa_foo.example.com

puoi anche fare ...

Host * .example.org
IdentityFile .ssh / id_rsa_example.org


Ciò si aggiunge alla chiave di destinazione alla fine dell'elenco, il che non risolverà il problema. IdentitiesOnlysolo con quella volontà.
Jo Rhett,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.