Apparentemente l'utilizzo della console per quelli che, abituati ad altri sistemi operativi, si avvicinano per le prime volte a Linux, non ha niente di intuitivo. In realtà appena capita la sua potenza, è uno strumento del quale non si può fare a meno.
Proprio per la sua potenza e semplicità fin dalla nascita dei primi sistemi Unix si è pensato di trovare un modo per riuscire a eseguire comandi, ottenendo una shell, su un computer situato fisicamente altrove. Nacquero così rsh e telnet, protocolli storici di Internet, noti anche per la sua semplicità.
Purtroppo proprio questa semplicità è anche uno dei loro maggiori limiti. Con la diffusione delle LAN e di Internet, telnet si è dimostrato un protocollo estremamente poco sicuro, in grado di compromettere la sicurezza del sistema. Il problema sta nel fatto che in LAN collegate da HUB, oppure su alcuni nodi di Internet è possibile con un banale sniffer intercettare il traffico passante. Risulta quindi abbastanza facile ottenere username, password, e dati trasferiti se il protocollo in questione non fa uso di cifratura. È il caso di telnet, ma, tra gli altri, anche di smtp, pop (se si esclude APOP) ed ftp.
Tra tutti questi quello potenzialmente più rischioso è senza dubbio telnet. Per questo si è pensato di creare un protocollo in grado di offrire le stesse caratteristiche di telnet, affiancandovi degli algoritmi di cifratura. È stato quindi creato SSH (Secure SHell) che risolve questo ed altri problemi di sicurezza. In particolare SSH è in grado di riconoscere se il computer che cerca di collegarsi a una macchina in remoto è sempre lo stesso che l'aveva fatto fino ad ora. Questo impedisce che qualcuno si "spacci" per qualcun altro cercando di ingannare i client che si collegherebbero a un server che non è in realtà quello che vorremmo contattare. Oltre alla shell, SSH è in grado di fornire gli strumenti necessari per il trasferimento cifrato di file, e di dati in generale.
Senza soffermarci troppo sui particolari tecnici di implementazione, lo scopo di questo articolo è quello di illustrare con esempi, alcune delle possibilità offerte da questo versatile strumento. Ovviamente in tutti gli esempi presi in esame all'host remoto sarà richiesta la presenza di un server SSH, e un client sul PC in locale (disponibili per praticamente tutti i sistemi operativi).
Come già detto lo scopo principale di SSH è quello di fornire una shell remota all'utente. In questo è del tutto simile a telnet. Se ad esempio noi dessimo come comando:
user@lnxbox1:~$ ssh andrea@linux.html.it
The authenticity of host 'linux.html.it (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is 9f:e8:fc:b4:6b:ff:1a:c2:d3:d1:c1:be:13:4c:bb:0a.
Are you sure you want to continue connecting (yes/no)?
Chi è loggato in locale (user) tenterà di collegarsi al server SSH presente sull'host linux.html.it usando come username andrea. Ma cosa vuol dire "Are you sure you want to continue connecting (yes/no)"? Il senso è questo: viene proposto all'utente un'identificativo del server. Se l'utente conosce questo identificativo, è in grado di affermare che il server è realmente quello che sta tentando di accedere. È una misura di sicurezza in più, per quanto possa sembrare una domanda minacciosa. Nella stragrande maggioranza dei casi possiamo rispondere "yes". A questo punto, risposto "yes", apparirà qualcosa del tipo:
Warning: Permanently added 'linux.html.it' (RSA) to the list of known hosts.
andrea@linux.html.it's password:
La prima riga ci avverte che il sistema che sarà riconosciuto come linux.html.it è quello che stiamo usando ora. Se l'IP di linux.html.it sarà associato ad un altro PC oppure verrà reinstallato SSH sul server, il sistema ci avvertirà che qualcosa è andato storto e che non è stato in grado di riconoscere il server SSH che si aspettava.
Inserita la password corretta ci verrà restituita una shell remota del tutto identica a quella utilizzata in locale.
Tra le innumerevoli opzioni offerte da ssh, -C consente di comprimere i dati trasferiti (molto utile su connessioni lente, utilizza la codifica di Lempel-Ziv, la stessa compressione usata da gzip, ma controproducente su reti veloci), -p consente di specificare una porta dove è in ascolto SSH (che di default è 22).
Un'altra delle possibilità offerta da SSH, non conosciuta a tutti, è quella del port forwarding. Per port forwarding si intende la ridirezione del traffico da una porta di un host a un'altra di un altro host (ma anche dello stesso host). È particolarmente utile per far "vedere" all'esterno server posizionati all'interno di una LAN. SSH dà in mano agli utenti (tutti gli utenti, al contrario di altri strumenti come ad esempio iptables, appannaggio del solo amministratore) la possibilità di rindirizzare il traffico, cifrando i dati di passaggio.
Per capire meglio questo esempio facciamo un esempio pratico. Poniamo di essere possessori di un account di posta su un server POP (ad esempio www.pop-e-ssh.com), sul quale è presente anche un server SSH. Come saprete in genere POP (con l'eccezione di APOP), trasferisce i dati (username/password e email) in chiaro.
Questo al giorno d'oggi non è di certo una soluzione sicura. Nel nostro esempio, la presenza di un server SSH sullo stesso computer con POP si rivela uno strumento che rende sicuro il trasferimento della nostra posta. Se sul nostro computer, dove è presente un client ssh, lanciamo il comando:
user@lnxbox1:~$ ssh -C andrea@www.pop-e-ssh.com -L 1500:www.pop-e-ssh.com:110
A questo punto verrà richiesta la password per l'accesso al sistema e aperta una shell sul server. Con questo comando specifichiamo inoltre di voler inoltrare tutto il traffico passante per la porta 1500 della macchina locale (lnxbox1) sulla porta 110 del server www.pop-e-ssh.com. Questo vuol dire che, una volta lanciato il comando e autenticateci sul server, ogni accesso verso la porta 1500 in locale verrà cifrato e spedito sul server POP. Impostando quindi il nostro client di posta mettendo come server dal quale scaricare la posta localhost e come porta remota 1500, in realtà scaricheremo la posta dal nostro server remoto (www.pop-e-ssh.com). E cosa più importante il trasferimento avverrà cifrato. L'opzione -C indica che vogliamo che il traffico sia anche compresso.
Un altro particolare di questo meccanismo è che in questo modo è possibile accedere a server presenti su un server remoto anche se questi non sono accessibili. Poniamo il caso ad esempio che sul nostro PC in locale sia consentito l'accesso verso l'esterno solo per ssh. Avendo accesso su un server (con ssh) che dispone ad esempio di un proxy, è possibile fare un port forwarding verso la porta del proxy, che non verrà filtrato dal firewall. Sarà quindi possibile accedere al proxy che ci consetirà di navigare sul web.
Nell'uso del port forwarding è bene ricordare che solo l'utente root può lasciare in ascolto le porte fino alla 1024, cosa da tenere in considerazione nella scelta delle porte in locale (ininfluente per quelle sul server remoto).
Quelli proposti in questo articolo sono solo alcuni esempi delle possibilità offerte da SSH. Vedremo successivamente come sia possibile ad esempio trasferire file in maniera sicura, risolvendo i problemi di sicurezza di FTP.
Dopo aver visto quanto può essere interessante l'utilizzo di SSH continuiamo ad analizzare le potenzialità di Secure Shell che, come avrete capito, è molto più di un semplice sostituto a telnet. Dopo aver discusso di come sia semplice e sicuro ottenere una shell remota con SSH, cerchiamo di trovare una soluzione ai problemi di insicurezza derivati da un'altro dei protocolli più diffusi e utilizzati su Internet: FTP. FTP infatti è per sua natura uno dei protocolli più insicuri presenti: sia l'autenticazione che il trasferimento dei dati, per quanto gestiti da un protocollo molto semplice, avvengono però in chiaro. A questo si aggiunge il fatto che storicamente alcuni demoni FTP sono stati affetti da vulnerabilità che hanno seriamente minato piu volte la sicurezza dei sistemi UNIX.
SSH fornisce una soluzione alternativa a due programmi: a rcp con scp e a ftp con sftp. Prima di continuare è necessario specificare che affinché il trasferimento di file over SSH funzioni è importante che sia presente la riga: Subsystem sftp /usr/lib/sftp-server nel file /etc/ssh/sshd_config del server.
SCP
Cosa è e a cosa server scp? La risposta è semplice: avete mai avuto la necessità di copiare dei file in rete da un PC all'altro? Probabilmente avrete usato FTP, ma avete mai pensato a quanto possa essere comodo utilizzare un comando simile a cp che copi però i nostri file anche attraverso una rete?
A questo ci pensa scp. La sintassi è molto simile a quella di cp. Ad esempio il comando:
user@lnxbox1:~$ scp miofile.txt mario@linux.html.it:
Dopo aver chiesto la password di "mario", account presente sul server linux.html.it, verrà copiato il file "miofile.txt" presente nella nostra homedirectory (lo capiamo dal fatto che il comando è stato eseguito quando il percorso corrente è l'home directory di "user", come notiamo dalla ~ del prompt) nella home directory dell'utente mario sul server linux.html.it. Ovviamente è possibile specificare anche un persorso sia esso locale o remoto. Questo necessita ovvimente la conoscenza almeno parziale dell'albero delle directory del server remoto. Ad esempio con il comando:
user@lnxbox1:~$ scp mario@linux.html.it:/var/data/backup/* /data
Dopo aver inserito la password per l'utente "mario" sul server linux.html.it verranno copiati tutti i file presenti nella directory /var/data/backup nella directory locale /data. Questo necessita ovviamente che sia la directory /var/data/backup che /data esistano già e che l'utente conosca la loro esistenza, in quanto per quel che riguarda le directory per l'host remoto non funzionano ad esempio meccanismi come il completamente automatico fornito dalla shell (bash ad esempio). Oltre a questo come per ssh, scp ammette anche l'utilizzo dell'opzione -C per la compressione dei file, cosa che può essere molto utile. È anche possibile specificare come argomento una directory e utilizzare l'opzione -r per copiarla ricorsivamente. Ad esempio con:
user@lnxbox1:~$ scp -C -r mario@linux.html.it:/var/data/backup /data
Copierà (dopo ovviamente aver inserito la password dell'utente mario) l'intera directory
/var/data/backup
ed eventuali subdirectory nella directory /data utilizzando un algoritmo di compressione durante il trasferimento. Come potete notare nei nostri esempi per i file "remoti" è necessario che la parte relativa all'host sia separata dal percorso da un:
Come con cp è anche possibile specificare più file nella riga di comando, come in questo esempio, con il quale copieremo i file /etc/passwd e /etc/group presenti sul PC in locale nella homedirectory (il semplice . dopo i : fa copiare i file nella home dell'utente) di mario su linux.html.it:
user@lnxbox1:~$ scp -C /etc/passwd /etc/group mario@linux.html.it:
Come per ssh è anche possibile specificare una porta differente sulla quale è in ascolto il nostro server. Contrariamente ai casi precedenti visti nel nostro precedente articolo l'opzione non è più -p ma -P. Come potete intuire, scp può essere utilizzato anche per copiare file tra due server differenti.
SFTP
Dopo aver visto scp probabilmente alcuni di voi avranno qualcosa da obiettare sulla poca facilità d'uso di questo comando. Innanzitutto è necessario conoscere la struttura delle directory dell'host remoto, o almeno quella che a noi interessa. Secondo, è concessa soltanto l'operazione di copia. A questi inconvenienti pone una soluzione sftp, un comando che vi darà un'interfaccia molto simile a quella di ftp, il client ftp utilizzato un pò in tutti i sistemi operativi (Microsoft inclusi).
La sua sintassi è molto semplice. Se ad esempio volessimo collegarci all'host linux.html.it con l'utente mario possiamo usare il comando:
user@lnxbox1:~$ sftp mario@linux.html.it
Molto similmente a quanto già visto con il comando ssh ci apparirà a schermo:
Connecting to linux.html.it...
mario@linux.html.it's password:
E una volta inserita la password ci verrà restituito:
sftp>
A questo punto ci troviamo davanti a un prompt molto simile a quello di FTP. Potremo ad esempio usare i comandi get, put per il trasferimento dei file, oppure ls o lls per la lista dei file presenti sul server o in locale. Analogamente è possibile usare lls, ls, mkdir, lmkdir, rmdir, ecc. proprio come se fossero "comandi" di un comune client FTP. Inoltre sono presenti anche dei client per moltissimi sistemi operativi, garantendovi la possibilità di poter completamente sostituire FTP con SFTP (alla homepage Simon Tatham ad esempio potrete scaricare un client ssh, scp e sftp per Windows). Come già visto negli altri casi, anche sftp consente il trasferimento di dati compressi usando l'opzione -C, che va data al momento della connessione. Ad esempio:
user@lnxbox1:~$ sftp -C mario@linux.html.it
Tenterà di connettersi al server linux.html.it con l'utente mario e gli eventuali dati trasferiti in seguito verranno compressi.
Prima di concludere è bene farvi notare che trasferire file con SSH ha lo svantaggio di appesantire il carico della CPU, in quanto questi verranno cifrati (ed eventualmente anche compressi). Questo può essere un "problema" su reti veloci (come ad esempio le LAN), dove su sistemi un pò datati il collo di bottiglia potrebbe essere il processore stesso. Nulla di grave, l'unico svantaggio al massimo consisterebbe nel non sfruttare al 100% la banda disponibile per la rete. Il suo utilizzo non ha ovviamente controindicazioni se i file vengono trasferiti su Internet, dove in genere non si hanno velocità paragonabili a quelle delle reti domestiche.
Come avete visto l'utilizzo di questi tool può risultare molto semplice, garantendoci una maggiore sicurezza dei nostri dati. È interessante notare come tutto questo sia stato ottenuto utilizzando un unico server, senza dover mettere in ascolto su altre porte altri programmi (come ad esempio un server FTP).
