Questo secondo passo è leggermente più complicato, ma quando viene combinato con il successivo, offre un considerevole aumento della protezione contro i tentativi automatici di rottura delle password. Il lato negativo è che gli utenti impiegheranno un po' più di tempo per creare chiavi cifrate prima di poter effettuare il login.

In Linux, un utente per creare coppie di chiavi cifrate può eseguire:

europa $ ssh-keygen -v -t rsa

Quando si esegue questo comando, si dovrebbe ottenere un output simile a questo:

Generating public/private rsa key pair.
Enter file in which to save the key (.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again: Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is: 2d:47:41:2d:5e:89:e7:10:85:31:36:f8:e6:e2:d4:23 jpm@europa

Assicurarsi di salvare i file generati nella directory .ssh che si trova nella propria home directory. Inoltre, anche se la passphrase è opzionale, assicurarsi di introdurne una (due volte). E senza barare scegliendone una troppo semplice! Meglio impegnarsi a crearne una composta da un bel mix di lettere, numeri e/o caratteri speciali.

Notare che nell'esempio sono state usate due opzioni per ssh-keygen. La prima è una -v per verbose. Non è necessaria, ma è sempre preferibile avere sott'occhio ciò che succede.

La seconda imposta il tipo di chiave. Un tempo l'algoritmo RSA era bloccato da brevetto, quindi la maggior parte degli utenti Linux sottolineavano il fatto che avrebbe dovuto essere usato DSA al suo posto. Il brevetto di RSA è scaduto il 21 settembre 2000, quindi da quella data non c'è più stato nessun problema per quanto riguarda il suo utilizzo. Ci sono anche alcune altre differenze, come il fatto che DSA è solo un algoritmo di sottoscrizione, mentre con RSA si possono tecnicamente anche cifrare dati (operazione non raccomandabile). Alcuni  sostengono inoltre che RSA impiega più tempo a generare chiavi rispetto  DSA... ma altri non sono d'accordo su questo punto. Quando le cose funzionano, la maggior parte delle persone semplicemente non se ne preoccupa.

(Sicuramente almeno un paio di crittografici si sono alquanto irritati leggendo quest'ultima affermazione!).

In Windows, si può usare l'utility PuTTYgen (docs) dal sito di PuTTY. Scaricare l'eseguibile (solo un file), ed eseguirlo.

Cliccare sul pulsante Generate, e muovere il mouse attraverso lo schermo per generare dati casuali, come indicano le istruzioni:

Una volta completata questa operazione, si avrà a disposizione una coppia di chiavi cifrate, una pubblica e una privata:

Cliccare sul pulsante Save Public Key, e salvare la chiave in un luogo adeguato. Per convenzione, alcuni la nominano id_rsa.pub. Cliccare poi il pulsante Save Private Key, e salvare la chiave. PuTTY raccomanda di usare nomi che finiscano in .ppk, per questo convenzionalmente si usa id_rsa.ppk. Ma i nomi dei file non hanno in realtà una grande importanza.

Sarà anche necessario cambiare l'impostazione per l'host remoto in PuTTY al fine di

• evitare login interattivi
• usare il file della chiave privata che è stato appena generato

Ciò può essere eseguito nella sezione SSH/Auth della configurazione:

europa $ cat id_rsa.pub | \ ssh jpm@metis "cat >> .ssh/authorized_keys"

In Windows, è invece forse più facile selezionare e copiare la versione testo della chiave da PuTTYgen, poi effettuare il login nel sistema remoto, creare il file authorized_keys e incollarlo all'interno di esso. Questo metodo funziona, ma non è l'unico.

Una volta che la chiave pubblica è stata aggiunta, è molto importante confermare il fatto che il login avviene senza una password! Di certo si vuole evitare di incasinare i login effettuati senza password, e poi disabilitare i login interattivi. Ciò che avverrebbe è che si rimarrebbe effettivamente bloccati al di fuori del proprio sistema...

europa $ ssh ganymede Last login: Sun Oct 29 22:44:33 2006 from europa ganymede $

Se, e solo se, tutto sembra funzionare, si può disabilitare il login interattivo attraverso la seguente linea di comando in sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no

Si può in alternativa disabilitare PAM assieme a "UsePAM no" ma ciò porterà alcuni problemi. Quindi è probabilmente consigliabile utilizzare le linee di comando presentate sopra.

Questo passo è però utile soprattutto se seguito dal seguente...