Heartbleed OpenSSL bug fix on Debian Wheezy

heartbleedFollowing the Debian Security Advisory DSA-2896-1 openssl — security update, a good practice would be to check wether your server is affected by the OpenSSL  Heartbleed security bug or not.

If you find your server affected by the bug, here are some few steps to  fix the problem on Debian Wheezy (but with slight changes you can use with other distros too).

As root:

aptitude update
aptitude upgrade libssl1.0.0
aptitude upgrade openssl

As you reboot you Apache or SSH servers, you will notice that  the bug is fixed, but the problem is still here, you private keys may be compromised, so it’s time to generate new secrets.

Apache

Let’s generate a new private key. First, let’s move to the ssl private keys directory:

cd /etc/ssl/private

Let’s issue:

openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr

So now we have a new private key and a csr  (certificate signing  request).

Time to strip the password from the private key:

cp server.key server.key.org
openssl rsa -in server.key.org -out server.key

And now, we self sign the certificate:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Have a look at your new certificate:

openssl x509 -in server.crt -text | less

Now let’s make everything readable just by root user, remember that we stripped the password from private key:

chmod o-r server*

Finally let’s copy the new public certificate to the right directory:

cp server.crt ../certs/

Do not forget to modify, if needed, the  entry for certificate  files in Apache conf :

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key

Now, restart Apache:

service apache2 restart

 

SSHD

For OpenSSH it’s way easier. First, we remove the old host keys:

rm /etc/ssh/ssh_host_*

Now  we reconfigure openssh-server package to generate new keys:

dpkg-reconfigure openssh-server

Finally, if dpkg-reconfigure did not, we restart SSH

service ssh restart

Autenticarsi con ssh senza password, qualche profilo e i comandi automatizzati

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?

keygen

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

History Time Format

Did you ever had a look at you bash history?

No? Well, try it issuing the following command:

root@moveaway: history
...
996  netstat -tapn
997  vi /etc/my.cnf
998  vi /etc/my.cnf
999  service mysql restart
1000  service mysqld restart
1001  history

Wow! One thousand (and one) commands issued on my laptop command line! Nice, insn’t it?

Well, ohhhh yess…but…mmm…when did I issue each command?

The default behaviour for the bash history file (.bash_history in your home directory), is to take note only of the commands, nothing else, as you can see “catting” the raw file:

root@moveaway: cat .bash_history
..
netstat -tapn
vi /etc/my.cnf
vi /etc/my.cnf
service mysql restart
service mysqld restart

Not that useful if you are trying to link some correlations from the commands you issued and what happened in your system. Better for you to timestamp you history log.

How to do it?

First, let’s pay attention to what

root@moveaway: man bash

tells us:

HISTTIMEFORMAT
If this variable is set and not null, its value is used as a format string for strftime(3) to print the time stamp associated with each his-
tory entry displayed by the history builtin. If this variable is set, time stamps are written to the history file so they may be preserved
across shell sessions.

So, setting the variable

HISTTIMEFORMAT

would give a relief to our concern. The syntax is similar the one you use for the command

date

so

man date

will help you to find a proper format string for this variable. Anyway, if you have no idea, here is a pre formatted variable (Year-Month-Day Hours:Minutes:Seconds)

HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "

This string alone won’t work, we have to “export” it as a environment variable:

export HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "

Mmm…let’s have a look to our history:

root@moveaway: history
997  2008-07-31 19:40:34 vi /etc/my.cnf
998  2008-07-31 19:40:34 vi /etc/my.cnf
999  2008-07-31 19:40:34 service mysql restart
1000  2008-07-31 19:40:34 service mysqld restart
1001  2008-07-31 19:40:37 history

Ouch! All the entries have the same date stamp! Well, to fix this we should exit the login session and logon again, but our environment variable would get lost. We must make it lasting through sessions. Let’s invoke the

man bash

command again:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the –login option, it first reads and executes commands from
the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order,
and reads and executes commands from the first one that exists and is readable.

Interesting. It’s time to edit the

/etc/profile

file and write the command in, to make it last:

export HISTTIMEFORMAT="%Y-%m-%d %H:%M:%S "

Save the file, exit the login session and logon again. Now issue some commands…

root@moveaway: prova_time_stamp_1
-bash: prova_time_stamp_1: command not found
root@moveaway: prova_time_stamp_2
-bash: prova_time_stamp_2: command not found
root@moveaway: prova_time_stamp_3
-bash: prova_time_stamp_3: command not found
root@moveaway: history

Well, not real commands, but they will be a good placeholder to mark the timestamps. Let’s issue

history

again:

1001  2008-07-31 19:42:46 prova_time_stamp_1
1002  2008-07-31 19:42:54 prova_time_stamp_2
1003  2008-07-31 19:43:00 prova_time_stamp_3
1004  2008-07-31 19:43:25 history

It works! Now our history is marked with a time stamp for each entry, so it will be easier to understand when a command has been issued. Let’s have a look to the

.bash_history

file, but since the file is fully written only after the login session is closed, logoff, logon again and then issue:

root@moveaway: cat .bash_history
...
#1217533366
prova_time_stamp_1
#1217533374
prova_time_stamp_2
#1217533366
prova_time_stamp_3
#1217533405
history

What’s that? Each command is prefixed by a Unix Timestamp, which is converted for you by the

history

command, otherwise you can use an online converter.

Good, isn’t it?

2 Cent Tip:

If you want your history file to take note of more than the standard 500 commands, put in the

profile

the following string:

export HISTSIZE=1000

You will have a 1000 commands worth history file.

Second 2 Cent Tip:

If you want more infos on the time syntax for

HISTTIMEFORMAT

have a look to

man 3 strftime

Blogsecurify, controlla la sicurezza del tuo WordPress

Date un’occhiata a un servizio online che potrebbe risultarvi utile, Blogsecurify. Controllo della versione del vostro WordPress, esame del template utilizzato dal vostro blog, alla ricerca di vulnerabilità, reperimento e visualizzazione della lista dei plugin installati. Ok, come potete vedere dall’immagine, ha rilevato ben poco, ma dare una passata al vostro blog con questo strumento, non è poi una cattiva idea.

Per attivare il controllo, dovrete “autenticare” Blogsecurify in uno dei seguenti modi:

  • Andate In Design, Editor e cliccate su Piè di pagina, quindi scorrete fino in fondo la text box e individuate l’ultima riga:
  • </body></html>

    e aggiungete prima di questa riga, la seguente istruzione:

    <!-- wpscanner -->

    Fatto questo, salvate le modifiche, tornate su Blogsecurify, inserite la vostra url nella text box e premete test!

  • In alternativa, scaricate il plugin, installatelo, attivatelo e lanciate il controllo.