Come si configura ssh per l'autenticazione usando le chiavi invece di un nome utente / password?


34

Come si configura ssh per autenticare un utente usando le chiavi invece di un nome utente / password?

Risposte:


27

Per ogni utente: dovrebbero generare (sulla loro macchina locale) la loro coppia di chiavi usando ssh-keygen -t rsa( rsapossono essere sostituiti con dsao rsa1anche, anche se quelle opzioni non sono raccomandate). Quindi devono inserire il contenuto della loro chiave pubblica ( id_rsa.pub) ~/.ssh/authorized_keyssul server in cui si è effettuato l'accesso.


L'unica altra cosa che aggiungerei a questo è guardare le autorizzazioni sul file e sulla directory.
Trento,

2
Non dimenticare chmod 0700 .ssh chmod 0600 .ssh / authorized_keys
Dave Cheney,

3
Genera sicuramente le chiavi in ​​questo modo, ma controlla il post di @Chris Bunch in merito a "ssh-copy-id". Questo è il modo di trasferire il tuo 'id_rsa.pub'.
Gareth,

@gyaresu: grazie! Ho appena imparato qualcosa di nuovo! MrGreen
Chris Jester-Young,

23

In realtà preferisco ssh-copy-id , uno script trovato su * nix per impostazione predefinita (può essere inserito anche su Mac OS X abbastanza facilmente) che lo fa automaticamente per te. Dalla pagina man:

ssh-copy-id è uno script che utilizza ssh per accedere a una macchina remota (presumibilmente usando una password di accesso, quindi l'autenticazione della password dovrebbe essere abilitata, a meno che tu non abbia fatto un uso intelligente di più identità)

Cambia anche le autorizzazioni della casa dell'utente remoto, ~ / .ssh e ~ / .ssh / authorized_keys per rimuovere la scrivibilità del gruppo (che altrimenti impedirebbe di accedere, se lo sshd remoto ha StrictModes impostato nella sua configurazione).

Se viene fornita l'opzione -i, viene utilizzato il file di identità (il valore predefinito è ~ / .ssh / identity.pub), indipendentemente dal fatto che ci siano chiavi nel tuo ssh-agent.


2
@Chris Bunch TUTTI LO GUARDANO QUI! :) ssh-copy-id è sicuramente il modo di condividere il proprio id_rsa.pub
Gareth,

1
Fantastico, non l'ho mai saputo ... Ho scritto la mia sceneggiatura per fare esattamente la stessa cosa: - /
David Z,

6

Hum, non capirlo. Basta creare una chiave e iniziare. :) HOWTO Inoltre potresti vietare l'accesso tramite password. In eg / etc / ssh / sshd_config:

PasswordAuthentication no

2
E devi anche impostare UsePAM no (o configurare PAM di conseguenza). È incredibile quanti HOWTO manchino questa parte. In caso contrario, potrai comunque accedere con una password.
Nathan,

3

Questo è abbastanza straight-forward per fare - c'è una guida semplice per essere trovato qui .

I punti principali sono:

  • Esegui ssh-keygensulla tua macchina. Ciò genererà per te chiavi pubbliche e private.
  • Copia e incolla il contenuto della tua chiave pubblica (probabilmente in ~/.ssh/id_rsa.pub) ~/.ssh/authorized_keyssul computer remoto.

È importante ricordare che questo darà a chiunque abbia accesso alla chiave privata sul tuo computer lo stesso accesso al computer remoto, quindi quando generi la coppia di chiavi puoi scegliere di inserire una password qui per maggiore sicurezza.


Consiglio di tagliare e incollare invece di copiare. Un file authorized_keys può contenere più chiavi e non si desidera bloccare le altre chiavi già presenti.
Chris Jester-Young,

Il mio walkthrough preferito è stato consegnato alla Wayback Machine: web.archive.org/web/20061103161446/http://…
Philip Durbin,

@Chris oops - Intendevo copiarlo nel file piuttosto che sovrascriverlo! Risposta aggiornata ora per chiarire
ConroyP


1

Per riassumere ciò che altri hanno detto, impostare le chiavi SSH è facile e prezioso.

Sulla macchina che vi sarà SSHing da è necessario generare la coppia di chiavi:

claudius:~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/dinomite/.ssh/id_rsa): <ENTER>
Enter passphrase (empty for no passphrase): <PASSPHRASE>
Enter same passphrase again: <PASSPHRASE>
Your identification has been saved in /home/dinomite/.ssh/id_rsa.
Your public key has been saved in /home/dinomite/.ssh/id_rsa.pub.
The key fingerprint is:
a3:93:8c:27:15:67:fa:9f:5d:42:3a:bb:9d:db:93:db dinomite@claudius

Basta premere invio dove indicato e inserire una passphrase quando richiesto - idealmente, questo è diverso dalla normale password di accesso sia sull'host corrente che su quelli su cui SSHing.

Successivamente, è necessario copiare la chiave appena generato per l'host che si desidera SSH a . La maggior parte delle distribuzioni Linux ha uno strumento ssh-copy-idper fare questo:

claudius:~$ ssh-copy-id caligula.dinomite.net
Now try logging into the machine, with "ssh 'caligula.dinomite.net'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Se la tua distribuzione non lo possiede, allora dovresti copiare la chiave nell'host di destinazione e aggiungerla al .ssh/authorized_keysfile (possibilmente esistente) :

claudius:~$ scp .ssh/id_dsa.pub caligula.dinomite.net:
id_dsa.pub                                    100% 1119     1.1KB/s   00:00
claudius:~$ ssh caligula.dinomite.net
Last login: Sat May  9 10:32:30 2009 from claudius.csh.rit.edu
Caligula:~$ cat id_dsa.pub >> .ssh/authorized_keys

Infine, per ottenere il massimo beneficio dalle chiavi SSH, dovrai eseguire un agente SSH. Se si utilizza un ambiente desktop (Gnome, KDE, ecc.), Semplicemente disconnettersi e riconnettersi avvierà un agente SSH per te. In caso contrario, è possibile aggiungere quanto segue al file di shell RC ( .bashrc, .profile, etc.):

SSHAGENT=/usr/bin/ssh-agent
SSHAGENTARGS="-s"
if [ -z "$SSH_AUTH_SOCK" -a -x "$SSHAGENT" ]; then
    eval `$SSHAGENT $SSHAGENTARGS`
trap "kill $SSH_AGENT_PID" 0
fi

1

Questo è inteso come una lista di controllo. Se uno lo segue punto per punto, dovrebbero essere coperti i gotcha più comuni agli accessi senza password. La maggior parte di questi punti sono menzionati altrove; questa è un'aggregazione.

Ci deve essere una ~/.sshdirectory chmod 700su ogni macchina sotto l'account che originerà o riceverà le connessioni.

La chiave (privata) deve essere generata senza una passphrase, oppure è possibile avviare un agente che conterrà una versione decrittografata di una chiave con passphrase che i client possano utilizzare. Inizia l'agente con ssh-agent $SHELL. È la $SHELLparte che mi ha impiegato un po 'di tempo a trovare. Vedi la pagina man in quanto ci sono molti dettagli se vuoi usare un agente.

Non dimenticare che per impostazione predefinita le chiavi deboli (<2048 bit DSA) non sono accettate dalle versioni recenti di sshd.

È necessario eseguire le seguenti operazioni sul computer lato client per creare una connessione.

  1. La chiave privata deve essere inserita ~/.ssh/id_rsao ~/.ssh/id_dsacome appropriato. È possibile utilizzare un altro nome, ma deve essere incluso in un'opzione -i nel comando ssh sul computer di origine per indicare esplicitamente la chiave privata.

  2. La tua chiave privata deve essere chmod 600.

  3. Verifica che la tua cartella principale sia chmod 700.

Ora per consentire a una macchina di ricevere una richiesta. Un modello comune è quello in cui un amministratore ti dà accesso a una macchina che non possiedi (come l'hosting web condiviso). Pertanto, l'idea con ssh è che offri la tua chiave pubblica a chiunque ti stia dando l'account. Ecco perché in genere non si inseriscono chiavi private sulla macchina che riceve richieste. Ma, se si desidera che anche questa macchina esegua ssh in uscita, è necessario trattare è come una macchina di origine con i passaggi precedenti.

  1. La chiave pubblica deve essere inserita in un file chiamato ~/.ssh/authorized_keyssotto l'account che riceverà le connessioni. Puoi inserire anche altre chiavi a cui è consentito connettersi tramite questo account. Una cosa particolarmente complicata se vi trovate in vi e incollate la chiave nel file dal buffer di incollaggio in PuTTY è questa: la chiave inizia con un "ssh-". Se non si è in modalità di inserimento, la prima "s" metterà vi in ​​modalità di inserimento e il resto della chiave avrà un bell'aspetto. Ma ti mancherà una "s" all'inizio della chiave. Ci sono voluti giorni per trovarlo.
  2. Mi piace chmod 600 ~/.ssh/authorized_keys. Deve essere almeno gw.
  3. Ora, è necessario aggiungere l'impronta digitale dell'host alla cache. Vai alla macchina A e ssh alla macchina B manualmente. La prima volta, riceverai una query del tipo "Vuoi aggiungere ... alla cache della chiave host?". Se si sta tentando di ottenere l'automazione (come uno script) per utilizzare questo accesso, è necessario assicurarsi che il client ssh utilizzato dall'automazione non ottenga questo prompt.

0

Come altri hanno già detto, i tuoi utenti dovrebbero creare autonomamente delle chiavi di sicurezza sui loro computer client con ssh-keygen e aggiungere la loro chiave pubblica a ~ / .ssh / authorized_keys sul computer a cui desiderano accedere.

Per informazioni più dettagliate, consiglio vivamente SSH, The Secure Shell .


0

Ci sono buoni consigli qui, quindi non lo ripeterò. Una volta configurato un server per consentirti di accedere con le chiavi, puoi configurare gli altri affinché facciano lo stesso con questo unico liner:

remote=server1 server2 server3 server4
for r in $remote; do echo connecting to $r; tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh $r "tar zxf -; chmod 700 .ssh" ; done

Basta cd nella home directory, definire la variabile remote come uno o più nomi di server e fare un sacco in una volta. La password richiesta sarà la password SSH per il server remoto. Ovviamente puoi usare una versione semplificata senza il for-loop:

tar czf - ./.ssh/id*.pub ./.ssh/authorized_keys2 ./.ssh/config | ssh YOUR_SERVER_NAME_HERE "tar ztvf -; chmod 700 .ssh"

RICORDA: copia solo sulle tue chiavi pubbliche. Non vuoi che le tue chiavi private siedano su un server in cui chiunque con sudo può copiarle e forzare brutalmente la tua passphrase.

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.