6 999
contributi
OpenSSH: Windows: differenze tra le versioni
Vai alla navigazione
Vai alla ricerca
nessun oggetto della modifica
Nessun oggetto della modifica |
S3v (discussione | contributi) Nessun oggetto della modifica |
||
| Riga 6: | Riga 6: | ||
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: | 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> | <br> | ||
una '''connessione SSH''' | 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. | ||
=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. Per far ciò, occorre scegliere un server-software SSH sulla macchina Linux (che funge da server) ed un client-software SSH su una macchina Windows (che funge da client). Per scegliere un server-software SSH per Linux, non esiste 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]. Ora, siccome Windows (in tutte le sue edizione per il desktop) non ha nessun client-software SSH, occorre cercarne uno. Il più semplice client SSH con licenza certificata Open Source è [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] ma, chi volesse usare soprattutto la | 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. Per far ciò, occorre scegliere un server-software SSH sulla macchina Linux (che funge da server) ed un client-software SSH su una macchina Windows (che funge da client). Per scegliere un server-software SSH per Linux, non esiste 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]. Ora, siccome Windows (in tutte le sue edizione per il desktop) non ha nessun client-software SSH, occorre cercarne uno. Il più semplice client SSH con licenza certificata Open Source è [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] ma, chi volesse usare soprattutto la shell di Linux ed avere qualche comodità in più sullo stile di Windows, dovrà valutare programmi commerciali come [http://www.vandyke.com/products/securecrt/ SecureCRT] o [http://www.ssh.com/products/tectia/client/ SSH Tectia Client]: si possono utilizzare le versioni di prova, completamente funzionanti, prima dell'acquisto. | ||
{{Box | 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 [http://it.wikipedia.org/wiki/X_Window_System 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 [http://it.wikipedia.org/wiki/VNC client/server VNC]. Ora, niente paura in quanto, grazie alla funzionalità [http://en.wikipedia.org/wiki/Tunneling_protocol Tunneling] di questi tre client SSH, | {{Box | 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 [http://it.wikipedia.org/wiki/X_Window_System 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 [http://it.wikipedia.org/wiki/VNC client/server VNC]. Ora, niente paura in quanto, grazie alla funzionalità [http://en.wikipedia.org/wiki/Tunneling_protocol Tunneling] di questi tre client SSH, è possibile controllare anche X sempre in modo sicuro.}} | ||
=Preparazione del lato Server= | =Preparazione del lato Server= | ||
| Riga 31: | Riga 31: | ||
#Autenticazione '''GSSAPI''' | #Autenticazione '''GSSAPI''' | ||
<br/> | <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 | * '''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. | * '''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. | ||
* '''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 | * '''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. | ||
* '''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. | * '''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. | ||
| Riga 47: | Riga 47: | ||
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. | 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. | ||
Perciò, verifichiamo, da root, che, nel file <code> | 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): | ||
<br/><br/> | <br/><br/> | ||
{| | {| | ||
| Riga 66: | Riga 66: | ||
|- | |- | ||
|style="width:20em;vertical-align:top;"|''PermitEmptyPasswords no'' | |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'' | |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'' | |style="width:20em;vertical-align:top;"|''ChallengeResponseAuthentication no'' | ||
| Riga 75: | Riga 75: | ||
|- | |- | ||
|style="width:20em;vertical-align:top;"|''AuthorizedKeysFile <File chiavi pubbliche>'' | |style="width:20em;vertical-align:top;"|''AuthorizedKeysFile <File chiavi pubbliche>'' | ||
|Il valore di questa keyword | |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'' | |style="width:20em;vertical-align:top;"|''GSSAPIAuthentication no'' | ||
| Riga 90: | Riga 90: | ||
|- | |- | ||
|style="width:20em;vertical-align:top;"|''TCPKeepAlive no'' | |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. | |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'' | |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 | |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/> | ||
| Riga 102: | Riga 102: | ||
==Configurazione per accedere da remoto alle sessioni grafiche== | ==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 | 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]. | ||
{{Box | Osservazione |Un '''X Display''' | {{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.}} | ||
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 | 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à | 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. | ||