Il blog sull'informatica

Qualche tempo fa, mentre provavo ad abilitare l'SSH sul mio PIX 501, ho cercato di visualizzare il fingerprint che viene generato dopo aver creato la coppia di chiavi RSA pubblica/privata.

Con mio enorme stupore, dopo una breve ricerca su Internet e diversi tentativi da console, ho constatato che tale fingerprint non è visualizzabile direttamente dalla CLI del PIX.

L'unico comando presente da linea di comando è il seguente:

NightFirewall# sh ca mypubkey rsa

che consente di visualizzare la chiave pubblica usata dal firewall in questione, ma non il suo fingerprint.

Inoltre, dando un'occhiata al file .ssh/known_host presente nella mia home, ho notato che il fingerprint salvato è diverso da quelli associati agli host SSHv2. Questo a mio avviso è imputabile a due fattori:

1) L'uso di RSA1 anzichè RSA2 per la generazione del fingerprint stesso;

2) La versione del protocollo SSH utilizzata dal firewall (ovvero la 1.5).

Un modo per visualizzare il fingerprint del PIX 501 però esiste, e si basa su nmap:

nightfly@nightbox:~$ sudo nmap -sS -A <IP PIX 501>

Starting Nmap 5.00 ( http://nmap.org ) at 2011-09-05 20:30 CEST
Interesting ports on *.*.*.*:
Not shown: 998 closed ports
PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      Cisco SSH 1.25 (protocol 1.5)
|_ ssh-hostkey: 1024 **:**:**:**:6f:62:05:dd:a6:3b:43:1f:**:**:**:** (RSA1)

Mistero svelato.

PS: i lameri che volessero fare dei tentativi di exploit verso la mia macchina (poichè l'SSH 1.5 è palesemente vulnerabile), sappiano che tale servizio non è pubblicato all'esterno ed accetta connessioni solo da determinati host della rete interna. Ergo abbandonate qualunque idea bellicosa.

A presto.

Il protocollo SSH (acronimo si Secure SHell), viene utilizzato per stabilire una connessione cifrata con determinati host, in modo da ottenere accesso alla loro interfaccia a linea di comando (CLI).

Ora, l'accesso vero e proprio alla macchina remota può evvenire seguendo diverse strade, ad esempio mediante l'inserimento di opportune credenziali di accesso (username e password) oppure mediante uno scambio di chiavi (pubbliche). Quest'ultima modalità di accesso risulta estremamente utile quando un determinato host deve connettersi via SSH ad un altro in modo automatizzato (ad esempio attraverso un cronjob schedulato). Un caso molto diffuso riguarda l'upload via SCP dei log relativi ai vari dispositivi di rete direttamente sul logserver.

Vediamo ora come predisporre i nostri dispositivi per lo scambio automatico delle chiavi. Per prima cosa occorre generare, su ciascun host, una coppia di chiavi pubblica/privata (RSA a 2048 bit). E' possibile fare ciò mediante il comando:

nightfly@nightbox:~$ ssh-keygen

Durante la procedura di generazione delle chiavi è buona norma utilizzare una passphrase non vuota. Essa verrà adoperata per criptare la nostra chiave privata.

In particolare, la chiave pubblica verrà salvata all'interno del file id_rsa.pub nella direcotory nascosta .ssh presente nella home del nostro utente.

A questo punto connettiamoci all'host remoto via SSH in modo da aggiungere il suo fingerprint all'interno dei file known_hosts, anch'esso posizionato nella dir .ssh. Tale procedura si rende necessaria in quanto SSH prevede l'identificazione dell'host remoto e l'aggiunta esplicita (mediante popup di conferma) del suo fingerprint tra gli host fidati.

Una volta identificato l'host remoto occorre generare una coppia di chiavi anche su di esso. Il comando è del tutto identico a quello utilizzato sul notro PC.

Ora possiamo procedere con copia/incolla della nostra chiave pubblica sull'host remoto, salvandola all'interno del file authorized_keys, dopo averlo creato mediante il comando:

nightfly@nightbox:~/.ssh$ touch authorized_keys

e dopo avergli assegnato i permessi 600:

nightfly@nightbox:~/.ssh$ chmod 600 authorized_keys

Tale procedura va eseguita anche sul nostro PC, nel caso in cui dovesse essere il logserver ad effettuare una richiesta di connessione verso di noi. Ovviamente, in tal caso, all'interno del nostro file authorized_keys andrà copiata la chiave pubblica del server.

Attenzione: condizione necessaria affinchè tutto funzioni è che l'utente del nostro PC (che lancia la connessione SSH) e quello del logserver per il quale è stato definito il file authorized_key coincidano.

A presto.

PS: Grazie a Max per i prezioni suggerimenti.