Risposte:
Per ogni utente: dovrebbero generare (sulla loro macchina locale) la loro coppia di chiavi usando ssh-keygen -t rsa
( rsa
possono essere sostituiti con dsa
o rsa1
anche, anche se quelle opzioni non sono raccomandate). Quindi devono inserire il contenuto della loro chiave pubblica ( id_rsa.pub
) ~/.ssh/authorized_keys
sul server in cui si è effettuato l'accesso.
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.
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
Questo è abbastanza straight-forward per fare - c'è una guida semplice per essere trovato qui .
I punti principali sono:
ssh-keygen
sulla tua macchina. Ciò genererà per te chiavi pubbliche e private.~/.ssh/id_rsa.pub
) ~/.ssh/authorized_keys
sul 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.
Per gli utenti di Windows installare stucco
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-id
per 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_keys
file (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
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 ~/.ssh
directory chmod 700
su 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 $SHELL
parte 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.
La chiave privata deve essere inserita ~/.ssh/id_rsa
o ~/.ssh/id_dsa
come 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.
La tua chiave privata deve essere chmod 600
.
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.
~/.ssh/authorized_keys
sotto 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.chmod 600 ~/.ssh/authorized_keys
. Deve essere almeno gw.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 .
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.