Email: MailTo(fbiancini80@aol.com)

BR

VNC over SSH usando chiavi pubblica / privata

Introduzione

Lo scopo di questa guida è quello di:

• usare software VNC per l'amministrazione da remoto del proprio home computer. Impiegando un server VNC (ad esempio vino-server presente fin dalla prima installazione in Ubuntu) sulla propria macchina e tramite una opportuna password consentire ai client VNC (siano essi Windows, Unix che OS X), di ricevere una immagine dello schermo e di inviare input di tastiera e mouse al computer server. In pratica gestire il computer server da un'altra postazione, come se fosse il proprio home computer.
• Chiarire come configurare un server SSH sul proprio home computer usando solamente chiave pubblica e privata, sulla porta standard.
• Creare un tunnel instradando tutto il traffico VNC sulla connessione SSH.

Al termine di questo HowTo, saremo in grado di connettere al proprio home computer qualunque altro PC.

xxx

Perchè?

In realtà non c'è una ragione per crittare il traffico VNC dato che è codificato e molte volte crittato, e per poter sniffare il traffico l'attaccante dovrebbe avere accesso in entrambi i due computer connessi. Pertanto non ci sarebbe la necessità di crittare il traffico VNC, in ongni modo ci sono perlomeno un paio di buone ragioni per attuare questo metodo:

1. Incrementare la sicurezza. L'attaccante deve compromettere diversi livelli di sicurezza per banneggiare il sistema e l'SSH è un livello ulteriore.
2. Meno porte esterne aperte. Usando il metodo qui descritto, non c'è bisogno di lasciare il server VNC in ascolto sulle porte esterne ma solo su quelle interne (in altre parole il router può bloccare la porta 5900).
3. l'unico servizio che gli attaccanti possono cercare di sfruttare per compromettere la macchina è l'SSH ma usando un sistema a chiave pubblica/privata questo diventa davvero difficile, a meno che queste non ci vengano rubate.

Generalmente il protocollo VNC non è un protocollo crittato (può esserlo, ma questo non è un aspetto che tratterò nell'articolo). Questo significa che ogni pacchetto che attraversa Internet può essere intercettato (ad esempio mediante schede di rete funzionanati in modalità promiscua) e letto da chiunque utilizzi un packet sniffer. Un software scritto in Perl chiamato Chaosreader (http://www.brendangregg.com/chaosreader.html) permette lo sniffing del traffico e il replay dei caratteri digitati quasi in real time. Questa è la ragione per la quale effettuo un tunnel VNC over SSH.

Installazione di SSH

Per prima cosa installare OpenSSH client e server, da terminale digitare:

sudo apt-get install openssh-server openssh-client 

Generare Chiave Pubblica e Privata

Prima di impostare SSH per usare le chiavi pubblica e privata, dovremo crearne un nostro paio.

E' bene ricordare di non utilizzare una passphrase identica alla password usata per l'account root, altrimenti significherebbe fornire privilegi illimitati a colui che ne venisse in possesso. L'ssh-keygen suggerisce una passphrase di almeno 10 - 30 caratteri. Un modo semplice ma efficente per generare una passphrases è creare una frase strana e per strana intendo una frase che non abbia senso compiuto, ad esempio:

Saturno è in rotta di collisione con un pesce giallo che inciampa in un termosifone, mentre fuori ci sono 40 gradi di longiutudine.

Ora prendiamo la prima lettera di ogni parola punteggiatura compresa e creiamo la seguente stringa di caratteri:

Sèirdccupgciiut,mfcs4gdl.

Ora per rendere la frase un po più sicura possiamo convertire lettere in numeri e/o simboli, trasformare maiuscole in minuscole a piacimento, ad esempio:

s31rd77up9711ut,mfcsa9dl.

S: s
è: 3
i: 1
c: 7
g: 9
4: a

Questa è solo un'idea che mi piace usare, tuttavia qualunque altro modo di procedere può essere ritenuto valido

Torniamo alla generazione delle chiavi. Per prima cosa è opportuno creare una directory nella quale memorizzarle, dopodichè avvieremo ssh-keygen.

mkdir -p ~/.ssh
chmod 700 ~./ssh
cd ~/.ssh
ssh-keygen -t rsa

Dovrebbe apparire qualcosa di simile a questo:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/USER/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/USER/.ssh/id_rsa.
Your public key has been saved in /home/USER/.ssh/id_rsa.pub.
The key fingerprint is:

Ovviamente, USER deve essere rimpiazzato con l'attuale username. Ora la chiave privata è chiamata id_rsa e la chiave pubblica è id_rsa.pub. Quindi necessiteremo di entrambe le chiavi per effettuare il login. La chiave pubblica verrà conservata nella cartella nascosta nella directory dell'utente:

/home/user/.ssh/

Mentre la chiave privata verrà memorizzata su un dispositivo di memorizzazione portatile che poi l'utente può portare con se. Per conformarsi alla configurazione di default di un qualunque ssh server, dovremo allegare la chiave pubblica a un altro file:

cat ~/.ssh/id.pub >> authorized_keys
chmod 600 authorized_keys

Ora siamo pronti a configurare sshd

Configurazione demone SSH

Before we configure the ssh server, we have a couple of things to think about. First is where you're going to be connected to your computer from. Work? School? The local Starbucks? Now ask yourself, do they allow outbound connections on any port? If you're at school or work, the answer is mostly likely no. My school blocks all outbound ports <1024 (except for DNS, HTTP and HTTPS of course), but the higher number unassigned ports they tend to leave open. For instance, they block port 5900 (VNC), but they do not block port 47000 (unassigned).

This is important information because we need to know what port to set up our ssh server on so that we CAN connect to it, no matter what. Here are some good guidelines (they don't apply in all situations of course)

• High numbered ports (>1024) are blocked less than low ports (privileged ports)

• Some ports will almost always be open, like HTTP (80) and HTTPS (443). If all else fails, try running your SSH server on one of those.
• Last but not least, port 53 (DNS) will always be open.

I run a web server on port 80, with SSL on port 443, so those options are out for me. So i chose a high numbered port (specifically 47000), and I have not had problems connecting from anywhere *yet*.

Now we're going to set SSH up to be a little more secure, and possibly to help us bypass any filters your school/work has set up.

First, let's make a backup of our SSH configuration (which we're going to change), in case anything goes wrong.

CategoryHomepage