SSH (Secure SHell, shell sicura) è un protocollo di rete che permette di stabilire una sessione remota cifrata tramite interfaccia a riga di comando con un altro host di una rete informatica. E' il protocollo che ha sostituito l'analogo ma insicuro Telnet.
Al giorno d'oggi la maggior parte delle comunicazioni su Internet avviene attraverso i protocolli della suite TCP/IP (POP, IMAP, SMTP, HTTP, X11, TELNET), che però sono nati in un'epoca in cui la possibilità di scambiarsi dati era considerata più importante rispetto alla sicurezza degli stessi.
Come risultato Internet, la cui infrastruttura è proprio basata su TCP/IP, è un mezzo di comunicazione fondamentalmente insicuro. Caratteristica dei protocolli elencati è, infatti, che tutte le transazioni avvengono in chiaro; cioè se qualcuno ha il controllo di una macchina situata in un punto qualsiasi del percorso di comunicazione che connette due host, può spiare il traffico ed analizzarlo alla ricerca di informazioni riservate come passwords, numeri di carte di credito, comunicazioni personali. Nelle future versioni del protocollo IP uno scenario del genere non sarà più possibile perchè si avrà una codifica dei dati in maniera trasparente. Fino ad allora l'unico modo per difendersi è quello di utilizzare la crittografia.
La crittografia è la scienza che studia le comunicazioni sicure. Crittografare un messaggio significa trasformarlo da una forma intelligibile in una forma inintelligibile: ciò avviene attraverso opportuni algoritmi che operano una trasformazione sul messaggio originale utilizzando le cosiddette "chiavi", cioè sequenze di bit la cui lunghezza può essere variabile. Solo il possessore della chiave giusta può effettuare la trasformazione inversa e riportare il messaggio in una forma intelligibile. All' aumentare della lunghezza della chiave di codifica diventa più difficile, per chi non possiede la chiave giusta, risalire al messaggio originale partendo da quello codificato.
Gli algoritmi di crittografia si possono classificare in due famiglie: a chiave simmetrica e a chiave asimmetrica.
Gli algoritmi di crittografia a chiave simmetrica sono chiamati cosi' perchè utilizzano la stessa chiave sia per la codifica che per la decodifica di un messaggio. L'inconveniente fondamentale di questa famiglia di algoritmi deriva dalla necessità di mettere d'accordo gli interlocutori sulla chiave da utilizzare. Dato che per scambiarsi la chiave deve esserci necessariamente una forma di comunicazione tra gli interlocutori, bisogna fare in modo che questa non avvenga attraverso un mezzo insicuro come può essere il telefono o, peggio ancora, la rete stessa. Un modo sicuro potrebbe essere, ad esempio, un incontro di persona, ma tale soluzione non è sempre praticabile.
Questo genere di inconvenienti viene superato con la crittografia a chiave asimmetrica. Ogni interlocutore dispone di una coppia di chiavi: una chiave pubblica che, come dice il nome, può essere divulgata, e una chiave privata che invece va custodita e protetta adeguatamente mediante password. Le due chiavi sono legate matematicamente tra di loro e non è in alcun modo possibile, in una scala di tempi ragionevolmente utile, derivare l'una dall'altra. La peculiarità di questi algoritmi è che un messaggio codificato con una delle chiavi può essere decodificato solo ed esclusivamente utilizzando l'altra chiave.
Anche questo tipo di crittografia però introduce un inconveniente, cioè la necessità di essere sicuri che una determinata chiave pubblica appartenga proprio all'interlocutore col quale stiamo comunicando. La soluzione è quella di accertarsene personalmente o, nel caso non sia possibile, affidarsi a entità esterne, che possono essere persone o enti di provata fiducia, che certificano e garantiscono l'associazione tra una chiave pubblica e il suo possessore, sia questi una persona o un host, una volta che ne hanno accertato l'identità. In questo modo, chiunque si fidi dell'entità esterna può fidarsi anche delle chiavi pubbliche certificate da quest'ultima.
Secure Shell.
Ssh è un protocollo di comunicazione nato per rimpiazzare i comandi Berkeley r* (rsh, rlogin, rcp) e a differenza di questi fornisce una infrastruttura per connessioni crittografate nonchè autenticazione forte tra host e host e tra utente e host. Chiude inoltre alcuni noti problemi di sicurezza dei protocolli TCP/IP come l'IP spoofing (falsificazione dell'indirizzo IP del mittente), il DNS spoofing (falsificazione delle informazioni contenute nel DNS) e il routing spoofing (falsificazione delle rotte intraprese dai pacchetti e instradamento su percorsi diversi).
I comandi r* possono essere addirittura rimpiazzati dalle rispettive versioni sicure (ssh, slogin, scp) in maniera trasparente per l'utente.
Esistono due versioni del protocollo ssh: la versione 1, più vecchia, che da questo momento in poi chiameremo ssh1, e la versione 2, che chiameremo ssh2, chè è una completa riscrittura della vecchia versione ed è più sicura.
Un ruolo primario nello scenario di ssh ce l'hanno due società finlandesi, la SSH Communications Security (http://www.ssh.org), che ha sviluppato i protocolli ssh1 e ssh2 e che mantiene le distribuzioni principali di ssh, e la Data Fellows (http://www.datafellows.com), che ha acquistato dalla prima la licenza di vendere e supportare ssh.
In particolare la Data Fellows ha imposto i limiti di utilizzo per il software: ssh1 può essere utilizzato liberamente a patto che non se ne ricavi guadagno; ssh2 invece può essere utilizzato liberamente solo privatamente o in ambito educational.
Tuttavia i protocolli ssh1 e ssh2 sono pubblicati come Internet Drafts e ci sono alcuni progetti che si occupano di scriverne una implementazione free: OpenSSH (http://www.openssh.com), nato per far parte del sistema operativo OpenBSD, implementa il protocollo ssh1 utilizzando solo algoritmi di crittografia non patentati, cioè senza restrizioni di utilizzo; OSSH (ftp://ftp.pdc.kth.se/pub/krypto/ossh/), che implementa il protocollo ssh1; lsh (http://www.net.lut.ac.uk/psst/), che implementa il protocollo ssh2.
Tutti i prodotti qui descritti sono sviluppati al di fuori degli U.S.A.: in questa nazione infatti vigono alcune leggi che impongono delle restrizioni sulla esportazione di prodotti che implementano crittografia forte; tali prodotti sono trattati dalle leggi alla stregua di armamenti militari e non possono utilizzare chiavi con lunghezza superiore ad un certo numero di bit, dipendente dall'algoritmo.
Come funziona ssh.
Le informazioni di seguito riguardano ssh1, la versione 1 del protocollo.
Ogni host su cui è installato ssh possiede una coppia di chiavi RSA (un algoritmo di crittografia a chiave asimmetrica) lunghe 1024 bit, una pubblica ed una privata. In più, ogni utente che utilizza ssh può opzionalmente generare una propria coppia di chiavi RSA.
All'atto della connessione, il server comunica al client due chiavi pubbliche: una fissa di 1024 bit che è la vera e propria chiave dell'host e l'altra di 768 bit che viene rigenerata ogni ora. Il client allora genera una sequenza casuale di 256 bit e la codifica con le chiavi pubbliche del server. Da questo momento in poi la connessione viene crittografata con uno degli algoritmi a chiave simmetrica supportati da ssh (IDEA, DES, 3DES, Arcfour, Blowfish) e si passa alla fase di autenticazione.
Ssh può autenticare un utente in vari modi:
- RhostsAuthentication:
questo metodo si basa sulla normale autenticazione dei comandi r*: se il nome dell'host client è inserito all'interno del file /etc/hosts.equiv sul server allora ad un utente è concesso il login senza password a patto che abbia uno username sul server uguale a quello sul client; analogamente è concesso il login senza password se la coppia "client username/client host" è inserita all'interno del file $HOME/.rhosts sul server (dove $HOME è la home directory dell'utente sul server).
Questo è il metodo di autenticazione meno sicuro, in quanto è suscettibile ai problemi di sicurezza descritti all'inizio ed in una installazione di default è disabilitato.
I file coinvolti in questo tipo di autenticazione sono i seguenti:
CLIENT
Nessuno
SERVER
/etc/hosts.equiv
$HOME/.rhosts
- RhostsRSAAuthentication:
questo è il metodo principale di autenticazione. Si basa fondamentalmente sulla RhostsAuthentication, ma l'identità dell'host client viene accertata attraverso la sua chiave pubblica RSA: il server possiede una copia della chiave pubblica degli host autorizzati alla connessione all'interno del file /etc/ssh_known_hosts ed inoltre ogni utente può crearsi una propria lista personalizzata di chiavi pubbliche utilizzando il file $HOME/.ssh/known_hosts, nella sua home directory sul server. Una volta accertata l'identità dell'host client la connessione viene autorizzata e il login viene effettuato con le modalità della RhostsAuthentication. Alternativamente ai file /etc/hosts.equiv e $HOME/.rhosts sul server si possono utilizzare i file /etc/shosts.equiv e $HOME/.shosts, di formato identico; in questo modo ci si svincola completamente da qualsiasi legame con i vecchi comandi r* e non si incorre nei loro problemi di security.
I file coinvolti in questo tipo di autenticazione sono i seguenti:
CLIENT
/etc/ssh_known_hosts
$HOME/.ssh/known_hosts
SERVER
/etc/ssh_known_hosts
$HOME/.ssh/known_hosts
/etc/hosts.equiv
/etc/shosts.equiv
$HOME/.rhosts
$HOME/.shosts
- RSAAuthentication:
questo tipo di autenticazione si basa sulla sola crittografia a chiave asimmetrica e presuppone che l'utente possegga una coppia di chiavi RSA. Se la chiave pubblica dell'utente è inserita nel file $HOME/.ssh/authorized_keys sul server, il server stesso genera una sequenza casuale di bit, la codifica con la chiave pubblica dell'utente e spedisce il tutto al client; il client decodifica con la chiave privata dell'utente la sequenza di bit e la rispedisce al server codificandola con le chiavi pubbliche del server. Cosi' facendo il client dimostra di conoscere la chiave privata, autenticandosi col server. Con questo tipo di autenticazione è richiesto all'utente di inserire la password che sblocca la sua chiave privata.
I file coinvolti in questo tipo di autenticazione sono i seguenti:
CLIENT
/etc/ssh_known_hosts
$HOME/.ssh/known_hosts
$HOME/.ssh/identity.pub
$HOME/.ssh/identity
SERVER
$HOME/.ssh/authorized_keys
Se un utente vuole utilizzare tale forma di autenticazione, è necessario che distribuisca la propria chiave pubblica a tutti i server ai quali vuole connettersi, in pratica copiando il contenuto del file $HOME/.ssh/identity.pub, presente all'interno della sua home directory sul client, all'interno del file $HOME/.ssh/authorized_keys sugli host server.
- TISAuthentication:
Questo tipo di autenticazione richiede la presenza di un server di autenticazione TIS: il server ssh cercherà di autenticare l'utente interagendo con il server di autenticazione TIS, agendo da tramite tra quest'ultimo e l'utente. Se l'utente viene autenticato dal server TIS, il server ssh concede l'accesso.
- Password:
Quando i metodi di cui sopra falliscono, all'utente viene chiesto di inserire la password del suo account sul server: da notare che la comunicazione sta comunque avvenendo in maniera crittografata.
Caratteristica interessante di ssh è la possibilità di effettuare una codifica di qualsiasi tipo di connessione, creando cosi' un canale di comunicazione crittografato tra client e server sul quale veicolare la connessione vera e propria. Questa caratteristica è chiamata port forwarding.
Nel caso del protocollo X11 ssh ne effettua in maniera automatica la codifica, a patto che dal lato client sia definita la variabile di ambiente DISPLAY: in questo caso, sul server al quale ci si è connessi, viene creato un X server fittizio e la variabile DISPLAY viene modificata in modo tale da puntare ad esso. Questo X server si occuperà in realtà solo di inoltrare i dati sul canale di comunicazione sicuro creato da ssh, che poi provvederà a passare i dati decodificati all'X server reale.
Prestazioni
Come è facile intuire, una comunicazione attraverso ssh avviene più lentamente rispetto ad una comunicazione non crittografata. La velocità della comunicazione dipende dall'algoritmo di crittografia utilizzato. Nel file README.CIPHERS, presente nella distribuzione standard di ssh, vengono elencate le prestazioni di ogni singolo algoritmo rispetto all'algoritmo "None" (nessuna crittografia) che viene quindi fissato come riferimento.
Abbiamo testato ssh su sessioni X11. Tale protocollo, per sua natura molto pesante, risente maggiormente di una lentezza della comunicazione rispetto, ad esempio, ad una sessione interattiva a caratteri o ad un trasferimento passivo di files.
Entrambi i test effettuati sono consistiti nella riproduzione di una serie di filmati attraverso il programma xanim versione 2.80.0 (http://xanim.va.pubnix.com).
Il primo test è consistito nel calcolo del tempo impiegato nella riproduzione di 3 filmati in formato AVI e 1 in formato MOV; ogni serie di filmati è stata riprodotta 5 volte e poi è stata calcolata una media dei tempi, il tutto per ogni algoritmo di crittografia supportato da ssh. Lo scopo è stato quello di verificare le prestazioni dei vari algoritmi di crittografia a chiave simmetrica.
Le macchine utilizzate per il test sono le seguenti, cosi' configurate:
ws1
Modello: Alphastation 255
CPU: Alpha 21064 a 233 Mhz
RAM: 128 MB
Interfaccia di rete: Fast Ethernet, 100 Mbit/s
S.O.: Digital Unix 4.0D
Versione ssh: 1.2.27
ws2
Modello: Alphaserver 1000 4/200
CPU: Alpha 21064 a 150 Mhz
RAM: 192 MB
Interfaccia di rete: FDDI su fibra ottica, 100 Mbit/s
S.O.: Digital Unix 4.0D
Versione ssh: 1.2.27
Il test è stato effettuato due volte, una utilizzando ws1 sia come client che come server e l'altra utilizzando ws1 come client e ws2 come server.
I dati rilevati sono riassunti nella seguente tabella:
Protocollo
Client
Server
Tempo 1
Tempo 2
Tempo 3
Tempo 4
Tempo 5
Media
%
Telnet
ws1
ws1
03:54
03:52
03:53
03:53
03:53
03:53
135%
Ssh/None
ws1
ws1
05:13
05:18
05:13
05:27
05:07
05:15
100%
Ssh/IDEA
ws1
ws1
07:31
07:27
07:24
07:44
06:11
07:15
72%
Ssh/DES
ws1
ws1
06:44
06:56
07:12
06:58
06:50
06:56
76%
Ssh/3DES
ws1
ws1
09:45
10:23
10:11
11:07
10:26
10:22
51%
Ssh/Arcfour
ws1
ws1
06:07
06:08
06:32
06:15
05:19
06:04
87%
Ssh/Blowfish
ws1
ws1
06:10
06:07
06:10
06:15
06:59
06:20
83%
Telnet
ws1
ws2
08:18
08:20
08:12
08:53
08:55
08:32
131%
Ssh/None
ws1
ws2
09:18
10:08
11:59
10:47
13:44
11:11
100%
Ssh/IDEA
ws1
ws2
17:52
16:47
15:07
19:18
18:00
17:24
64%
Ssh/DES
ws1
ws2
19:50
19:36
17:51
15:00
16:13
17:42
63%
Ssh/3DES
ws1
ws2
29:18
30:00
40:09
28:31
41:53
33:58
33%
Ssh/Arcfour
ws1
ws2
12:28
12:19
14:48
12:36
10:25
12:31
89%
Ssh/Blowfish
ws1
ws2
13:38
13:02
14:28
13:41
16:46
14:19
78%
Analogamente a quanto descritto nel file README.CIPHERS della distribuzione, abbiamo preso come riferimento l'algoritmo "None" assegnandogli una percentuale del 100%. Si può notare come le prestazioni di ssh in tale modalità siano inferiori rispetto ad una tradizionale connessione telnet.
A titolo comparativo, riportiamo i valori di performance cosi' come compaiono nel file README.CIPHERS:
None: 100%IDEA: 64%
DES: 71%
3DES: 45%
Arcfour: 91%
Blowfish: 88%
Il secondo test è consistito nella riproduzione del solo filmato in formato MOV, 5 volte e col calcolo della media dei tempi , utilizzando l'algoritmo di crittografia IDEA e variando i parametri di compressione della trasmissione, possibilità offerta da ssh. Lo scopo è stato quello di verificare l'effettiva convenienza dell'utilizzo della compressione nel caso di connessioni su WAN.
Le macchine utilizzate per il test sono le seguenti, cosi' configurate:
ws1 (Bari)
Modello: Alphastation 255
CPU: Alpha 21064 a 233 Mhz
RAM: 128 MB
Interfaccia di rete: Fast Ethernet, 100 Mbit/s
S.O.: Digital Unix 4.0D
Versione ssh: 1.2.27
pc1 (Firenze)
Modello: Personal Computer
CPU: Pentium II 450 Mhz
RAM: 512 MB
Interfaccia di rete: Fast Ethernet, 100 Mbit/s
S.O.: FreeBSD 3.4
Versione ssh: 1.2.27
I dati rilevati sono riassunti nella seguente tabella:
Compressione
Client
Server
Tempo 1
Tempo 2
Tempo 3
Tempo 4
Tempo 5
Media
%
None
ws1
pc1
15:53
15:53
15:54
15:43
15:28
15:46
100%
Fast (1)
ws1
pc1
11:55
11:19
12:06
10:55
10:45
11:24
138%
Slow (9)
ws1
pc1
14:34
14:13
14:17
14:14
14:01
14:16
111%
Abbiamo considerato come riferimento il comportamento di default di ssh, cioè nessuna compressione della trasmissione. Dalla tabella risulta che, almeno per quanto riguarda le connessioni su WAN, conviene in ogni caso abilitare la compressione. Il consiglio è quello di abilitarla, specialmente nel caso di trasmissioni utilizzanti una banda limitata.
Installazione e configurazione
Scaricare la distribuzione di ssh da ftp://ftp.cs.hut.fi/pub/ssh/
Per quanto riguarda ssh1 l'ultima versione al momento disponibile è la 1.2.27 mentre per ssh2 l'ultima versione è la 2.0.13. In ogni caso, dopo aver scaricato il file, per eseguire l'installazione è di norma sufficiente dare i seguenti comandi:
$ ./configure$ make
$ su
$ make install
ssh si compila senza problemi su una grande varietà di piattaforme. Una volta installato si deve fare in modo che il processo sshd parta automaticamente ad ogni bootstrap: questa fase richiede la modifica degli script di partenza e dipende ovviamente dal sistema operativo.
Da notare che sebbene gli algoritmi di crittografia a chiave simmetrica supportati da ssh siano sei (IDEA, DES, 3DES, Arcfour, Blowfish, None), alcuni di questi non sono abilitati in una installazione di default: DES perchè al giorno d'oggi non è ritenuto sicuro a causa della non sufficiente lunghezza della chiave utilizzata (56 bit); Arcfour perchè ha dei problemi di implementazione in ssh1, corretti però in ssh2; None perchè implementa una trasmissione non crittografata e dovrebbe essere usato solo per motivi di debugging o test.
Durante l'installazione viene generata anche la coppia di chiavi RSA per l'host.
Sebbene sia possibile definire già nel file di configurazione di sshd un elenco di hosts o domini abilitati alla connessione, è possibile compilare ssh con il supporto per i TCP Wrappers (ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz) di Wietse Wenema in modo tale che il controllo di accesso venga fatto utilizzando i files /etc/hosts.allow e /etc/hosts.deny: basta dare al comando configure il parametro --with-libwrap.
Per fare in modo che i vecchi comandi rsh, rcp e rlogin siano sostituiti dalle rispettive versioni sicure in maniera trasparente, bisogna compilare ssh dando al comando configure il parametro --with-rsh=<path>, dove <path> è una directory nella quale vanno copiati gli eseguibili rsh, rcp e rlogin; dopodichè ssh, slogin e scp vanno copiati al posto di rsh, rlogin e rcp, quindi rinominandoli. Inoltre va copiata la chiave pubblica dell'host, /etc/ssh_host_key.pub, all'interno del file /etc/ssh_known_hosts sui server ai quali ci si vuole collegare. Se su di un server remoto non è installato ssh, il client locale eseguirà il vecchio comando r* prendendolo dalla directory specificata all'atto della compilazione.
Uso.
ssh-keygen
Questo comando serve per la generazione di una coppia di chiavi RSA, delle quali è possibile scegliere la lunghezza in bit. Il comando viene utilizzato per generare la coppia di chiavi per l'host e per generare le chiavi degli utenti.
La sintassi è la seguente, con i flags più comuni:
$ ssh-keygen -b 1024 -N 'password'
Dove:
-b specifica la lunghezza in bit delle chiavi;
"password" serve per proteggere la chiave privata.
ssh, slogin
Questi sono i comandi per l'accesso ad un server remoto. slogin è in realtà un link simbolico all'eseguibile ssh.
La sintassi è la seguente, con i flags più comuni:
$ ssh [-vxC] [-l username] [-c cipher] host [comando]Dove:
-v abilita la modalità "verbose", utile per debugging;
-x disabilita il forward automatico delle connessioni X11;
-C abilita la compressione;
-l specifica lo username da utilizzare sul server, nel caso sia diverso dallo username locale;
-c serve per scegliere l'algoritmo di crittografia a chiave simmetrica da utilizzare per la connessione;
"comando" è un comando da eseguire sul server.
scp
Questo comando serve per trasferire files da locale a remoto o viceversa in maniera sicura.
La sintassi è la seguente, con i flags più comuni:
$ scp [-vrC] [-c cipher] [[user@]host1:]file1 [[user@host2:]file2Dove:
-v abilita la modalità "verbose";
-r copia un intero sottoalbero;
-C abilita la compressione;
-c serve per scegliere l'algoritmo di crittografia a chiave simmetrica da utilizzare per la connessione;
ssh-agent, ssh-add
Questi comandi servono per mantenere in memoria le chiavi private dell'utente in maniera da evitargli di digitare la password per sbloccarle ogni volta che si collega ad un server mediante RSAAuthentication.
La sintassi è:
$ ssh-agent [comando]Dove "comando" è di solito una shell oppure uno script di inizializzazione di una sessione X11. ssh-agent va a questo punto in background ed è pronto ad accettare le chiavi, fornitegli attraverso il comando:
$ ssh-add [file]Dove "file" è il nome del file contenente la chiave privata. Viene chiesta la password per sbloccarla, dopodichè ssh-agent si occuperà automaticamente di utilizzarla in maniera automatica per le connessioni con autenticazione RSAAuthentication.
Port forwarding
Come già detto, il port forwarding permette di creare un canale di comunicazione sicuro attraverso il quale veicolare qualsiasi conenssione TCP. Il suo funzionamento può essere spiegato attraverso un esempio.
Immaginiamo il seguente scenario:
Host A è separato dalla intranet da una rete insicura e deve comunicare via telnet con Host C. Host B permette connessioni ssh.
Con il port forwarding di ssh viene creato il canale sicuro tra Host A e Host B, mentre la connessione telnet vera e propria viene effettuata tra Host B e Host C.
Con il seguente comando, dato su Host A:
hostA> ssh -L 1111:HostC:23 HostB sleep 100viene allocata la porta TCP 1111 su Host A attraverso la quale, passando per il canale sicuro, si arriva alla porta 23 (telnet) di Host C.
Per completare la connessione vera e propria bisogna effettuare un telnet a questa porta:
hostA> telnet localhost 1111Da notare che Host B e Host C possono coincidere.
L'esempio illustrato riguarda il forwarding di una porta dall'host locale verso un host remoto. E' possibile effettuare anche l'operazione inversa, ossia il forward di una porta remota attraverso l'host locale.
fonte: Cert Garr
![Google Photo: backup automatico delle foto Desktop Cloud [Guida]](https://m22.paperblog.com/i/289/2891651/google-photo-backup-automatico-delle-foto-dal-L-zg6MH6-175x130.png)
![Dota Reborn update: risolto grave driver Linux [Changelog]](https://m2.paperblog.com/i/289/2891848/dota-2-reborn-update-risolto-grave-bug-per-dr-L-AwIGUZ-175x130.jpeg)
Pacman
Nostradamus
Magical Cat Adventure
Snake