{"id":1153,"date":"2011-04-09T18:05:01","date_gmt":"2011-04-09T17:05:01","guid":{"rendered":"http:\/\/www.zarrelli.org\/blog\/?p=1153"},"modified":"2011-04-09T18:34:23","modified_gmt":"2011-04-09T17:34:23","slug":"autenticarsi-con-ssh-senza-password","status":"publish","type":"post","link":"https:\/\/www.zarrelli.org\/blog\/autenticarsi-con-ssh-senza-password\/","title":{"rendered":"Autenticarsi con ssh senza password, qualche profilo e i comandi automatizzati"},"content":{"rendered":"

Password, che noia!<\/strong><\/h2>\n

 
\nQuando, 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.<\/p>\n

Lo stesso accade se si hanno troppi computer cui collegarsi: ricordare le password \u00e8 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.<\/p>\n

Ora, se non vogliamo incorrere nel pericolo di non ricordarci pi\u00f9 una password, oppure di utilizzarne di insicure, o anche di doverle scrivere in qualche portachiave elettronico, beh, allora, cosa fare?<\/p>\n

Semplice.<\/p>\n

Basta non utilizzare alcuna password.<\/p>\n

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.<\/p>\n

Vedremo quindi come creare delle chiavi di autenticazione che verranno scambiate fra il nostro account locale e quello remoto, il che ci consentir\u00e0 di autenticarci sull’host remoto senza dover ricordare alcuna password.<\/p>\n

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.<\/p>\n

Una chiave asimmetrica \u00e8, 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.<\/p>\n

Fermiamoci ora un attimo e introduciamo qualche attore in questo scenario:<\/p>\n

Computer locale<\/strong>: \u00e8 il computer dal quale tenter\u00f2 di autenticarmi su un host remoto (SALOTTO nel nostro esempio);<\/p>\n

Utente locale<\/strong>: \u00e8 l’utente il cui account useremo per accedere al computer locale (zarrelli, nel nostro esempio);<\/p>\n

Computer remoto<\/strong>: \u00e8 il computer in rete al quale tenter\u00f2 di collegarmi (giorgioz, nel nostro esempio);<\/p>\n

Utente remoto<\/strong>: \u00e8 l’utente il cui account useremo per accedere al computer remoto (zarrelli e giorgiossh, nel nostro esempio;<\/p>\n

Chiave privata:<\/strong> \u00e8 la chiave che non dovr\u00f2 MAI<\/strong> distribuire e che star\u00e0 sul computer locale (chiave.di.autenticazione.1, nel nostro esempio);<\/p>\n

Chiave pubblica<\/strong>: \u00e8 la chiave che distribuir\u00f2 sugli host\/account ai quali vorr\u00f2 collegarmi in remoto (chiave.di.autenticazione.1.pub, nel nostro esempio).<\/p>\n

Creiamo le nostre chiavi<\/strong><\/h2>\n

 <\/p>\n

Per prima cosa dobbiamo creare il nostro paio di chiavi pubblica e privata.
\nEntriamo nel nostro account locale, che nel mio caso \u00e8 zarrelli<\/strong>, e creiamo la directory che conterr\u00e0: le chiavi ssh:<\/p>\n

cd ~\r\nmkdir .ssh<\/pre>\n
e ora facciamo in modo che solo l’utente possa leggere, scrivere, entrare in questa directory:<\/p>\n
chmod 700 .ssh\r\nls -lah .ssh\r\ndrwx------   2 zarrelli zarrelli 4,0K 2011-04-09 13:30 \r\ndrwx--x--- 104 zarrelli zarrelli  24K 2011-04-09 13:12 ...<\/pre>\n
Entriamo nella nuova directory:<\/p>\n
cd .ssh<\/pre>\n
e ora utilizziamo ssh-keygen per creare le nostre nuove chiavi:<\/p>\n
ssh-keygen -b 2048 -C \"Chiave di accesso al server remoto\" -t rsa -f chiave.di.autenticazione.1 -N \"\"<\/pre>\n
Diamo un’occhiata alle varie opzioni:<\/p>\n
-b 2048, crea una chiave di 2048 bit di lunghezza. E’ una lunghezza considerata sicura;<\/p>\n
-C \u201cChiave di accesso al server remoto\u201d, \u00e8 un semplice commento mnemonico;<\/p>\n
-t rsa, indica il tipo di chiave, che pu\u00f2 essere rsa1 per connessioni ssh di protocollo 1, rsa e dsa per connessioni ssh di protocollo 2.<\/p>\n
-f  chiave.di.autenticazione.1, indica il nome dei file in cui verranno scritte le chiavi;<\/p>\n
-N \u201c\u201d, 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?<\/p>\n
\"keygen\"<\/p>\n
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<\/p>\n
VisualHostKey yes<\/pre>\n
Ora, dovremmo avere due chiavi, diamo un’occhiata in .ssh<\/p>\n
ls -lah ~\/.ssh\r\ntotale 56K\r\ndrwx------   2 zarrelli zarrelli 4,0K 2011-04-09 14:21 .\r\ndrwx--x--- 104 zarrelli zarrelli  24K 2011-04-09 13:58 ..\r\n-rw-------   1 zarrelli zarrelli 1,7K 2011-04-09 13:43 chiave.di.autenticazione.1\r\n-rw-r--r--   1 zarrelli zarrelli  416 2011-04-09 13:43 chiave.di.autenticazione.1.pub<\/pre>\n
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\u00f9 restrittivi per la chiave privata: questa non deve mai cadere in mano ad alcuno, n\u00e9 essere leggibile da un utente che non sia quello legittimo sulla macchina locale. <\/p>\n
Non va MAI<\/strong> messa su una macchina remota.<\/p>\n
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:<\/p>\n
ssh 192.168.0.9\r\nThe authenticity of host '192.168.0.9 (192.168.0.9)' can't be established.\r\nRSA key fingerprint is 5e:24:3a:33:22:7f:ac:a1:17:ac:dd:78:48:4f:0e:dc.\r\nAre you sure you want to continue connecting (yes\/no)? yes\r\nWarning: Permanently added '192.168.0.9' (RSA) to the list of known hosts.\r\nzarrelli@192.168.0.9's password:\r\nLinux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64<\/pre>\n
The programs included with the Debian GNU\/Linux system are free software;\r\nthe exact distribution terms for each program are described in the\r\nindividual files in \/usr\/share\/doc\/*\/copyright.<\/pre>\n
Debian GNU\/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\r\npermitted by applicable law.\r\nYou have new mail.\r\nLast login: Sat Apr  9 13:30:28 2011 from salotto.local<\/pre>\n
Notate la key fingerprint e il messaggio in cui il ci viene detto che la chiave rsa relativa all’host remoto verr\u00e0 inserita nella lista dei known hosts?<\/p>\n
Ok, diamo un’occhiata a .ssh del nostro computer locale, nel nostro account locale:<\/p>\n
ls -lah .ssh\/\r\ntotale 68K\r\ndrwx------   2 zarrelli zarrelli 4,0K 2011-04-09 14:29 .\r\ndrwx--x--- 104 zarrelli zarrelli  24K 2011-04-09 13:58 ..\r\n-rw-------   1 zarrelli zarrelli 1,7K 2011-04-09 13:43 chiave.di.autenticazione.1\r\n-rw-r--r--   1 zarrelli zarrelli  416 2011-04-09 13:43 chiave.di.autenticazione.1.pub\r\n-rw-r--r--   1 zarrelli zarrelli  442 2011-04-09 14:29 known_hosts<\/pre>\n
Notato il nuovo file known_hosts? Diamoci un'occhiata:<\/pre>\n
cat .ssh\/known_hosts<\/pre>\n
|1|7cgqnrktDWc6nlCotoulbASiTMM=|IdWT4iO3qLTJ6A5mEf0UhIIvgYs= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxW6c7w4gaiD1ypA6KAL8BbVLaik4lMmKTYamIq64LxfD0LbQXzGfsq2GU0I3oWbhvizZaKYxOjo6FRmRP\/tm1Ajush4wdLIBFw6UJ7EHsueukyb67AqfbDJ6WCotM2yGzTHmjyVxPE74aq7SpBdbk92kSGmEHZwn0+T3I0aIiZ59Bonce3o5IPMmkVNiQD+P7wiWrhjUgrvOmwz9SDllHkwQGAuMLw0+YMRxsvo9p1uz0wPYEJgl6wFa9ZWCP3zjJXrDJONZZ6RWD1gT2F\/M2Z8b2JdJ5tTZT6LqUUxOLpq73vX1knSVLEuf9dLPdzDRX658RtyVV0Hf0VNwOBJqB<\/pre>\n
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\u00e0 vi siete connessi almeno una volta, ssh hasher\u00e0 l’hostname cui tenterete di connettervi e cercher\u00e0 nel file known_hosts la relativa chiave pubblica associata all’host.<\/p>\n
Una breve controverifica con ssh-keyscan ci dar\u00e0 la conferma:<\/p>\n
ssh-keyscan rsa 192.168.0.9\r\n# 192.168.0.9 SSH-2.0-OpenSSH_5.5p1 Debian-6\r\n192.168.0.9 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxW6c7w4gaiD1ypA6KAL8BbVLaik4lMmKTYamIq64LxfD0LbQXzGfsq2GU0I3oWbhvizZaKYxOjo6FRmRP\/tm1Ajush4wdLIBFw6UJ7EHsueukyb67AqfbDJ6WCotM2yGzTHmjyVxPE74aq7SpBdbk92kSGmEHZwn0+T3I0aIiZ59Bonce3o5IPMmkVNiQD+P7wiWrhjUgrvOmwz9SDllHkwQGAuMLw0+YMRxsvo9p1uz0wPYEJgl6wFa9ZWCP3zjJXrDJONZZ6RWD1gT2F\/M2Z8b2JdJ5tTZT6LqUUxOLpq73vX1knSVLEuf9dLPdzDRX658RtyVV0Hf0VNwOBJqB<\/pre>\n
Guarda caso, ssh-keyscan non fa altro che raccogliere la chiave pubblica dell’host e, da quello che possiamo vedere, in known_hosts \u00e8 inserita proprio la chiave pubblica dell’host 192.168.0.9.<\/p>\n
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 \u00e8 cambiata e ci consente di capire se c’\u00e8 un qualche pericolo in vista.<\/p>\n
A questo punto, dobbiamo trasferire la chiave pubblica dal computer locale al computer remoto, autenticandovi con la password dell’utente remoto:<\/p>\n
zarrelli@SALOTTO:~\/.ssh$ ssh-copy-id -i chiave.di.autenticazione.1.pub zarrelli@192.168.0.9\r\nzarrelli@192.168.0.9's password:\r\nNow try logging into the machine, with \"ssh 'zarrelli@192.168.0.9'\", and check in:\r\n.ssh\/authorized_keys\r\nto make sure we haven't added extra keys that you weren't expecting.<\/pre>\n
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:<\/p>\n
zarrelli@SALOTTO:~\/.ssh$ ssh zarrelli@192.168.0.9\r\nLinux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64\r\nThe programs included with the Debian GNU\/Linux system are free software;\r\nthe exact distribution terms for each program are described in the\r\nindividual files in \/usr\/share\/doc\/*\/copyright.\r\nDebian GNU\/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\r\npermitted by applicable law.\r\nYou have new mail.\r\nLast login: Sat Apr  9 16:52:56 2011 from salotto.local\r\nzarrelli@giorgioz:~$<\/pre>\n
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):<\/p>\n
zarrelli@giorgioz:~\/.ssh$ ls -lah\r\ntotale 16K\r\ndrwx------  2 zarrelli zarrelli 4,0K  9 apr 16.59 .\r\ndrwxr-xr-x 78 zarrelli zarrelli 4,0K  9 apr 16.59 ..\r\n-rw-------  1 zarrelli zarrelli  416  9 apr 16.53 authorized_keys\r\n-rw-r--r--  1 zarrelli zarrelli 3,9K 15 mar 14.55 known_hosts<\/pre>\n
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:<\/p>\n
zarrelli@giorgioz:~\/.ssh$ cat authorized_keys\r\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDUX3+4gEUScWEnV3muzp0Mhr7KeNQTM1aYHEbfH6J+tL2Tb9euVslYUhA\/zM21wVKhvuXOzph+9w1P9ZF2bRDBa0tD5U3TXf4D6eylvBXNCeARGJCB0krvyVmgF5RaObYNJH9kBKt2Ih02QWe\/n\/axY\/SSEuRquUxaA27Bl+bRvxPivjQnAT3z1POeqUJBySBbJiNlE3upQjVzVn5w7jL35ZQVAJiOx0YbbCDlmNkYBDJtrtjuP4CrdenTJe7Xnzyruhrycs4xw5fHNhQcY00pbipA5sV8O6EQuNFdnxrnxZ2yHZGLQE+wVukK0M3sPWm8DqBE9dxq3pZ2y970UMQN Chiave di accesso al server remoto<\/pre>\n
Qui ritroviamo la chiave pubblica creata sul computer locale (SALOTTO). In realt\u00e0, 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.<\/p>\n
Ovviamente, potremmo esportare la chiave pubblica su ogni utente remoto che vorremo utilizzare per la connessione all’host in rete, baster\u00e0 poi utilizzare per il collegamento l’identificativo utente@host.<\/p>\n
Configuriamo i nostri profili<\/strong><\/h2>\n
 <\/p>\n
Simpatico, vero? Per\u00f2, c’\u00e8 un per\u00f2, con diversi utenti e diverse macchine, come fare a ricordarsi quale identit\u00e0 o quale chiave utilizzare, senza essere costretti a usare una chiave per tutto?<\/p>\n
Basta usare un file di configurazione. Ora, nella directory .ssh dell’utente locale create il file<\/p>\n
config<\/pre>\n
Al cui interno scriverete:<\/p>\n
Host  Nome_Configurazione\r\n      AddressFamily           inet\r\n      ConnectionAttempts      10\r\n      ForwardAgent            no\r\n      ForwardX11              no\r\n      ForwardX11Trusted       no\r\n      GatewayPorts            yes\r\n      HostBasedAuthentication no\r\n      HostKeyAlias            alias_della_chiave\r\n      HostName                nome_host\r\n      IdentityFile            ~\/.ssh\/chiave.di.autenticazione.1\r\n      PasswordAuthentication  no\r\n      Protocol                2\r\n      Compression             yes\r\n      CompressionLevel        9\r\n      ServerAliveCountMax     3\r\n      ServerAliveInterval     15\r\n      TCPKeepAlive            no\r\n      User                    utente_remoto<\/pre>\n
Premesso che il file config \u00e8 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:<\/p>\n
Host<\/pre>\n
In realt\u00e0…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.<\/p>\n
HostKeyAlias<\/pre>\n
Indica un alias da utilizzare quando si vuole registrare o ricercare la chiave di un host, in alternativa all’IP. In questo modo, quindi, \u00e8 possibile gestire pi\u00f9 chiavi per host differenti ospitati sullo stesso IP.<\/p>\n
HostName<\/pre>\n
Indica l’host name o l’indirizzo IP cui ci si vuole collegare.<\/p>\n
IdentityFile<\/pre>\n
Definisce quale \u00e8 il file da cui leggere la chiave privata che attesta l’identit\u00e0 dell’utente. Normalmente, se non indicato nulla, per il protocollo 1 il file \u00e8 ~\/.ssh\/identity,\u00a0mentre per il protocollo ssh 2 si usano ~\/.ssh\/id_rsa e ~\/.ssh\/id_dsa, a seconda del tipo di chiave creata.<\/p>\n
User<\/pre>\n
Indica con quale utente ci si vuole collegare all’host definito da questa configurazione.<\/p>\n
Visto che abbiamo qualche nozioni in pi\u00f9, usiamola per giocare e andiamo sul computer remoto per creare un nuovo utente:<\/p>\n
giorgioz:~# adduser --disabled-password giorgiossh\r\nAggiunta dell'utente \u00abgiorgiossh\u00bb ...\r\nAggiunta del nuovo gruppo \u00abgiorgiossh\u00bb (1001) ...\r\nAggiunta del nuovo utente \u00abgiorgiossh\u00bb (1001) con gruppo \u00abgiorgiossh\u00bb ...\r\nCreazione della directory home \u00ab\/home\/giorgiossh\u00bb ...\r\nCopia dei file da \u00ab\/etc\/skel\u00bb ...\r\nModifica delle informazioni relative all'utente giorgiossh\r\nInserire il nuovo valore o premere INVIO per quello predefinito\r\n\tNome completo []: Giorgio Zarrelli\r\n\tStanza n\u00b0 []: 1\r\n\tNumero telefonico di lavoro []: 12345\r\n\tNumero telefonico di casa []: 123456\r\n\tAltro []:\r\nLe informazioni sono corrette? [S\/n]<\/pre>\n
L’utente non pu\u00f2 essere usato con autenticazione via password, visto che abbiamo abilitato esplicitamente il supporto a questa funzionalit\u00e0, quindi non potremo utilizzare ssh-copy-id per fare il lavoro sporco. Nessun problema, qualche un cp e un chown aggiusteranno tutto:<\/p>\n
cp -R \/home\/zarrelli\/.ssh\/ \/home\/giorgiossh\/ ; chown -R giorgiossh. \/home\/giorgiossh\/.ssh\/<\/pre>\n
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\u00e0 dell’utente giorgiossh.<\/p>\n
Non ci rimane che tornare indietro sul computer locale e mettere mano al nostro file config:<\/p>\n
Host  zarrelli\r\n      AddressFamily           inet\r\n      ConnectionAttempts      10\r\n      ForwardAgent            no\r\n      ForwardX11              no\r\n      ForwardX11Trusted       no\r\n      GatewayPorts            yes\r\n      HostBasedAuthentication no\r\n      HostKeyAlias            chiave_zarrelli\r\n      HostName                192.168.0.9\r\n      IdentityFile            ~\/.ssh\/chiave.di.autenticazione.1\r\n      PasswordAuthentication  no\r\n      Protocol                2\r\n      Compression             yes\r\n      CompressionLevel        9\r\n      ServerAliveCountMax     3\r\n      ServerAliveInterval     15\r\n      TCPKeepAlive            no\r\n      User                    zarrelli<\/pre>\n
Host  giorgiossh\r\n      AddressFamily           inet\r\n      ConnectionAttempts      10\r\n      ForwardAgent            no\r\n      ForwardX11              no\r\n      ForwardX11Trusted       no\r\n      GatewayPorts            yes\r\n      HostBasedAuthentication no\r\n      HostKeyAlias            chiave_giorgiossh\r\n      HostName                192.168.0.9\r\n      IdentityFile            ~\/.ssh\/chiave.di.autenticazione.1\r\n      PasswordAuthentication  no\r\n      Protocol                2\r\n      Compression             yes\r\n      CompressionLevel        9\r\n      ServerAliveCountMax     3\r\n      ServerAliveInterval     15\r\n      TCPKeepAlive            no\r\n      User                    giorgiossh<\/pre>\n
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\u00e0 registrata e cercata come chiave_zarrelli e l’utente con cui collegarsi al sistema remoto \u00e8 zarrelli. Per la configurazione giorgiossh, abbiamo fatto quasi lo stesso, indicando chiave_giorgiossh come alias e giorgio.ssh come utente.<\/p>\n
Beh, ora non rimane che provare a collegarsi all’host remoto indicando non pi\u00f9 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:<\/p>\n
zarrelli@SALOTTO:~\/.ssh$ ssh zarrelli\r\nThe authenticity of host 'chiave_zarrelli (192.168.0.9)' can't be established.\r\nRSA key fingerprint is 5e:24:3a:33:22:7f:ac:a1:17:ac:dd:78:48:4f:0e:dc.\r\nAre you sure you want to continue connecting (yes\/no)? yes\r\nWarning: Permanently added 'chiave_zarrelli<\/strong>' (RSA) to the list of known hosts.\r\nLinux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64<\/pre>\n
The programs included with the Debian GNU\/Linux system are free software;\r\nthe exact distribution terms for each program are described in the\r\nindividual files in \/usr\/share\/doc\/*\/copyright.<\/pre>\n
Debian GNU\/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\r\npermitted by applicable law.\r\nYou have new mail.\r\nLast login: Sat Apr  9 18:08:18 2011 from salotto.local\r\nzarrelli<\/strong>@giorgioz:~$<\/pre>\n
Bum! Siamo entrati sul computer remoto (@giorgioz), come utente zarrelli e la chiave \u00e8 stata registrata con l’alias chiave_zarrelli. Adesso proviamo con l’altra configurazione, giorgiossh:<\/p>\n
zarrelli@SALOTTO:~\/.ssh$ ssh giorgiossh\r\nThe authenticity of host 'chiave_giorgiossh (192.168.0.9)' can't be established.\r\nRSA key fingerprint is 5e:24:3a:33:22:7f:ac:a1:17:ac:dd:78:48:4f:0e:dc.\r\nAre you sure you want to continue connecting (yes\/no)? yes\r\nWarning: Permanently added 'chiave_giorgiossh<\/strong>' (RSA) to the list of known hosts.\r\nLinux giorgioz 2.6.37-zarrelli-1 #1 SMP Mon Jan 24 11:28:15 CET 2011 x86_64<\/pre>\n
The programs included with the Debian GNU\/Linux system are free software;\r\nthe exact distribution terms for each program are described in the\r\nindividual files in \/usr\/share\/doc\/*\/copyright.<\/pre>\n
Debian GNU\/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\r\npermitted by applicable law.\r\nLast login: Sat Apr  9 18:08:35 2011 from salotto.local\r\ngiorgiossh<\/strong>@giorgioz:~$<\/pre>\n
Opl\u00e0, eccoci dentro al computer remoto come utente giorgiossh la cui password, ricordiamo, \u00e8 stata bloccata al momento della creazione dell’utenza stessa.<\/p>\n
Da qui in poi, potete giocare a piacimento con il file di configurazione, le cui specifiche potrete leggere richiamando<\/p>\n
man ssh_config<\/pre>\n
Ma prima di finire, un ultimo giochino. Vedremo come giorgiossh ci torner\u00e0 utile per eseguire dei comandi automatizzati, senza che questi vengano indicati da linea di comando.<\/p>\n
Automatic lover!<\/strong><\/h2>\n
 <\/p>\n
Torniamo sull’host remoto (giorgioz) e apriamo il file<\/p>\n
authorized_keys<\/pre>\n
dell’utente<\/p>\n
giorgiossh<\/pre>\n
e modifichiamolo aggiungendo all’inizio della chiave preeseistente, i seguenti caratteri:<\/p>\n
command=\"htop\"<\/pre>\n
in modo che alla fine risulti in cos\u00ec:<\/p>\n
command=\"htop\" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDUX3+4gEUScWEnV3muzp0Mhr7KeNQTM1aYHEbfH6J+tL2Tb9euVslYUhA\/zM21wVKhvuXOzph+9w1P9ZF2bRDBa0tD5U3TXf4D6eylvBXNCeARGJCB0krvyVmgF5RaObYNJH9kBKt2Ih02QWe\/n\/axY\/SSEuRquUxaA27Bl+bRvxPivjQnAT3z1POeqUJBySBbJiNlE3upQjVzVn5w7jL35ZQVAJiOx0YbbCDlmNkYBDJtrtjuP4CrdenTJe7Xnzyruhrycs4xw5fHNhQcY00pbipA5sV8O6EQuNFdnxrnxZ2yHZGLQE+wVukK0M3sPWm8DqBE9dxq3pZ2y970UMQN Chiave di accesso al server remoto<\/pre>\n
Tutto su una riga, anche se la formattazione del blog potrebbe spezzare in pi\u00f9 parti la stringa.<\/p>\n
Proviamo a ricollegarci al computer remoto come giorgiossh:<\/p>\n
ssh giorgiossh<\/pre>\n
otterremo questo:<\/p>\n
\"\"<\/p>\n
E’ da notare che il comando \u00e8 vincolato, ovvero anche se si tenta di dare qualsiasi altra istruzione sulla linea di comando con cui si richiama la connessione, questa non verr\u00e0 eseguita. Volete saperne di pi\u00f9? 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:<\/p>\n
man 8 sshd<\/pre>\n","protected":false},"excerpt":{"rendered":"
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 \u00e8 quasi impossibile, a meno di …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31,57,62],"tags":[],"class_list":["post-1153","post","type-post","status-publish","format-standard","hentry","category-gnulinux","category-sicurezza","category-sysadmin","without-featured-image"],"_links":{"self":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/1153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/comments?post=1153"}],"version-history":[{"count":0,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/posts\/1153\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/media?parent=1153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/categories?post=1153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zarrelli.org\/blog\/wp-json\/wp\/v2\/tags?post=1153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}