Dimensione: 4595
Commento:
|
Dimensione: 15488
Commento:
|
Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
Linea 3: | Linea 3: |
== Biancini Federico == | |
Linea 16: | Linea 15: |
#format wiki #language it |
##format wiki ##language it |
Linea 50: | Linea 49: |
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. Un semplice output di una sessione VCN mostra quasto: Code: {{{ VNC: 192.168.1.102:1096 -> 192.168.1.100:5900 File out_20070212-1601.log, Session 1 sudo cat /ectc/ oasshad password exit }}} Generally speaking VNC is an unencrypted protocol (it can be encrypted, but that's not the focus of this article). That means that any information you send over the internet can possibly be read by someone running a packet sniffer. There is a software package written in Perl called Chaosreader (http://www.brendangregg.com/chaosreader.html) which allows you to sniff for VNC traffic (and almost everything else) and replay keystrokes in almost real time. A sample output from a test VNC session shows this: |
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. ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Piccole/warning.png,,center)]] ||<style="padding:0.5em; border:none;">'''Fare sempre molta attenzione a come scegliere la password.''' || 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. ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Piccole/warning.png,,center)]] ||<style="padding:0.5em; border:none;">'''Attenzione, quanto segue deve essere fatto dall'utente che vuole effettuare il login tramite SSH, non dall'utente root!''' || {{{ 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 == Prima di configurare il server ssh abbiamo ancora un paio di cose su cui riflettere. Da dove ci connetteremo al nostro computer? Dal lavoro, da scuola ? Da dove ci connetteremo, permetteranno le connessioni verso l'esterno su qualunque porta? La risposta all'ultima domanda è probabilmente negativa. Nella mia università le connessioni in uscita sulle porte <1024 sono bloccate eccezion fatta per servizi quali DNS, HTTP, HTTPS ovviamente. Tuttavia le porte con alto valore tendono a non essere chiuse. Ovviamente la porta 5900 pur essendo >1024 viene tendenzialmente chiusa, ma una porta quale la 59000 non è bloccata. Queste informazioni sono molto importanti perchè noi dobbiamo conoscere su quale porta il server ssh deve restare in ascolto. Riporto alcune linee guida ovviamente da non applicare in tutte le sietuazioni: * le porte >1024 sono meno "bloccate" rispetto alle inferiori (privileged ports) * alcune porte sono quasi sempre aperte come la porta HTTP (80) HTTPS (443) etc. Se tutte le altre falliscono possiamo provare a raggiungere il nostro server SSH sfruttando una di queste. Ovviamente non è la soluzione migliore. * la porta del DNS (53) è sempre aperta. Nel mio caso ho un web server in ascolto sulla porta 80, sessione SSL sulla porta 443, quindi queste alternative non sono tali per me. A titolo d'esempio ho scelto la porta 59000. Stabilite delle linee guida possiamo ora modificare la configurazione di SSH per renderla un po più sicura, aggirando i filtri sulle porte per permettere la connessione da scuola o dal lavoro. === Backup sshd_config === Come primo passo facciamo un backup della configurazione di SSH: {{{ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.working }}} Ora usando {{{vi}}} o un qualunque altro editor, apriamo {{{/etc/ssh/sshd_config}}}. {{{ sudo vi /etc/ssh/sshd_config }}} Dobbiamo apportare alcuni cambiamenti. Anzitutto occorre trovale la linea: {{{ port 22 }}} porta di default sulla quale resta in ascolto il server SSH, occorre cambiarla per qualto detto precedentemente con: {{{ port 59000 }}} Assicuriamoci che non ci siano {{{#}}} prima del numero della porta. Ovviamente non dobbiamo necessariamente scegliere la porta 59000 ma ricordando quanto detto prima. === Disabilitiamo i login remoti con l'account di root === Per disabilitare i login remoti ocn l'account root cercare la riga: {{{ PermitRootLogin yes }}} cambiamo il {{{yes}}} con un {{{no}}}. Sebbene di default Ubuntu non abilita l'account di root, resta comunque una buona idea disabilitare il login da remoto con i permessi e priviligi disponibili all'account root. === Disabilitare la password anthentication === Disabiliteremo tutte le password authentication. Questa scelta è stata fatta per un paio di ragioni: * Non c'è metodo per crackare una password se questa non esiste * Facendo questo forziamo l'utente a usare la coppia di chiavi pubblica e privata create precedentemente per la sua autenticazione Cerchiamo la riga: {{{ #PasswordAuthentication yes }}} e cambiamola con: {{{ PasswordAuthentication no }}} Attenzione ho rimosso {{{#}}} Questo credo sia tutto ora riaviamo il server SSH: {{{ sudo /etc/init.d/ssh restart }}} === Configurare Remote Desktop VNC === Questo passo è davvero semplice. Usando il menu andare alla voce '''''System -> Preferences -> Remote Desktop'''''. Un dyalog box si aprirà, selezionare i seguenti check boxes: * Allow other users to view your desktop * Allow other users to control your desktop * Require the user to enter this password ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Grandi/info.png,,center)]] ||<style="padding:0.5em; border:none;">Ricordo di non selezionare il check box "Ask for your confirmation" altrimenti non sarà possibile accedere da remoto. Una buona idea è scegliere una password il più possibile robusta. || Selezionare close e vino-server è configurato. === Risolvere il problema dell'IP dinamico === ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5% ^>[[Immagine(Icone/Piccole/note.png,,center)]] ||<style="padding:0.5em; border:none;">''In questa guida si presuppone che l'utente abbia un IP dinamico.''|| A meno che non si abbia a disposizione un proprio domain name e configurato il proprio computer affinchè risolva le queries indirizzate ad esso e, a meno che non si paghi per avere un IP statico. Occorre servirsi degli strumenti che permettano di impostare un proprio hostname gratuitamente. Andare sul sito di DynDNS ad esempio [https://www.dyndns.com/services/dns/dyndns/], cercare la voce '''sign up for a "Free Dynamic DNS account"'''. Con questo ci viene permesso di creare un virtual domain name partendo da uno dei loro domini (ad esempio mycomputer.dyndns.org). In questo modo quando si vorrà connettersi al proprio computer da qualunque luogo, potremo semplicemente scrivere quell'indirizzo piuttosto che l'IP della nostra macchina che tra altro è dinamico. ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5% ^>[[Immagine(Icone/Piccole/note.png,,center)]] ||<style="padding:0.5em; border:none;">''A titolo informativo, c'è un client *nix che ha il compito di informare i server DynDNS di quando cambia IP la propria macchina lo si può reperire al seguente indirizzo [https://www.dyndns.com/support/clients/]. Non mi è mai capitato di usarlo in quanto il mio router svolge questa funzione internamente. In ogni modo ci sono diversi HowTo al loro sito.''|| === Portable Solutions === Per connettersi alla propria machcina da remoto analizzare ancora un paio di cose. * Aprire le porte del proprio router/firewall sulle queli il demone SSH resterà in ascolto (nel caso di questa guida la porta 59000). Una buona guida per questo è disponibile al seguente indirizzo [http://portforward.com/routers.htm] * Recuperare del software portabile, usabile sulle macchine Windows (le macchine *nix e Mac hanno SSH built in). Alcuni esempi di questo software sono: Putty: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html] Un fantastico strumento, appunto un ssh-client che rende usabile ssh su macchine Windows Puttygen: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html] Software necessario per trasformare la nostra chiave id_rsa nel formato usato da Putty `.ppk`. TightVNC Viewer: [http://www.tightvnc.com/download.html] Questo è un client per Windows (ne esiste anche una versione usabile per Linux). Ne esiste una versione `tightvnc-X.X.X_x86_viewer.zip` che non richiede di essere installata perrtanto una volta scompattata può essere copiata su un qualunque portable drive. Ovviamente di questo software esistono delle alternative più che valide come UltraVNC e RealVNC. Scelto il software da usare sul portable drive, dobbiamo: * Copiare la private key memorizzata sul nostro home computer (nella cartella ~/.ssh/) nel nostro portable drive (d'ora in poi USBdrive): {{{ sudo cp ~/.ssh/id_rsa /media/USBdrive/ }}} Fatto ciò occorre importare la chiave in Putty, ma per far questo avremo bisogno di `puttygen.exe` memorizzato in precedenza anchesso sull'USB drive Remember the file from above, named id_rsa? You're going to put this file on your USB drive, and import the key into PuTTY. To do that: * Avviare il file `puttygen.exe` sull'USB drive * Andare in '''''Conversions | Import Key''''' * Click sulla propria private key e inserire la propria passphrase * Aggiornare la key fingerprint * Salvare le chiavi usando '''''Save public key''''' e '''''Save private key''''' `puttygen.exe` genera un altra chiave pubblica. Questa è identica a quella memorizzata sul nostro home computer. ||<tablestyle="text-align: justify; width:100%; " style="border:none;" 5%>[[Immagine(Icone/Piccole/note.png,,center)]] ||<style="padding:0.5em; border:none;">''Da notare che è sempre possibile partendo dalla propria chiave privata ricostruire la propria chiave pubblica, ma non è possibile il contrario''.|| === Impostare PuTTY per il port forwarding === |
Email: MailTo(fbiancini80@aol.com)
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.
In questa guida si assume che l'utente abbia un router/firewall e che sappia come aprirne le porte. L'utente possa trasportare la propria chiave privata ad esempio tramite una penna USB o un CD o qualunque altro tipo di supporto dimemorizzazione mobile. |
Queste istruzioni sono state testate su Ubuntu Dapper e Edgy ma in teoria dovrebbero essere usabili su qualunque altra Linux box (ad esclusioni di specifici comandi, ovviamente). |
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:
- Incrementare la sicurezza. L'attaccante deve compromettere diversi livelli di sicurezza per banneggiare il sistema e l'SSH è un livello ulteriore.
- 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).
- 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.
Fare sempre molta attenzione a come scegliere la password. |
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.
Attenzione, quanto segue deve essere fatto dall'utente che vuole effettuare il login tramite SSH, non dall'utente root! |
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
Prima di configurare il server ssh abbiamo ancora un paio di cose su cui riflettere. Da dove ci connetteremo al nostro computer? Dal lavoro, da scuola ? Da dove ci connetteremo, permetteranno le connessioni verso l'esterno su qualunque porta? La risposta all'ultima domanda è probabilmente negativa. Nella mia università le connessioni in uscita sulle porte <1024 sono bloccate eccezion fatta per servizi quali DNS, HTTP, HTTPS ovviamente. Tuttavia le porte con alto valore tendono a non essere chiuse. Ovviamente la porta 5900 pur essendo >1024 viene tendenzialmente chiusa, ma una porta quale la 59000 non è bloccata.
Queste informazioni sono molto importanti perchè noi dobbiamo conoscere su quale porta il server ssh deve restare in ascolto.
Riporto alcune linee guida ovviamente da non applicare in tutte le sietuazioni:
le porte >1024 sono meno "bloccate" rispetto alle inferiori (privileged ports)
- alcune porte sono quasi sempre aperte come la porta HTTP (80) HTTPS (443) etc. Se tutte le altre falliscono possiamo provare a raggiungere il nostro server SSH sfruttando una di queste. Ovviamente non è la soluzione migliore.
- la porta del DNS (53) è sempre aperta.
Nel mio caso ho un web server in ascolto sulla porta 80, sessione SSL sulla porta 443, quindi queste alternative non sono tali per me. A titolo d'esempio ho scelto la porta 59000.
Stabilite delle linee guida possiamo ora modificare la configurazione di SSH per renderla un po più sicura, aggirando i filtri sulle porte per permettere la connessione da scuola o dal lavoro.
Backup sshd_config
Come primo passo facciamo un backup della configurazione di SSH:
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.working
Ora usando vi o un qualunque altro editor, apriamo /etc/ssh/sshd_config.
sudo vi /etc/ssh/sshd_config
Dobbiamo apportare alcuni cambiamenti. Anzitutto occorre trovale la linea:
port 22
porta di default sulla quale resta in ascolto il server SSH, occorre cambiarla per qualto detto precedentemente con:
port 59000
Assicuriamoci che non ci siano # prima del numero della porta. Ovviamente non dobbiamo necessariamente scegliere la porta 59000 ma ricordando quanto detto prima.
Disabilitiamo i login remoti con l'account di root
Per disabilitare i login remoti ocn l'account root cercare la riga:
PermitRootLogin yes
cambiamo il yes con un no. Sebbene di default Ubuntu non abilita l'account di root, resta comunque una buona idea disabilitare il login da remoto con i permessi e priviligi disponibili all'account root.
Disabilitare la password anthentication
Disabiliteremo tutte le password authentication. Questa scelta è stata fatta per un paio di ragioni:
- Non c'è metodo per crackare una password se questa non esiste
- Facendo questo forziamo l'utente a usare la coppia di chiavi pubblica e privata create precedentemente per la sua autenticazione
Cerchiamo la riga:
#PasswordAuthentication yes
e cambiamola con:
PasswordAuthentication no
Attenzione ho rimosso # Questo credo sia tutto ora riaviamo il server SSH:
sudo /etc/init.d/ssh restart
Configurare Remote Desktop VNC
Questo passo è davvero semplice. Usando il menu andare alla voce System -> Preferences -> Remote Desktop. Un dyalog box si aprirà, selezionare i seguenti check boxes:
- Allow other users to view your desktop
- Allow other users to control your desktop
- Require the user to enter this password
Ricordo di non selezionare il check box "Ask for your confirmation" altrimenti non sarà possibile accedere da remoto. Una buona idea è scegliere una password il più possibile robusta. |
Selezionare close e vino-server è configurato.
Risolvere il problema dell'IP dinamico
In questa guida si presuppone che l'utente abbia un IP dinamico. |
A meno che non si abbia a disposizione un proprio domain name e configurato il proprio computer affinchè risolva le queries indirizzate ad esso e, a meno che non si paghi per avere un IP statico. Occorre servirsi degli strumenti che permettano di impostare un proprio hostname gratuitamente.
Andare sul sito di DynDNS ad esempio [https://www.dyndns.com/services/dns/dyndns/], cercare la voce sign up for a "Free Dynamic DNS account". Con questo ci viene permesso di creare un virtual domain name partendo da uno dei loro domini (ad esempio mycomputer.dyndns.org). In questo modo quando si vorrà connettersi al proprio computer da qualunque luogo, potremo semplicemente scrivere quell'indirizzo piuttosto che l'IP della nostra macchina che tra altro è dinamico.
A titolo informativo, c'è un client *nix che ha il compito di informare i server DynDNS di quando cambia IP la propria macchina lo si può reperire al seguente indirizzo [https://www.dyndns.com/support/clients/]. Non mi è mai capitato di usarlo in quanto il mio router svolge questa funzione internamente. In ogni modo ci sono diversi HowTo al loro sito. |
Portable Solutions
Per connettersi alla propria machcina da remoto analizzare ancora un paio di cose.
Aprire le porte del proprio router/firewall sulle queli il demone SSH resterà in ascolto (nel caso di questa guida la porta 59000). Una buona guida per questo è disponibile al seguente indirizzo [http://portforward.com/routers.htm]
- Recuperare del software portabile, usabile sulle macchine Windows (le macchine *nix e Mac hanno SSH built in).
Alcuni esempi di questo software sono:
Putty: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html] Un fantastico strumento, appunto un ssh-client che rende usabile ssh su macchine Windows
Puttygen: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html] Software necessario per trasformare la nostra chiave id_rsa nel formato usato da Putty .ppk.
TightVNC Viewer: [http://www.tightvnc.com/download.html] Questo è un client per Windows (ne esiste anche una versione usabile per Linux). Ne esiste una versione tightvnc-X.X.X_x86_viewer.zip che non richiede di essere installata perrtanto una volta scompattata può essere copiata su un qualunque portable drive. Ovviamente di questo software esistono delle alternative più che valide come UltraVNC e RealVNC.
Scelto il software da usare sul portable drive, dobbiamo:
- Copiare la private key memorizzata sul nostro home computer (nella cartella ~/.ssh/) nel nostro portable drive (d'ora in poi USBdrive):
sudo cp ~/.ssh/id_rsa /media/USBdrive/
Fatto ciò occorre importare la chiave in Putty, ma per far questo avremo bisogno di puttygen.exe memorizzato in precedenza anchesso sull'USB drive Remember the file from above, named id_rsa? You're going to put this file on your USB drive, and import the key into PuTTY. To do that:
Avviare il file puttygen.exe sull'USB drive
Andare in Conversions | Import Key
- Click sulla propria private key e inserire la propria passphrase
- Aggiornare la key fingerprint
Salvare le chiavi usando Save public key e Save private key
puttygen.exe genera un altra chiave pubblica. Questa è identica a quella memorizzata sul nostro home computer.
Da notare che è sempre possibile partendo dalla propria chiave privata ricostruire la propria chiave pubblica, ma non è possibile il contrario. |