Password, che noia!
Quando, per una ragione o l’altra, ci ritrova troppo spesso o troppe poche volte, a collegarsi a un host remoto via shh, indicare o ricordare una password diventa un’operazione noiosa, difficile, impossibile.
Lo stesso accade se si hanno troppi computer cui collegarsi: ricordare le password è quasi impossibile, a meno di abbassare i livelli di sicurezza e utilizzarne una per tutti, oppure impiegare termini banali, o anche troppo correlati a una qualche caratteristica dell’utilizzatore.
Ora, se non vogliamo incorrere nel pericolo di non ricordarci più una password, oppure di utilizzarne di insicure, o anche di doverle scrivere in qualche portachiave elettronico, beh, allora, cosa fare?
Semplice.
Basta non utilizzare alcuna password.
Sia inteso. Non vogliamo dire di lasciare l’account aperto, solo lo proteggeremo in maniera differente, utilizzando delle chiavi di autenticazione che verranno scambiate fra il nostro account locale e quello remoto.
Vedremo quindi come creare delle chiavi di autenticazione che verranno scambiate fra il nostro account locale e quello remoto, il che ci consentirà di autenticarci sull’host remoto senza dover ricordare alcuna password.
Ci avvarremo quindi dei benefici delle chiavi asimmetriche, senza addentrarci troppo nei tecnicismi della crittografia. Per ora, immaginatevi che una chiave asimmetrica sia come uno di quelle medagliette da innamorati in cui un cuore viene spezzato in due parti in maniera irregolare: solo le due parti originali potranno ricostituire la versione integrale dello schema, tutte le altre combinazioni non saranno accettate.
Una chiave asimmetrica è, schematizzando all’osso, qualcosa di simile: due differenti parti, una chiave pubblica e una chiave privata esclusive, generate insieme e uniche in grado di combaciare l’una con l’altra.
Fermiamoci ora un attimo e introduciamo qualche attore in questo scenario:
Computer locale: è il computer dal quale tenterò di autenticarmi su un host remoto (SALOTTO nel nostro esempio);
Utente locale: è l’utente il cui account useremo per accedere al computer locale (zarrelli, nel nostro esempio);
Computer remoto: è il computer in rete al quale tenterò di collegarmi (giorgioz, nel nostro esempio);
Utente remoto: è l’utente il cui account useremo per accedere al computer remoto (zarrelli e giorgiossh, nel nostro esempio;
Chiave privata: è la chiave che non dovrò MAI distribuire e che starà sul computer locale (chiave.di.autenticazione.1, nel nostro esempio);
Chiave pubblica: è la chiave che distribuirò sugli host/account ai quali vorrò collegarmi in remoto (chiave.di.autenticazione.1.pub, nel nostro esempio).
Creiamo le nostre chiavi
Per prima cosa dobbiamo creare il nostro paio di chiavi pubblica e privata.
Entriamo nel nostro account locale, che nel mio caso è zarrelli, e creiamo la directory che conterrà: le chiavi ssh:
cd ~
mkdir .ssh
e ora facciamo in modo che solo l’utente possa leggere, scrivere, entrare in questa directory:
chmod 700 .ssh
ls -lah .ssh
drwx------ 2 zarrelli zarrelli 4,0K 2011-04-09 13:30
drwx--x--- 104 zarrelli zarrelli 24K 2011-04-09 13:12 ...
Entriamo nella nuova directory:
cd .ssh
e ora utilizziamo ssh-keygen per creare le nostre nuove chiavi:
ssh-keygen -b 2048 -C "Chiave di accesso al server remoto" -t rsa -f chiave.di.autenticazione.1 -N ""
Diamo un’occhiata alle varie opzioni:
-b 2048, crea una chiave di 2048 bit di lunghezza. E’ una lunghezza considerata sicura;
-C “Chiave di accesso al server remoto”, è un semplice commento mnemonico;
-t rsa, indica il tipo di chiave, che può essere rsa1 per connessioni ssh di protocollo 1, rsa e dsa per connessioni ssh di protocollo 2.
-f chiave.di.autenticazione.1, indica il nome dei file in cui verranno scritte le chiavi;
-N “”, indica la password con cui proteggere la chiave. Nel nostro caso, lasciamo due apici consecutivi, in modo da non impostare alcuna password. Stiamo cercando di farne a meno, giusto?
Notate la ASCII art? E’ nient’altro che una rappresentazione casuale della vostra chiave. Se non vi appare, ptete sempre abilitarla nella configurazione di ssh, tramite la voce
VisualHostKey yes
Ora, dovremmo avere due chiavi, diamo un’occhiata in .ssh
ls -lah ~/.ssh
totale 56K
drwx------ 2 zarrelli zarrelli 4,0K 2011-04-09 14:21 .
drwx--x--- 104 zarrelli zarrelli 24K 2011-04-09 13:58 ..
-rw------- 1 zarrelli zarrelli 1,7K 2011-04-09 13:43 chiave.di.autenticazione.1
-rw-r--r-- 1 zarrelli zarrelli 416 2011-04-09 13:43 chiave.di.autenticazione.1.pub
Bene, la chiave privata “chiave.di.autenticazione.1” e la chiave pubblica “chiave.di.autenticazione.1.pub” sono al loro posto e date un’occhiata ai permessi, più restrittivi per la chiave privata: questa non deve mai cadere in mano ad alcuno, né essere leggibile da un utente che non sia quello legittimo sulla macchina locale.
Non va MAI messa su una macchina remota.
Ci siamo quasi, ora la chiave pubblica va copiata sull’host remoto cui vogliamo collegarci. Per prima cosa, connettiamoci all’account remoto usando le solite password e vediamo se l’utente ha una directory .ssh:
ssh 192.168.0.9
The authenticity of host '192.168.0.9 (192.168.0.9)' can't be established.
RSA key fingerprint is 5e:24:3a:33:22:7f:ac:a1:17:ac:dd:78:48:4f:0e:dc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.9' (RSA) to the list of known hosts.
zarrelli@192.168.0.9's password:
Linux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sat Apr 9 13:30:28 2011 from salotto.local
Notate la key fingerprint e il messaggio in cui il ci viene detto che la chiave rsa relativa all’host remoto verrà inserita nella lista dei known hosts?
Ok, diamo un’occhiata a .ssh del nostro computer locale, nel nostro account locale:
ls -lah .ssh/
totale 68K
drwx------ 2 zarrelli zarrelli 4,0K 2011-04-09 14:29 .
drwx--x--- 104 zarrelli zarrelli 24K 2011-04-09 13:58 ..
-rw------- 1 zarrelli zarrelli 1,7K 2011-04-09 13:43 chiave.di.autenticazione.1
-rw-r--r-- 1 zarrelli zarrelli 416 2011-04-09 13:43 chiave.di.autenticazione.1.pub
-rw-r--r-- 1 zarrelli zarrelli 442 2011-04-09 14:29 known_hosts
Notato il nuovo file known_hosts? Diamoci un'occhiata:
cat .ssh/known_hosts
|1|7cgqnrktDWc6nlCotoulbASiTMM=|IdWT4iO3qLTJ6A5mEf0UhIIvgYs= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxW6c7w4gaiD1ypA6KAL8BbVLaik4lMmKTYamIq64LxfD0LbQXzGfsq2GU0I3oWbhvizZaKYxOjo6FRmRP/tm1Ajush4wdLIBFw6UJ7EHsueukyb67AqfbDJ6WCotM2yGzTHmjyVxPE74aq7SpBdbk92kSGmEHZwn0+T3I0aIiZ59Bonce3o5IPMmkVNiQD+P7wiWrhjUgrvOmwz9SDllHkwQGAuMLw0+YMRxsvo9p1uz0wPYEJgl6wFa9ZWCP3zjJXrDJONZZ6RWD1gT2F/M2Z8b2JdJ5tTZT6LqUUxOLpq73vX1knSVLEuf9dLPdzDRX658RtyVV0Hf0VNwOBJqB
Si tratta di una impronta crittografata con un algoritmo di hashing, basata sull’hostname e indirizzo IP del computer remoto. In questo modo, quando vi collegherete a un computer remoto cui già vi siete connessi almeno una volta, ssh hasherà l’hostname cui tenterete di connettervi e cercherà nel file known_hosts la relativa chiave pubblica associata all’host.
Una breve controverifica con ssh-keyscan ci darà la conferma:
ssh-keyscan rsa 192.168.0.9
# 192.168.0.9 SSH-2.0-OpenSSH_5.5p1 Debian-6
192.168.0.9 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxW6c7w4gaiD1ypA6KAL8BbVLaik4lMmKTYamIq64LxfD0LbQXzGfsq2GU0I3oWbhvizZaKYxOjo6FRmRP/tm1Ajush4wdLIBFw6UJ7EHsueukyb67AqfbDJ6WCotM2yGzTHmjyVxPE74aq7SpBdbk92kSGmEHZwn0+T3I0aIiZ59Bonce3o5IPMmkVNiQD+P7wiWrhjUgrvOmwz9SDllHkwQGAuMLw0+YMRxsvo9p1uz0wPYEJgl6wFa9ZWCP3zjJXrDJONZZ6RWD1gT2F/M2Z8b2JdJ5tTZT6LqUUxOLpq73vX1knSVLEuf9dLPdzDRX658RtyVV0Hf0VNwOBJqB
Guarda caso, ssh-keyscan non fa altro che raccogliere la chiave pubblica dell’host e, da quello che possiamo vedere, in known_hosts è inserita proprio la chiave pubblica dell’host 192.168.0.9.
A cosa ci torna utile? Beh, questa opzione, abilitata dalla keyword HashKnownHosts nel file di configurazione di sshd, ci permette di rilevare se la host key pubblica di un host è cambiata e ci consente di capire se c’è un qualche pericolo in vista.
A questo punto, dobbiamo trasferire la chiave pubblica dal computer locale al computer remoto, autenticandovi con la password dell’utente remoto:
zarrelli@SALOTTO:~/.ssh$ ssh-copy-id -i chiave.di.autenticazione.1.pub zarrelli@192.168.0.9
zarrelli@192.168.0.9's password:
Now try logging into the machine, with "ssh 'zarrelli@192.168.0.9'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Ora, dato che la mia macchina locale si chiama SALOTTO e quella remota 192.168.0.9, provo a collegarmi dalla macchina locale a quella remota, usando l’utente zarrelli e SENZA fornire alcuna password:
zarrelli@SALOTTO:~/.ssh$ ssh zarrelli@192.168.0.9
Linux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sat Apr 9 16:52:56 2011 from salotto.local
zarrelli@giorgioz:~$
BINGO! Sono entrato nell’host “giorgioz”, all’indirizzo IP 192.168.0.9 come utente zarrelli, senza che mi venisse richiesta alcuna password. Andiamo a dare un’altra occhiata alla directory .ssh sul computer remoto (giorgioz):
zarrelli@giorgioz:~/.ssh$ ls -lah
totale 16K
drwx------ 2 zarrelli zarrelli 4,0K 9 apr 16.59 .
drwxr-xr-x 78 zarrelli zarrelli 4,0K 9 apr 16.59 ..
-rw------- 1 zarrelli zarrelli 416 9 apr 16.53 authorized_keys
-rw-r--r-- 1 zarrelli zarrelli 3,9K 15 mar 14.55 known_hosts
E’ apparso un nuovo file, authorized_keys, il quale contiene le chiavi pubbliche degli utenti autorizzati a connettersi a questo account. Diamo uno sguardo al suo contenuto:
zarrelli@giorgioz:~/.ssh$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDUX3+4gEUScWEnV3muzp0Mhr7KeNQTM1aYHEbfH6J+tL2Tb9euVslYUhA/zM21wVKhvuXOzph+9w1P9ZF2bRDBa0tD5U3TXf4D6eylvBXNCeARGJCB0krvyVmgF5RaObYNJH9kBKt2Ih02QWe/n/axY/SSEuRquUxaA27Bl+bRvxPivjQnAT3z1POeqUJBySBbJiNlE3upQjVzVn5w7jL35ZQVAJiOx0YbbCDlmNkYBDJtrtjuP4CrdenTJe7Xnzyruhrycs4xw5fHNhQcY00pbipA5sV8O6EQuNFdnxrnxZ2yHZGLQE+wVukK0M3sPWm8DqBE9dxq3pZ2y970UMQN Chiave di accesso al server remoto
Qui ritroviamo la chiave pubblica creata sul computer locale (SALOTTO). In realtà, ssh-copy-id ha fatto un lavoro che potremmo eseguire noi a mano, ovvero ha creato nella directory .ssh dell’utente con cui vogliamo entrare nell’host remoto un file authorized_keys e poi vi ha copiato all’interno il contenuto della chiave pubblica chiave.di.autenticazione.1.pub.
Ovviamente, potremmo esportare la chiave pubblica su ogni utente remoto che vorremo utilizzare per la connessione all’host in rete, basterà poi utilizzare per il collegamento l’identificativo utente@host.
Configuriamo i nostri profili
Simpatico, vero? Però, c’è un però, con diversi utenti e diverse macchine, come fare a ricordarsi quale identità o quale chiave utilizzare, senza essere costretti a usare una chiave per tutto?
Basta usare un file di configurazione. Ora, nella directory .ssh dell’utente locale create il file
config
Al cui interno scriverete:
Host Nome_Configurazione
AddressFamily inet
ConnectionAttempts 10
ForwardAgent no
ForwardX11 no
ForwardX11Trusted no
GatewayPorts yes
HostBasedAuthentication no
HostKeyAlias alias_della_chiave
HostName nome_host
IdentityFile ~/.ssh/chiave.di.autenticazione.1
PasswordAuthentication no
Protocol 2
Compression yes
CompressionLevel 9
ServerAliveCountMax 3
ServerAliveInterval 15
TCPKeepAlive no
User utente_remoto
Premesso che il file config è valido solo per l’utente locale, mentre se vogliamo che le direttive indicate al suo interno ricadano su tutti gli utenti di sistema dovremo aggiungere le precedenti righe al file /etc/ssh/ssh_config (aggiustate il tiro per le varie distro e OS), fermiamoci per un attimo a esaminare le principali fra le direttive appena scritte:
Host
In realtà…non si riferisce ad alcun host. Indica semplicemente l’inizio di un insieme di direttive che arrivano fino al successivo “Host” e che compongono una configurazione. Date un nome a piacere.
HostKeyAlias
Indica un alias da utilizzare quando si vuole registrare o ricercare la chiave di un host, in alternativa all’IP. In questo modo, quindi, è possibile gestire più chiavi per host differenti ospitati sullo stesso IP.
HostName
Indica l’host name o l’indirizzo IP cui ci si vuole collegare.
IdentityFile
Definisce quale è il file da cui leggere la chiave privata che attesta l’identità dell’utente. Normalmente, se non indicato nulla, per il protocollo 1 il file è ~/.ssh/identity, mentre per il protocollo ssh 2 si usano ~/.ssh/id_rsa e ~/.ssh/id_dsa, a seconda del tipo di chiave creata.
User
Indica con quale utente ci si vuole collegare all’host definito da questa configurazione.
Visto che abbiamo qualche nozioni in più, usiamola per giocare e andiamo sul computer remoto per creare un nuovo utente:
giorgioz:~# adduser --disabled-password giorgiossh
Aggiunta dell'utente «giorgiossh» ...
Aggiunta del nuovo gruppo «giorgiossh» (1001) ...
Aggiunta del nuovo utente «giorgiossh» (1001) con gruppo «giorgiossh» ...
Creazione della directory home «/home/giorgiossh» ...
Copia dei file da «/etc/skel» ...
Modifica delle informazioni relative all'utente giorgiossh
Inserire il nuovo valore o premere INVIO per quello predefinito
Nome completo []: Giorgio Zarrelli
Stanza n° []: 1
Numero telefonico di lavoro []: 12345
Numero telefonico di casa []: 123456
Altro []:
Le informazioni sono corrette? [S/n]
L’utente non può essere usato con autenticazione via password, visto che abbiamo abilitato esplicitamente il supporto a questa funzionalità, quindi non potremo utilizzare ssh-copy-id per fare il lavoro sporco. Nessun problema, qualche un cp e un chown aggiusteranno tutto:
cp -R /home/zarrelli/.ssh/ /home/giorgiossh/ ; chown -R giorgiossh. /home/giorgiossh/.ssh/
Cosa abbiamo fatto? Semplice, abbiamo copiato la directory .ssh dall’utente zarrelli all’utente giorgiossh (siamo diventati utente root per farlo), quindi abbiamo reso la directory di destinazione e i file in essa contenuti di proprietà dell’utente giorgiossh.
Non ci rimane che tornare indietro sul computer locale e mettere mano al nostro file config:
Host zarrelli
AddressFamily inet
ConnectionAttempts 10
ForwardAgent no
ForwardX11 no
ForwardX11Trusted no
GatewayPorts yes
HostBasedAuthentication no
HostKeyAlias chiave_zarrelli
HostName 192.168.0.9
IdentityFile ~/.ssh/chiave.di.autenticazione.1
PasswordAuthentication no
Protocol 2
Compression yes
CompressionLevel 9
ServerAliveCountMax 3
ServerAliveInterval 15
TCPKeepAlive no
User zarrelli
Host giorgiossh
AddressFamily inet
ConnectionAttempts 10
ForwardAgent no
ForwardX11 no
ForwardX11Trusted no
GatewayPorts yes
HostBasedAuthentication no
HostKeyAlias chiave_giorgiossh
HostName 192.168.0.9
IdentityFile ~/.ssh/chiave.di.autenticazione.1
PasswordAuthentication no
Protocol 2
Compression yes
CompressionLevel 9
ServerAliveCountMax 3
ServerAliveInterval 15
TCPKeepAlive no
User giorgiossh
Cosa abbiamo fatto? Abbiamo creato due configurazioni per lo stesso host, una l’abbiamo chiamata zarrelli, l’altra giorgiossh. Poi, nella configurazione zarrelli abbiamo specificato che la chiave dell’host andrà registrata e cercata come chiave_zarrelli e l’utente con cui collegarsi al sistema remoto è zarrelli. Per la configurazione giorgiossh, abbiamo fatto quasi lo stesso, indicando chiave_giorgiossh come alias e giorgio.ssh come utente.
Beh, ora non rimane che provare a collegarsi all’host remoto indicando non più l’indirizzo ip ma il nome della configurazione che vogliamo caricare, la quale contiene tutte le informazioni che ci servono, dall’indirizzo ip, al certificato, all’utente remoto:
zarrelli@SALOTTO:~/.ssh$ ssh zarrelli
The authenticity of host 'chiave_zarrelli (192.168.0.9)' can't be established.
RSA key fingerprint is 5e:24:3a:33:22:7f:ac:a1:17:ac:dd:78:48:4f:0e:dc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'chiave_zarrelli' (RSA) to the list of known hosts.
Linux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sat Apr 9 18:08:18 2011 from salotto.local
zarrelli@giorgioz:~$
Bum! Siamo entrati sul computer remoto (@giorgioz), come utente zarrelli e la chiave è stata registrata con l’alias chiave_zarrelli. Adesso proviamo con l’altra configurazione, giorgiossh:
zarrelli@SALOTTO:~/.ssh$ ssh giorgiossh
The authenticity of host 'chiave_giorgiossh (192.168.0.9)' can't be established.
RSA key fingerprint is 5e:24:3a:33:22:7f:ac:a1:17:ac:dd:78:48:4f:0e:dc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'chiave_giorgiossh' (RSA) to the list of known hosts.
Linux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Apr 9 18:08:35 2011 from salotto.local
giorgiossh@giorgioz:~$
Oplà, eccoci dentro al computer remoto come utente giorgiossh la cui password, ricordiamo, è stata bloccata al momento della creazione dell’utenza stessa.
Da qui in poi, potete giocare a piacimento con il file di configurazione, le cui specifiche potrete leggere richiamando
man ssh_config
Ma prima di finire, un ultimo giochino. Vedremo come giorgiossh ci tornerà utile per eseguire dei comandi automatizzati, senza che questi vengano indicati da linea di comando.
Automatic lover!
Torniamo sull’host remoto (giorgioz) e apriamo il file
authorized_keys
dell’utente
giorgiossh
e modifichiamolo aggiungendo all’inizio della chiave preeseistente, i seguenti caratteri:
command="htop"
in modo che alla fine risulti in così:
command="htop" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDUX3+4gEUScWEnV3muzp0Mhr7KeNQTM1aYHEbfH6J+tL2Tb9euVslYUhA/zM21wVKhvuXOzph+9w1P9ZF2bRDBa0tD5U3TXf4D6eylvBXNCeARGJCB0krvyVmgF5RaObYNJH9kBKt2Ih02QWe/n/axY/SSEuRquUxaA27Bl+bRvxPivjQnAT3z1POeqUJBySBbJiNlE3upQjVzVn5w7jL35ZQVAJiOx0YbbCDlmNkYBDJtrtjuP4CrdenTJe7Xnzyruhrycs4xw5fHNhQcY00pbipA5sV8O6EQuNFdnxrnxZ2yHZGLQE+wVukK0M3sPWm8DqBE9dxq3pZ2y970UMQN Chiave di accesso al server remoto
Tutto su una riga, anche se la formattazione del blog potrebbe spezzare in più parti la stringa.
Proviamo a ricollegarci al computer remoto come giorgiossh:
ssh giorgiossh
otterremo questo:
E’ da notare che il comando è vincolato, ovvero anche se si tenta di dare qualsiasi altra istruzione sulla linea di comando con cui si richiama la connessione, questa non verrà eseguita. Volete saperne di più? Per esempio con quale variabile possiamo limitare la login da precisi indirizzi o hostname (from=”pattern-list”), o impostare variabili di ambiente (environment=”NAME=value”), date una sbirciatina alle opzioni di configurazione delle chiavi autorizzate con un bel:
man 8 sshd
