Autenticazione con chiave SSH con più computer


21

Stavo leggendo l'autenticazione con chiave SSH e la configuravo con i miei 3 computer a casa.

Ho un computer principale, lo chiamo "A", e altri due, li chiamo "B" e "C".

Ora, in base alla documentazione che ho letto, eseguivo ssh-keygen su B e C e inserivo le chiavi pubbliche sul computer A, supponendo che avrò sempre SSH nel computer A, se sono su B o C.

Ma, penso che gli esempi di documentazione che ho letto presumono che verrà utilizzato solo 1 computer di casa con un altro computer esterno. Nella mia situazione, ha senso eseguire ssh-keygen su un computer e copiare i file sugli altri? In questo modo devo solo eseguire il backup di un set di chiavi? E quando accedo a un computer esterno, devo solo configurarlo con 1 set di chiavi e non configurarlo con tutti e tre i computer.

ha senso? Qualche difetto o avvertenza da considerare?

Grazie.

Risposte:


29

Teoricamente puoi fare entrambe le cose, ma ognuna ha i suoi vantaggi e svantaggi:

Puoi infatti creare solo 1 chiave, dire che è "tua" (come persona), proteggerla da qualche parte e copiarla su qualsiasi computer che usi. Il vantaggio è che puoi connetterti ad A ovunque tu vada, purché possiedi la tua chiave privata SSH. Lo svantaggio è che finché copi la tua chiave privata da un luogo a un altro, in ogni caso, aumenti il ​​rischio che venga letta da qualcuno che intercetta la connessione. Peggio ancora, se il computer C viene rubato, devi rigenerare una nuova chiave su tutti i computer che usano questa chiave e distribuirne una nuova.

D'altra parte, l'uso di 1 chiave per utente @ computer ha il vantaggio di un maggiore "controllo fine" su "cosa" può connettersi "dove". È il modo più comune di fare.

Se, ad esempio, dovessi consegnare il computer C a tuo fratello / sorella / moglie / marito / amico / cane o a un ladro (senza la tua approvazione), dovresti semplicemente rimuovere la chiave dalle "chiavi autorizzate" di A file.

Quindi, anche se significa "più chiavi in ​​authorized_keys" suggerisco il secondo approccio.


Non è possibile decrittografare un flusso ssh con la chiave privata del client e, a seconda delle impostazioni del server, non è nemmeno possibile decrittografarlo con la chiave privata del server. zurlinux.com/?p=1772
Dan Merillat

Esatto, e non è quello che intendevo. Volevo dire che se la tua chiave privata viene rubata, puoi usarla per collegarti al computer A da qualsiasi altra parte. Questo può essere mitigato aggiungendo un FROM = "<IP>" all'inizio della riga authorized_keys. (vedi la pagina man di ssh)
mveroone,

dopo averlo copiato ho dovuto inserire la mia password per usarla sull'altro mio computer, immagino che sia almeno un po 'di sicurezza :)
OZZIE

3

L'uso degli stessi tasti su tutti e tre i computer è sicuramente fattibile, lo faccio sempre, principalmente per comodità.

Kwaio sottolinea correttamente che ciò aumenta il rischio che le tue chiavi vengano compromesse. Una possibile soluzione sarebbe quella di separare i componenti della chiave privata e pubblica. Così:

  • Tutti i computer hanno la tua chiave pubblica nel file authorized_keys.
  • Conservi 2 copie della tua chiave privata; uno è in una chiavetta USB intorno al collo (da usare quando si usa ssh per accedere a un altro computer) e l'altro è anche in una chiavetta USB in un luogo sicuro (nel caso in cui si perda la prima copia).

Se uno dei tuoi computer viene rubato o la tua chiave pubblica è altrimenti compromessa - beh, è ​​solo una chiave pubblica, e allora.

Se la tua chiave privata viene rubata o persa, inizi immediatamente a generare una nuova coppia di chiavi e ad aggiornare le chiavi pubbliche su tutti i tuoi computer.

HTH.


2
Ok, ma cos'è HTH?
Mikeserv,

3
HTH = Spero che aiuti.
ALAN WARD,

1
Sarebbe opportuno sottolineare che se si inserisce la chiave privata in un'unità flash, sarebbe saggio renderla una chiave privata protetta da passphrase. L'inconveniente di dover inserire la passphrase ogni volta può essere mitigato usando un agent (pagent su windows, ssh-agent su linux)
mveroone
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.