Paolo Amendola
Versione 1.0: 10/03/2000

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.

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.

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:

• RhostsRSAAuthentication:

• RSAAuthentication:

• Password:

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.

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:

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:

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:

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.

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:

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.

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.

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:

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.

Questo comando serve per trasferire files da locale a remoto o viceversa in maniera sicura.

La sintassi è la seguente, con i flags più comuni:

Dove:

-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;

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 è:

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:

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.

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:

viene 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:

Da 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.

Ssh esiste, oltre che per i vari dialetti Unix, per altre piattaforme: esistono client per Windows, Macintosh, OS2, VMS, Windows CE e Palm Pilot. Per quanto riguarda i server lo scenario è un pò più desolato: attualmente esistono ssh server per VMS e Windows. Una particolare menzione va a Mindbright Technologies (http://www.mindbright.se/english) per aver sviluppato un client ed un server in Java, ma per il momento sono ancora parecchio limitati nelle funzionalità.

Abbiamo testato una serie di client e server ssh, free e commerciali, per piattaforma Windows. Per ognuno daremo una breve descrizione e in una tabella riassuntiva daremo le caratteristiche di ssh implementate.

Teraterm PRO - http://hp.vector.co.jp/authors/VA002416/teraterm.html
TTSSH - http://www.zip.com.au/~roca/ttssh.html

Teraterm PRO è un ottimo software di emulazione terminale Open Source per Windows, supporta comunicazioni su LAN con TCP/IP, comunicazioni attraverso la porta seriale e trasferimento file con i protocolli Kermit, Zmodem, Xmodem.

TTSSH è invece un plug-in per Teraterm PRO che implementa il protocollo ssh1.

Questa accoppiata è risultata quella più ricca di funzionalità. Unico punto a sfavore è la non possibilità di creare la propria coppia di chiavi RSA, cosa che invece va fatta in altra maniera importando poi le chiavi all'interno del programma.

Le versioni provate sono Teraterm PRO 2.3 e TTSSH 1.5.1.

F-Secure - http://www.datafellows.com/products/cryptography/f-sshtt.htm

Questa è una versione commerciale di un client ssh1. Manca di alcune funzionalità ma è possibile generare le proprie chiavi RSA all'interno del programma. Emulazione terminale abbastanza buona. La versione provata è la 1.1.

Putty - http://www.chiark.greenend.org.uk/~sgtatham/putty.html

Client ssh1 molto semplice, con funzionalità limitate. La versione provata è la 0.48. Da notare che l'autore ha anche sviluppato una versione di scp, reperibile allo stesso indirizzo.

Cedomir Igaly - http://www.doc.ic.ac.uk/~ci2/ssh/

Questo client ssh1 implementa quasi tutte le funzionalità del protocollo, manca solo della RhostsRSAAuthentication. E' possibile generare le proprie chiavi RSA dall'interno del programma. Funzionalità di emulazione terminale piuttosto limitate.

La versione provata è la 2.112.

Non scaricabile al di fuori degli U.S.A.

Oltre a questi programmi, scritti appositamente per Windows, esistono alcune versioni di ssh che sono state portate sul sistema operativo Microsoft partendo dal codice sorgente originale della versione Unix. Ciò è possibile utilizzando una particolare libreria che si occupa di tradurre le chiamate di sistema di Unix in corrispondenti chiamate di sistema Windows. In questo modo è in pratica possibile prendere un qualsiasi software scritto per Unix e, con poche modifiche, compilarlo e farlo funzionare sotto Windows.

Il progetto si chiama Cygwin (http://www.cygnus.com/cygwin) ed è portato avanti dalla software house Cygnus Solutions (http://www.cygnus.com). Tra i software portati sul sistema operativo Microsoft ci sono Apache, Sendmail, bash, tcsh, gcc, Lesstif, Xfree86.

Ovviamente è stato portato anche ssh, sia in versione client che server.

Tra le versioni di ssh portate menzioniamo Therapy, la versione di Gorden Chaffee e la versione di Sergej Okhapkin, la quale è risultata più funzionale. Di seguito diamo le istruzioni per installare la Cygwin su di un sistema Windows NT e configurare l'ssh server come servizio di sistema.

La piattaforma di test è un PC Pentium II con Windows NT 4.0 Service Pack 5 in inglese.

Cygwin è attualmente alla versione Beta 20.1 ed è distribuito in due versioni: una completa, costituita da librerie, header files, compilatori e tutto ciò che serve per lo sviluppo software, e una versione più leggera costituita dai soli tools utente, cioè una serie di comuni comandi unix (gcc, bash, man, diff) portati su Windows: noi abbiamo bisogno di quest'ultima.

Per l'installazione si procede in questo modo:

• Scaricare gli user tools da:

ftp://ftp.unina.it/pub/Unix/cygnus/cygwin/cygwin-b20/usertools.exe

ed eseguire l'installazione.

• Scaricare il pacchetto ssh versione 1.2.26 già compilato per Cygwin da:

http://dome.weeg.uiowa.edu/pub/domestic/sos/ports/ssh-1.2.26-cygwinb20.tar.bz2

supponiamo di metterlo nella directory C:\TEMP.

• Modificare il file C:\cygnus\cygwin-b20\cygnus.bat aggiungendo la linea:

SET CYGWIN=tty notitle

• lanciare la bash (dal menu Programs, Cygnus Solutions, Cygwin B20)
• eseguire dalla shell i seguenti comandi:

bash$  mkdir  /tmp  /etc  /bin  /usr/local/bin
bash$  mkpasswd  -l  >  /etc/passwd
bash$  mkgroup  -l  >  /etc/group
bash$  cp  /cygnus/cygwin-b20/H-i586-cygwin32/bin/sh.exe  /bin
bash$  bzip2  -d  /temp/ssh-1.2.26-cygwinb20.tar.bz2
bash$  cd  /
bash$  tar   xvf  /temp/ssh-1.2.26-cygwinb20.tar
bash$  ssh-keygen  -b 1024  -f  /etc/ssh_host_key  -N  ""

A questo punto la parte client è sistemata. Per quanto riguarda l'ssh server si può installare come servizio di Windows NT. Per fare ciò si può utilizzare l'utility SRVANY del Resource Kit di Windows NT 4.0. Nella versione Supplement 4 del kit c'è un wizard molto comodo che evita la modifica manuale del registry come accadeva nelle versioni precedenti. Installare il servizio sshd in modo che giri sotto l'account SYSTEM.

Bisogna inoltre modificare la variabile di ambiente PATH di Windows NT (Control Panel, System, Environment), aggiungendo la directory

dove si trova la libreria principale di Cygwin.

/etc/sshd.config
file di configurazione generale di sshd.

/etc/ssh_host_key
chiave privata RSA dell'host. Deve essere leggibile solo dall'utente root.

/etc/ssh_host_key.pub
chiave pubblica RSA dell'host. Deve essere leggibile da tutti.

/etc/ssh_known_hosts
elenco di chiavi pubbliche di hosts conosciuti.

$HOME/.ssh/known_hosts
analogo al precedente, ma personalizzabile dall'utente.

/etc/hosts.equiv
elenco di hosts abilitati al login senza password attraverso l'utilizzo dei comandi r*.

/etc/shosts.equiv
equivalente al file precedente, ma viene considerato solo da sshd.

$HOME/.ssh/authorized_keys
elenco di chiavi pubbliche RSA alle quali l'utente consente l'accesso attraverso RSAAuthentication.

$HOME/.rhosts
elenco di coppie host/username abilitate al al login senza password attraverso l'utilizzo dei comandi r*.

$HOME/.shosts
equivalente al file precedente, ma viene considerato solo da sshd.

/etc/ssh.config
file di configurazione generale di ssh.

$HOME/.ssh/config
analogo al precedente, ma personalizzabile dall'utente.

$HOME/.ssh/known_hosts
analogo al precedente, ma personalizzabile dall'utente.

$HOME/.ssh/identity
la chiave privata dell'utente.

$HOME/.ssh/identity.pub
la chiave pubblica dell'utente.

SSH Communications Security
http://www.ssh.org

Data Fellows
http://www.datafellows.com

Lsh
http://www.net.lut.ac.uk/psst/

Ssh FAQ
http://www.employees.org/~satch/ssh/faq

Ssh Network Negotiation
http://www.massconfusion.com/ssh/ssh_sample.html

Internet draft del protocollo ssh1
Presente all'interno della distribuzione principale di ssh1.

Internet drafts del protocollo ssh2
http://www.ietf.org/ids.by.wg/secsh.html

Man pages ssh-keygen, ssh, sshd, scp, slogin, ssh-agent.

Archivio mailing list di ssh
http://www.ssh.org/mailinglists.html

TCP Wrappers
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz

xanim
http://xanim.va.pubnix.com

Java ssh
http://www.mindbright.se/english

Teraterm Pro
http://hp.vector.co.jp/authors/VA002416/teraterm.html

Ttssh
http://www.zip.com.au/~roca/ttssh.html

F-secure
http://www.datafellows.com/products/cryptography/f-sshtt.htm

Putty
http://www.chiark.greenend.org.uk/~sgtatham/putty.html

Cedomir Igaly
http://www.doc.ic.ac.uk/~ci2/ssh/

Secure CRT
http://www.vandyke.com

Therapy
http://guardian.htu.tuwien.ac.at/therapy/ssh

Gorden Chaffee
http://bmrc.berkeley.edu/people/chaffee/winntutil.html

Sergej Okhapkin
http://www.lexa.ru/sos

GARR-CERT
http://www.cert.garr.it