|
|
| (22 versioni intermedie di 4 utenti non mostrate) |
| Riga 1: |
Riga 1: |
| {{stub}} | | {{Guida da adottare}}{{OpenSSH}} |
| {{Versioni compatibili|Debian Etch 4.0<br/>Debian Lenny 5.0<br/>Debian Squeeze<br/>Debian Sid|}} | |
| == Introduzione ==
| |
| Ho deciso di scrivere questa guida poiché ho avuto molta difficoltà a creare una connessione remota sicura fra una macchina Windows ed una Linux in una [http://it.wikipedia.org/wiki/Lan LAN] (o in una [http://it.wikipedia.org/wiki/Wan WAN]) in quanto la maggior parte delle guide, degli How-To e delle FAQ che ho trovato in Internet esamina tale connessione fra due macchine Linux.
| |
| | |
| La connessione remota sicura, che esaminerò, è una connessione che usa il protocollo [http://it.wikipedia.org/wiki/Ssh SSH (Secure SHell)] e, perciò, è detta '''connessione SSH'''. Questo tipo di connessione si basa sulla [http://it.wikipedia.org/wiki/Crittografia_asimmetrica criptografia asimmetrica] detta anche '''crittografia a coppia di chiavi''' o, più semplicemente, '''a chiave pubblica/privata''' (o, semplicemente, '''a chiave pubblica''') che consiste nella generazione di una coppia di chiavi (chiamate [http://it.wikipedia.org/wiki/Chiave_privata chiave privata] e [http://it.wikipedia.org/wiki/Chiave_pubblica chiave pubblica]). In pratica, la '''chiave pubblica''' codifica la comunicazione mentre la '''chiave privata''' decodifica tale comunicazione e vengono generate usando degli algoritmi asimmetrici che sono [http://it.wikipedia.org/wiki/RSA RSA] e [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm DSA]: le connessioni che usano tali coppie di chiavi prodotte da questi algoritmi asimmetrici sono dette '''connessioni SSH'''. Tali algoritmi, però, servono soltanto per instaurare una connessione criptata fra il client SSH e il server SSH in quanto, per il trasferimento vero e proprio dei dati, si usano degli algoritmi simmetrici, come AES o 3DES, che sono molto più efficienti per questo scopo ovvero per cifrare la comunicazione. Quindi:
| |
| <br>
| |
| una '''connessione SSH''' è una connessione cifrata che utilizza gli algoritmi asimmetrici RSA o DSA soltanto per verificare se una chiave pubblica, memorizzata sul server, derivi da una chiave privata salvata sul client (in modo da garantire la reciproca autenticità del server e del client) in modo da essere utilizzata, per l'intera sessione, per la cifratura simmetrica con algoritmi come AES o 3DES.
| |
| | |
| La '''connessione SSH''' avviene tipicamente sulla '''porta 22''' e, di norma, il server risponde aprendo una shell di comando.
| |
| <br/>
| |
| Con un software client adatto è però possibile sfruttare, tramite il meccanismo del [http://en.wikipedia.org/wiki/Tunneling_protocol tunneling], la possibilità del protocollo SSH di instradare attraverso il canale criptato sulla porta 22 anche il traffico di altre porte.
| |
| <br/>
| |
| Questa importante caratteristica consente quindi di sottoporre a comunicazione criptata protocolli che in origine non prevedono questa possibilità; inoltre, utilizzando una sola porta per la trasmissione di pacchetti che invece ne userebbero molte altre, è possibile collegarsi ad un host Linux posto dietro ad un firewall senza bisogno di modificarne le impostazioni.
| |
| | |
| == Scelta del software == | | == Scelta del software == |
|
| |
|
| Ora, dopo aver fatto questa introduzione per chiarire i termini che userò in seguito, spiegherò, in pratica, come si crea una connessione SSH da Windows a Linux.
| | In primis è necessario che che sulla macchina Linux sia attivo un '''server SSH''', mentre sulla macchina Windows deve essere installata la controparte '''client'''. |
| <br>
| |
| A questo scopo, è necessario che che sulla macchina Linux sia attivo un '''server SSH''', mentre sulla macchina Windows deve essere installata la controparte '''client'''.
| |
| <br> | | <br> |
| La scelta del server SSH per Linux non pone alcun problema in quanto la comunità Open Source ha creato un ottimo prodotto che, ormai, tutte le distribuzioni installano come predefinito. Questo prodotto è il software [http://www.openssh.com/ OpenSSH Server]. | | La scelta del server SSH per Linux non pone alcun problema in quanto la comunità Open Source ha creato un ottimo prodotto che, ormai, tutte le distribuzioni installano come predefinito. Questo prodotto è il software [http://www.openssh.com/ OpenSSH Server]. |
| Riga 38: |
Riga 22: |
| == Preparazione del lato Server == | | == Preparazione del lato Server == |
|
| |
|
| Le due sottosezioni seguenti permettono che la vostra Linux-Box faccia da Server SSH con la possibilità di controllare, da remoto, anche le sessioni grafiche.
| | Si vedano le guide [[OpenSSH]] e [[OpenSSH: file di configurazione]]. |
|
| |
|
| === Configurazione del Server OpenSSH === | | === Configurazione per accedere da remoto alle sessioni grafiche === |
|
| |
|
| Per installare l'OpenSSH Server (nel caso in cui la vostra distribuzione non lo avesse installato), occorre cercare, nel vostro gestore di pacchetti preferito, il pacchetto openssh-server ed installarlo con tutte le eventuali dipendenze. Una guida utile per aiutarvi in questo compito può essere: [http://guide.debianizzati.org/index.php/OpenSSH:_configurazione_di_base OpenSSH: Configurazione di base]
| | Fin qui, sarete in grado '''solo''' di accedere, mediante un client SSH, alla '''sola''' shell della vostra Linux-Box che, pur essendo molto potente ed utile, non è troppo amichevole. Quindi, per far sì che i vostri utenti remoti possano usare anche un server grafico X (quasi sicuramente già installato e configurato), è necessario, prima, autorizzare tali utenti ad accedere a tale server e, poi, ad avviare, su questa stessa macchina, un server VNC che permetta di controllare un X display in modo da poter usare qualunque programma per X compresi i [http://it.wikipedia.org/wiki/Desktop_environment Desktop Environment] come [http://it.wikipedia.org/wiki/GNOME GNOME] o [http://it.wikipedia.org/wiki/KDE KDE]. |
|
| |
|
| Una volta installato l'OpenSSH Server sulla macchina Linux, occorre configurarlo per scegliere il modo di autenticazione che volete che le macchine client utilizzino per accedere al server Linux.
| | {{Box | Osservazione |Un '''X Display''' è un display virtuale, creato da un server [http://it.wikipedia.org/wiki/X11 X Window System detto, comunemente, X11] o figli (come [http://it.wikipedia.org/wiki/XFree86 XFree86] o [http://it.wikipedia.org/wiki/XOrg X.Org]), atto a ricevere l'input da una tastiera, da un mouse e da una scheda grafica, situate in locale o in remoto, mediante un qualsiasi programma-client X che può essere installato sulla macchina locale o in una remota.}} |
|
| |
|
| Le varie autenticazioni che OpenSSH Server può offrire sono:
| | Perciò, per fare in modo che anche gli utenti remoti possono usare l'X server, occorre accedere alla vostra Linux-Box come root e modificare il valore di una variabile nel file <code>/etc/X11/Xwrapper.config</code> (nel caso in cui tale variabile mancasse, aggiungetela senza paura). Quindi, questa variabile è <code>allowed_users</code> e deve assumere il valore <code>anybody</code> (ossia <code>allowed_users=anybody</code>). |
| | Dopo, per dare la possibilità ai vostri utenti remoti, che usano Windows, di gestire i vari programmi di X, occorre che alla partenza dell'X Server parta anche un VNC server che permetta di far visualizzare, tramite un client VNC (installato su Windows), i programmi di X. In Linux, ci sono vari VNC server free per Linux come [http://www.realvnc.com/ RealVNC] o [http://www.tightvnc.com/ TightVNC] o [http://www.karlrunge.com/x11vnc/ x11vnc]. Quest'ultimo ha una caratteristica particolare: quella di poter essere controllato un X Display già in uso da un qualsiasi VNC client installato su una macchina remota. Perciò, questa particolarità è molto utile anche per effettuare l'insegnamento a distanza. |
|
| |
|
| #Autenticazione tramite '''password'''
| | == PuTTY, autenticazione con chiave pubblica == |
| #Autenticazione '''ChallengeResponseAuthentication''' o '''Keyboard-Interactive'''
| |
| #Autenticazione '''a chiave pubblica'''
| |
| #Autenticazione '''GSSAPI'''
| |
| <br/>
| |
| * '''L'autenticazione tramite password''' utilizza la Username e la Password dell'utente (le stesse usate per l'autenticazione in locale) per verificare se l'utente è autorizzato ad accedere da remoto alla macchina Linux.
| |
|
| |
|
| * '''L'autenticazione ChallengeResponseAuthentication o Keyboard-Interactive''' utilizza una serie di autenticazioni caratterizzate da richieste, fatte dal server SSH, che devono essere confermate dalle risposte mandate dal client SSH. Se le risposte coincidono con quelle memorizzate sul Server, l'utente è autorizzato ad accedere da remoto alla macchina Linux altrimenti questi non può accedere alla macchina Linux.
| | === Preparazione === |
|
| |
|
| * '''L'autenticazione a chiave pubblica''' verifica se la chiavi pubblica, memorizzata sul Server, '''derivi''' dalla chiave privata memorizzata sul client dell'utente. Se tale verifica ha esito positivo, l'utente può accedere alla macchina Linux altrimenti no. Siccome la chiave privata è praticamente un file, che autorizza chiunque entra in possesso ad entrare in un Server SSH, è consigliabile proteggerla con una '''passphrase''' che, in sostanza, è una password da inserire ogni volta, o quasi, che si effettua una connessione verso tale Server SSH.
| | Prima di potersi collegare al server è necessario o importare una chiave privata già esistente, se la corrispondente chiave pubblica è già registrata sul server di interesse, oppure creare ex-novo una coppia di chiavi con PuTTY e registrare quella pubblica sul server. |
|
| |
|
| * '''L'autenticazione GSSAPI''', basata su un'API generica, implementata su vari sistemi operativi, utilizza un determinato protocollo, che, normalmente, è Kerberos 5, per trasferire i dati per l'autenticazione.
| | ==== Usare una chiave privata OpenSSH esistente ==== |
| <br/>
| |
| Le autenticazioni più comode ed usate in una rete LAN (ma non solo) sono l''''autenticazione tramite password''' e l''''autenticazione a chiave pubblica'''. Quindi, la mia attenzione andrà soprattutto su queste due autenticazioni in quanto sono, forse, le più semplici da essere implementate.
| |
|
| |
|
| Il file di configurazione di OpenSSH Server si chiama <code>''sshd_config''</code> e, normalmente, si trova nella directory <code>''/etc/ssh''</code>.
| | Se si possiede una chiave privata per il server di interesse, ma generata tramite <code>ssh-keygen</code>, è necessario convertirla nel formato supportato da putty prima di poterla usare con quest'ultimo.<br/> |
| | Per fare ciò è sufficiente avviare PuTTYgen, cliccare sul pulsante "load" e selezionare la propria chiave privata. Quando PuTTYgen informa l'utente di essere riuscito ad importare la chiave privata, questi non dovrà far altro che salvarla cliccando sull'apposito pulsante. Il risultante file ''.ppk'' è proprio la chiave privata salvata in un formato compatibile con PuTTY. |
|
| |
|
| Questo è un file di testo composto da '''direttive''' (dette '''Keywords'''), che sono '''case-insensitive''', e da '''valori''', che sono '''case-sensitive'''. Quindi, per editarlo, basta un semplice editor di testo come '''vi''' o '''Emacs''' che avete già nella vostra distribuzione.
| | ==== Generazione di una nuova coppia di chiavi ==== |
|
| |
|
| Quindi, attiviamo, in forma base, le autenticazioni tramite password e a chiave pubblica e disattiviamo le altre per evitare conflitti ed accessi non desiderati a causa di eventuali bachi.
| | # Avviare PuTTYgen |
| | | # Selezionare i parametri di interesse, ad esempio il numero di bit della chiave |
| Perciò, verifichiamo, da root, che, nel file <code>/etc/ssh/sshd_config</code>, ci siano le seguenti keyword ed i corrispettivi valori; se si dovessero trovare delle keyword mancanti o dei valori che non corrispondessero a quelli sotto enunciati, modificate semplicemente il testo stando attenti a non fare incominciare le keyword con il simbolo # (sto facendo riferimento al file <code>/etc/ssh/sshd_config</code> creato da OpenSSH Server di default):
| | # Cliccare sul pulsante ''Generate'' |
| <br/><br/>
| | # Muovere il mouse come richiesto ed attendere il termine della procedura. |
| {|
| | # Salvare la chiave privata in un luogo sicuro. |
| |style="width:20em;vertical-align:top;"|''Port <Numero porta d'ascolto>''
| | # Copiare quella pubblica dal box superiore e salvarla in un file, oppure inserirla manualmente tra le chiavi pubbliche accettate dal server (si veda la pagina principale dedicata ad Open SSH). |
| |Il valore di questa keyword indica la porta d'ascolto dell'OpenSSH Server. Conviene cambiare la porta d'ascolto di default per evitare, fin da subito, degli attacchi esterni e mettere un numero superiore a 1024 che non sia già usato da altri servizi locali o di Internet (per sapere le porte Internet di default usate dai comuni servizi Internet, andate [http://www.iana.org/assignments/port-numbers qui]). Si deve ricordare, dopo aver scelto tale porta, di "dire" al vostro firewall di aprire in entrata tale porta per fare in modo che i vostri utenti remoti possono accedere alla vostra macchina Linux.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''Protocol 2''
| |
| |Il valore di questa keyword indica quale protocollo SSH utilizzare. Consiglio di utilizzare soltanto il protocollo 2 in quanto il protocollo 1 ha seri problemi di sicurezza.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''PermitRootLogin no''
| |
| |Il valore di questa keyword evita l'accesso come root da remoto con '''una sola''' autenticazione. Ciò garantisce maggior sicurezza alla vostra Linux-Box poiché, se si volesse accedere come root, sarebbe necessario prima autenticarsi come utente normale per poi autenticarsi come root tramite il comando ''su''. In altre parole, con questa keyword impostata su '''no''', chi volesse accedere come root da remoto, dovrebbe autenticarsi '''due''' volte anziché '''una'''.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''PasswordAuthentication yes''
| |
| |Il valore di questa keyword permette l'autenticazione mediante un semplice Login (Username e Password) da remoto.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|KerberosAuthentication no''
| |
| |Il valore di questa keyword evita che la password fornita mediante l'autenticazione tramite password sia convalidata dal KDC (Kerberos Key Distribution Center).
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''PermitEmptyPasswords no''
| |
| |Il valore di questa keyword evita che l'autenticazione mediante un semplice Login remoto avvenga senza la richiesta di una password se la keyword ''PasswordAuthentication'' è impostata sul ''yes''.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''ChallengeResponseAuthentication no''
| |
| |Il valore di questa keyword non permette l'autenticazione mediante richieste-risposte ben precise fra il server ed il client SSH.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''PubkeyAuthentication yes''
| |
| |Il valore di questa keyword permette l'autenticazione mediante una coppia di chiavi, una '''pubblica''', memorizzata sul server, ed una '''privata''' salvata sul client.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''AuthorizedKeysFile <File chiavi pubbliche>''
| |
| |Il valore di questa keyword è il nome del file in cui vengono memorizzate le chiavi pubbliche degli utenti remoti che servono per verificare se una di queste derivi dalla chiave privata memorizzata dal client SSH che cerca di effettuare una connessione SSH utilizzando un''''autenticazione a chiave pubblica'''. Logicamente, tale keyword viene considerata soltanto se la keyword ''PubkeyAuthentication'' è impostata su ''yes''. Il valore di tale keyword deve contenere il path assoluto o relativo di questo file compreso il nome stesso (il valore di default è <code>.ssh/authorized_keys</code>). Normalmente, il path assoluto si usa quando il gestore del Server vuole tenere sott'occhio un unico file (che può anche essere memorizzato, per motivi di sicurezza, su un'altra macchina); mentre il path relativo alla home directory di ogni utente remoto viene, normalmente, usato per far sì che ogni utente gestisca lui stesso il file mettendo una o più delle sue chiavi pubbliche.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''GSSAPIAuthentication no''
| |
| |Il valore di questa keyword non permette l'autenticazione utilizzando l'API GSSAPI.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''Ciphers aes256-cbc,aes256-ctr,3des-cbc''
| |
| |Il valore di questa keyword permette di scegliere quali algoritmi simmetrici verranno usati per cifrare i dati trasferiti. Siccome l'utente del client SSH o il client stesso possono decidere quale sarà l'algoritmo simmetrico da utilizzare per l'intera sessione di lavoro, conviene "obbligare" l'utente o il client SSH a scegliere gli algoritmi che garantiscono la massima sicurezza con un occhio di riguardo alla velocità di trasferimento dei dati fra il server ed il client (e viceversa).
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''ClientAliveInterval 60''
| |
| |Il valore di questa keyword imposta il numero di secondi dopo i quali, se da un client SSH remoto non viene inviato al server SSH alcun dato, tale server invia un messaggio di verifica, nel canale criptato, dell'ancora esistenza del client (detto alive message) ed aspetta una risposta. Se tale risposta non arriva, interviene la keyword ''ClientAliveCountMax''.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''ClientAliveCountMax 3''
| |
| |Il valore di questa keyword indica quante volte mandare un alive message, sempre nel canale criptato, al client SSH che non risponde. Se, dopo l'ultima richiesta "di vita", il client SSH non risponde, il server SSH termina la connessione con quel client. Quindi, impostando correttamente i valori delle keyword ''ClientAliveInterval'' e ''ClientAliveCountMax'' si evita il sovraccarico del vostro server (con un risparmio delle sue risposte) impostando '''una disconnessione automatica''' del client da parte del Server ogni 180 (60·3) secondi.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''TCPKeepAlive no''
| |
| |Il valore di questa keyword non permette di mandare dei '''TCP keepalive message''' per verificare se la rete è caduta o se il client SSH remoto è andato in crash. Poiché i TCP keepalive message non vengono mandati nel canale criptato e possono contenere delle informazioni sensibili, si preferisce disabilitare questa tecnica di analisi sullo stato delle connessioni SSH usufruendo delle keyword ''ClientAliveInterval'' e ''ClientAliveCountMax'' per eliminare le connessioni SSH non più utilizzate.
| |
| |-
| |
| |style="width:20em;vertical-align:top;"|''Subsystem sftp /usr/lib/openssh/sftp-server''
| |
| |Il valore di questa keyword permette di configurare un sottosistema esterno, come un server FTP, da avviare insieme al servizio SSH. Conviene far partire un server FTP che possa sfruttare il protocollo SSH in modo da poter trasferire, in modo sicuro, dei file dal client al server e viceversa.
| |
| |}
| |
| <br/> | | <br/> |
| Questo è tutto ciò che vi serve per far funzionare, in forma base ma efficiente ed in tutta sicurezza, un Server SSH in grado di dialogare con le macchine Windows (per chi volesse conoscere altre keyword per personalizzare il vostro Server SSH, basato sull'OpenSSH Server, consiglio di digitare, dalla Shell, il comando <code>''man 5 sshd_config''</code>).
| | {{Warningbox|La chiave pubblica deve essere esportata in modo che sia compatibile con OpenSSH! Finché è aperta la finestra del generatore di chiave sarà possibile copiarla, altrimenti se la si salva sarà necessario eliminare le prime due righe ed inserire ssh-rsa per rsa oppure ssh-dss per dsa, quindi lasciare uno spazio vuoto e inserire in un'unica riga il testo della chiave. Alla fine ci deve essere il simbolo =, la parte seguente è opzionale e potete ometterla senza problemi.}} |
| | |
| {{Box | Nota |Dato che nel file <code>/etc/ssh/sshd_config</code> ci potrebbero essere dati sensibili (come la porta d'ascolto del Server SSH), forse, si vorrebbe proteggerlo dagli utenti locali. Quindi, basta che, dopo averlo salvato, scriviate da root <code>chmod 600 /etc/ssh/sshd_config</code>.}}
| |
|
| |
|
| === Configurazione per accedere da remoto alle sessioni grafiche ===
| | [[Immagine:MmteamPutty001.JPG |320px | center]] |
|
| |
|
| Fin qui, sarete in grado '''solo''' di accedere, mediante un client SSH, alla '''sola''' shell della vostra Linux-Box che, pur essendo molto potente ed utile, non è troppo amichevole. Quindi, per far sì che i vostri utenti remoti possano usare anche un server grafico X (quasi sicuramente già installato e configurato), è necessario, prima, autorizzare tali utenti ad accedere a tale server e, poi, ad avviare, su questa stessa macchina, un server VNC che permetta di controllare un X display in modo da poter usare qualunque programma per X compresi i [http://it.wikipedia.org/wiki/Desktop_environment Desktop Environment] come [http://it.wikipedia.org/wiki/GNOME GNOME] o [http://it.wikipedia.org/wiki/KDE KDE].
| | === Connessione === |
|
| |
|
| {{Box | Osservazione |Un '''X Display''' è un display virtuale, creato da un server [http://it.wikipedia.org/wiki/X11 X Window System detto, comunemente, X11] o figli (come [http://it.wikipedia.org/wiki/XFree86 XFree86] o [http://it.wikipedia.org/wiki/XOrg X.Org]), atto a ricevere l'input da una tastiera, da un mouse e da una scheda grafica, situate in locale o in remoto, mediante un qualsiasi programma-client X che può essere installato sulla macchina locale o in una remota.}}
| | Per la connessione indicare a putty dove risiede la propria chiave privata . |
|
| |
|
| Perciò, per fare in modo che anche gli utenti remoti possono usare l'X server, occorre accedere alla vostra Linux-Box come root e modificare il valore di una variabile nel file <code>/etc/X11/Xwrapper.config</code> (nel caso in cui tale variabile mancasse, aggiungetela senza paura). Quindi, questa variabile è <code>allowed_users</code> e deve assumere il valore <code>anybody</code> (ossia <code>allowed_users=anybody</code>).
| | [[Immagine:Mmteamputty2.JPG |320px | center]] |
| Dopo, per dare la possibilità ai vostri utenti remoti, che usano Windows, di gestire i vari programmi di X, occorre che alla partenza dell'X Server parta anche un VNC server che permetta di far visualizzare, tramite un client VNC (installato su Windows), i programmi di X. In Linux, ci sono vari VNC server free per Linux come [http://www.realvnc.com/ RealVNC] o [http://www.tightvnc.com/ TightVNC] o [http://www.karlrunge.com/x11vnc/ x11vnc]. Quest'ultimo ha una caratteristica particolare: quella di poter essere controllato un X Display già in uso da un qualsiasi VNC client installato su una macchina remota. Perciò, questa particolarità è molto utile anche per effettuare l'insegnamento a distanza.
| |
|
| |
|
| | e nella schermata principale inserire i dati per la connessione. |
|
| |
|
| | [[Immagine:MmteamPutty003.JPG |320px | center]] |
|
| |
|
| ----
| | Al login inserire la password impostata nella chiave. |
|
| |
|
| --[[Utente:Balubeto|Balubeto]] 10:52, 9 Giu 2006 (EDT)
| | [[Categoria:Reti con Windows]] |
| [[Categoria:Networking]] | | [[Categoria:SSH server e amministrazione remota]] |
Guida da adottare! 
|
Scelta del software
In primis è necessario che che sulla macchina Linux sia attivo un server SSH, mentre sulla macchina Windows deve essere installata la controparte client.
La scelta del server SSH per Linux non pone alcun problema in quanto la comunità Open Source ha creato un ottimo prodotto che, ormai, tutte le distribuzioni installano come predefinito. Questo prodotto è il software OpenSSH Server.
Al contrario, le versioni di Windows per desktop fin qui rilasciate non prevedono l'installazione di un client SSH, ed è necessario quindi rivolgersi a software di terze parti.
Attualmente il più diffuso, nonchè semplice, client SSH per Windows è PuTTY.
Viene rilasciato con licenza MIT, certificata OSI – Open Source Initiative, e compatibile con la GPL ([1]).
Non necessita di installazione, per utilizzarlo è sufficiente disporre dell'eseguibile putty.exe; questo è un vantaggio in tutte le situazioni in cui non sia possibile o consentita l'installazione di software aggiuntivo.
Insieme a PuTTY, e sempre utilizzabili tramite il solo eseguibile, sono disponibili altri programmi che ne completano le funzionalità:
- PSCP, client SCP;
- PSFTP, client SFTP;
- PuTTYgen, utility per la generazione delle chiavi crittografiche RSA e DSA.
Programmi commerciali come SecureCRT oppure Tectia offrono soluzioni sicuramente più complete, ma per i nostri scopi PuTTY è più che sufficiente, e sarà il client Windows che verrà trattato nella presente guida.
|
Nota
I client SSH permettono soltanto di accedere alla Shell di Linux per poter eseguire comandi su un terminale a caratteri di questo sistema operativo. Per poter accedere anche al suo server grafico X Window System o X11 o soltanto X (e, quindi, per poter controllare i vari ambienti grafici ed i programmi di X), occorre anche un client/server VNC. Ora, niente paura in quanto, grazie alla funzionalità Tunneling di questi tre client SSH, è possibile controllare anche X sempre in modo sicuro.
|
Preparazione del lato Server
Si vedano le guide OpenSSH e OpenSSH: file di configurazione.
Configurazione per accedere da remoto alle sessioni grafiche
Fin qui, sarete in grado solo di accedere, mediante un client SSH, alla sola shell della vostra Linux-Box che, pur essendo molto potente ed utile, non è troppo amichevole. Quindi, per far sì che i vostri utenti remoti possano usare anche un server grafico X (quasi sicuramente già installato e configurato), è necessario, prima, autorizzare tali utenti ad accedere a tale server e, poi, ad avviare, su questa stessa macchina, un server VNC che permetta di controllare un X display in modo da poter usare qualunque programma per X compresi i Desktop Environment come GNOME o KDE.
|
|
Osservazione
Un X Display è un display virtuale, creato da un server X Window System detto, comunemente, X11 o figli (come XFree86 o X.Org), atto a ricevere l'input da una tastiera, da un mouse e da una scheda grafica, situate in locale o in remoto, mediante un qualsiasi programma-client X che può essere installato sulla macchina locale o in una remota.
|
Perciò, per fare in modo che anche gli utenti remoti possono usare l'X server, occorre accedere alla vostra Linux-Box come root e modificare il valore di una variabile nel file /etc/X11/Xwrapper.config (nel caso in cui tale variabile mancasse, aggiungetela senza paura). Quindi, questa variabile è allowed_users e deve assumere il valore anybody (ossia allowed_users=anybody).
Dopo, per dare la possibilità ai vostri utenti remoti, che usano Windows, di gestire i vari programmi di X, occorre che alla partenza dell'X Server parta anche un VNC server che permetta di far visualizzare, tramite un client VNC (installato su Windows), i programmi di X. In Linux, ci sono vari VNC server free per Linux come RealVNC o TightVNC o x11vnc. Quest'ultimo ha una caratteristica particolare: quella di poter essere controllato un X Display già in uso da un qualsiasi VNC client installato su una macchina remota. Perciò, questa particolarità è molto utile anche per effettuare l'insegnamento a distanza.
PuTTY, autenticazione con chiave pubblica
Preparazione
Prima di potersi collegare al server è necessario o importare una chiave privata già esistente, se la corrispondente chiave pubblica è già registrata sul server di interesse, oppure creare ex-novo una coppia di chiavi con PuTTY e registrare quella pubblica sul server.
Usare una chiave privata OpenSSH esistente
Se si possiede una chiave privata per il server di interesse, ma generata tramite ssh-keygen, è necessario convertirla nel formato supportato da putty prima di poterla usare con quest'ultimo.
Per fare ciò è sufficiente avviare PuTTYgen, cliccare sul pulsante "load" e selezionare la propria chiave privata. Quando PuTTYgen informa l'utente di essere riuscito ad importare la chiave privata, questi non dovrà far altro che salvarla cliccando sull'apposito pulsante. Il risultante file .ppk è proprio la chiave privata salvata in un formato compatibile con PuTTY.
Generazione di una nuova coppia di chiavi
- Avviare PuTTYgen
- Selezionare i parametri di interesse, ad esempio il numero di bit della chiave
- Cliccare sul pulsante Generate
- Muovere il mouse come richiesto ed attendere il termine della procedura.
- Salvare la chiave privata in un luogo sicuro.
- Copiare quella pubblica dal box superiore e salvarla in un file, oppure inserirla manualmente tra le chiavi pubbliche accettate dal server (si veda la pagina principale dedicata ad Open SSH).
|
ATTENZIONE
La chiave pubblica deve essere esportata in modo che sia compatibile con OpenSSH! Finché è aperta la finestra del generatore di chiave sarà possibile copiarla, altrimenti se la si salva sarà necessario eliminare le prime due righe ed inserire ssh-rsa per rsa oppure ssh-dss per dsa, quindi lasciare uno spazio vuoto e inserire in un'unica riga il testo della chiave. Alla fine ci deve essere il simbolo =, la parte seguente è opzionale e potete ometterla senza problemi.
|
Connessione
Per la connessione indicare a putty dove risiede la propria chiave privata .
e nella schermata principale inserire i dati per la connessione.
Al login inserire la password impostata nella chiave.
