OpenSSH: Windows

Attenzione: questo articolo è ancora incompleto e in fase di scrittura da parte del suo autore.

Sentitevi liberi di contribuire, proponendo modifiche alla guida tramite l'apposita pagina di discussione, in modo da non interferire con il lavoro portato avanti sulla voce. Per altre informazioni si rimanda al template.

Introduzione

Ho deciso di fare questa guida poichè ho avuto molta difficoltà a creare una connessione remota sicura fra una macchina Windows ed una Linux in una LAN (o in una 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 esaminero`, e` una connessione che usa il protocollo SSH (Secure SHell) e, perciò, é detta connessione SSH la quale si basa sulla criptografia asimetrica detta anche criptografia a coppia di chiavi o, piu` semplicemente, a chiave pubblica/privata (o, semplicemente, a chiave pubblica) che consiste nella generazione di una coppia di chiavi (chiamate chiave privata e chiave pubblica). In pratica, la chiave pubblica codifica la communicazione mentre la chiave privata decodifica tale comunicazione e vengono generate usando degli algoritmi asimetrici che sono RSA e DSA e le connessioni che usano tali coppie di chiavi prodotte da questi algoritmi asimetrici 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ù efficenti per questo scopo ovvero per cifrare la comunicazione. Quindi:

Una connessione SSH é una connessione cifrata che utilizza gli algoritmi asimetrici 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 autenticita` 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

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 dal Server) ed un client-software SSH su una macchina Windows (che funge da Client). Ora, per scegliere un server-software SSH per Linux, non esiste alcun problema in quanto la communità Open Source ha creato un ottimo prodotto che, ormai, tutte le distribuzione lo installano come default. Questo prodotto é il software 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 é 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 SecureCRT o SSH Tectia Client che, per fortuna, si possono prelevare le versioni di valutazione completamente funzionanti prima dell'acquisto.

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 controlare anche X sempre in modo sicuro.

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.

Configurazione del Server OpenSSH

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 volta installato l'OpenSSH Server sulla macchina Linux, occorre configurarlo per scegliere il modo di authentificazione che volete che le macchine Client usano per accedere a questa macchina Linux.

Le varie autentificazione che OpenSSH Server può offrire sono:

Autentificazione tramite password
Autentificazione ChallengeResponseAuthentication o Keyboard-Interactive
Autentificazione a chiave pubblica
Autentifiazione GSSAPI

L'autentificazione tramite password utilizza la Username e la Password dell'utente (le stesse usate per l'autentificazione in locale) per verificare se l'utente é autorizzato ad accedere da remoto alla macchina Linux.

L'autentificazione ChallengeResponseAuthentication o Keyboard-Interactive utilizza una serie di autentificazioni caratterizzate da richieste, fatte dal server SSH, che devono essere confermate dalle risposte mandate dal client SSH. Se le risposte coincidono a quelle memorizzate sul Server, l'utente é autorizzato ad accedere da remoto alla macchina Linux altrimenti questi non può entrare in tale macchina Linux.

L'autentificazione 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 altrimetri no. Siccome la chiave privata é praticamente un file, che autorizza chiunque entra in possesso ad entrare in un Server SSH, é consigliabile protteggerla con una passphrase che, in sostanza, é una password che occorre inserirla ogni volta (o quasi) che si effettua una connessione verso tale Server SSH.

L'autentifiazione 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'autentificazione.

Le auttentificazioni più comode ed usate in una rete LAN (ma non solo) sono l'autentificazione tramite password e l'autentificazione a chiave pubblica. Quindi, la mia attenzione andrà soprattutto su queste due autentificazioni in quanto sono, forse, le più semplici da essere implementate.

Il file di configurazione di OpenSSH Server si chiama sshd_config che, normalmente, si trova nella directory /etc/ssh.

Questo file é 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.

Quindi, attiviamo, in forma base, le autentificazioni tramite password e a chiave pubblica e disattiviamo le altre per evitare conflitti ed accessi non desiderati a causa di eventuali bachi.

Perciò, verichiamo, da root, che, nel file /etc/ssh/sshd_config, ci siano le seguenti keyword ed i corrispettivi valori; se si dovessero trovare delle keyword mancanti o dei valori che non corrispodessero a quei sotto-ennunciati, modificate semplicemente il testo stando attenti a non fare incominciare le keyword con il simbolo # (sto facendo rifferimento al file /etc/ssh/sshd_config creato da OpenSSH Server come default):

Port <Numero porta d'ascolto>	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 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.
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.
PermitRootLogin no	Il valore di questa keyword evita l'accesso come root da remoto con una sola autentificazione. Cio' garantisce maggior sicurezza alla vostra Linux-Box poichè, se uno volesse accedere come root, dovrebbe prima autentificarsi come utente normale per poi autentificarsi come root tramite il comando su. In altre parore, con questa keyword impostata su no, si volesse accedere come root da remoto, occorrerebbe autentificarsi due volte anzichè una.
PasswordAuthentication yes	Il valore di questa keyword permette l'autentificazione mediante un semplice Login (Username e Password) da remoto.
KerberosAuthentication no	Il valore di questa keyword evita che la password fornita mediante l'autentificazione tramite password sia convalidata dal KDC (Kerberos Key Distribution Center).
PermitEmptyPasswords no	Il valore di questa keyword evita che l'autentificazione mediante un semplice Login remoto avenga senza la richiesta di una password se la keyword PasswordAuthentication é impostata sul yes.
ChallengeResponseAuthentication no	Il valore di questa keyword non permette l'autentificazione mediante richieste-risposte ben precise fra il server ed il client SSH.
PubkeyAuthentication yes	Il valore di questa keyword permette l'autentificazione mediante una coppia di chiavi, una pubblica, memorizzata sul Server, ed una privata salvata sul Client.
AuthorizedKeysFile <File chiavi pubbliche>	Il valore di questa keyword é il nome del file dove vengono memorizzate le chiavi publiche 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'autentificazione 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 é .ssh/authorized_keys). 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.
GSSAPIAuthentication no	Il valore di questa keyword non permette l'autentificazione utilizzando l'API GSSAPI.
Ciphers aes256-cbc,aes256-ctr,3des-cbc	Il valore di questa keyword permette di scegliere quali algoritmi simmetrici verranno usati per cifrare i dati trafferiti. 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).
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.
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 disconnette la connessione con quel client. Quindi, impostando correttamente i valori delle keyword ClientAliveInterval e ClientAliveCountMax si evita il sovracarico del vostro server (con un risparmio delle sue risposte) impostando una disconnessione automatica del Client da parte del Server ogni 180 (60·3) secondi.
TCPKeepAlive no	Il valore di questa keyword non permette di mandare dei TCP keepalive message per verificare se la rete e` caduta o se il client SSH remoto e` 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 le keyword ClientAliveInterval e ClientAliveCountMax per eliminare le connessioni SSH non più utilizzate.
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 sfuttare il protocolo SSH in modo da poter trasferire, in modo sicuro, file dal Client al Server e viceversa.

Questo é tutto ciò che vi serve per far funzionare, in forma base ma efficente 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 man 5 sshd_config).

Nota
Dato che nel file /etc/ssh/sshd_config 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, scrivete da root chmod 600 /etc/ssh/sshd_config.

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), é neccessario, 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 puo` 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) e riavviare la macchina. 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.

--Balubeto 10:52, 9 Giu 2006 (EDT)