1 Introduzione

 

1.1 Motivazioni

 

In tempi di rete onnipresente, l'accesso ad un sistema remoto è una cosa normalissima. Sia che ritiriamo la posta, gestiamo un server o aggiungiamo un articolo ad una pagina web di un sistema redazionale, un'autenticazione deve sempre seguire la nostra persona. Ogni utente dovrebbe sapere che il suo user ID e la sua password sono cose che appartengono solo a lui. Inoltre 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 (quindi le informazioni e i dati degli utenti passano attraverso la rete in chiaro e senza alcuna protezione); quindi 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. Questo concerne, da una parte, la sfera privata dell'utente e, dall'altra, apre un accesso all'abuso. Tali accessi vengono usati, in particolare, per attaccare altri sistemi da questo punto di partenza o per ottenere su questo sistema diritti di amministratore o di root. Il pericolo a cui viene esposto un sistema diventa evidente quando vengono eseguiti lavori come utente 'root' attraverso la rete: è come se si annunciasse alla radio dove sono nascoste le chiavi di riserva di casa! Ogni dispositivo coinvolto nell'inoltro dei dati o impiegato nella stessa rete locale come firewall, router, switch, mailserver, workstation, ecc., è in grado di prendere visione dei dati. Contrariamente agli evidenti maneggi da parte di terzi, a cui può venir sottoposto un documento inviato per posta, il ricevente di dati digitali non può rendersi conto dell'abuso fatto nei confronti dei suoi dati. Fondamentalmente, le regole giudiziarie vigenti proibiscono un tale procedimento, ma, a causa delle molteplici possibilità di attacchi e della bassa quota di chiarimenti, è consigliabile non farvi affidamento. 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.

 

1.2 Panoramica di SSH

Il software SSH offre l'alternativa che si cerca: tutta l'autenticazione (in generale user ID e password) e la comunicazione avvengono in forma cifrata; anche qui, è ancora possibile la registrazione dei dati trasmessi, ma a causa della chiave mancante, il contenuto non può venire identificato. Ciò rende possibile una comunicazione sicura su una rete insicura come Internet. Secure Shell (SSH), scritto in origine da Tatu Ylönen, finlandese, è un protocollo di comunicazione nato per rimpiazzare i comandi Berkeley r* (rsh, rlogin, rcp), telnet e ftp, con le rispettive versioni sicure (ssh, slogin, scp, sftp). Una compressione dei dati viene fornita come opzione e può essere utilizzata insieme a molti schemi di autenticazione come SecureID, Kerberos e S/KEY per fornire un accesso remoto altamente sicuro a server UNIX. SSH fornisce quindi, un'infrastruttura per connessioni crittografate nonché autenticazione forte tra due host o tra un utente e un host. Risolve, 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). Con SSH è anche possibile rendere sicuro un qualunque altro protocollo allo strato di applicazione tramite la tecnica del TCP port forwarding.

SSH1 è stata la prima versione (protocolli v1.2 e v1.5), gratuita in un primo tempo, ma la licenza è diventata più restrittiva e SSH Communications e DataFellows stanno cercando di far adottare la nuova SSH2 (che è commerciale). Comunque SSH1 è destinata ad avere ancora lunga vita come freeware, ora che SSH è stata rilasciata dal team e dalla comunità OpenBSD.

 

Perché SSH?

I comandi Telnet, rlogin, rcp, rsh hanno parecchi punti deboli quanto a sicurezza: tutte le comunicazioni sono in chiaro e nessuna autenticazione viene svolta dalla macchina. Questi comandi sono suscettibili di intercettazione e allo spoofing dell'indirizzo IP. Ricordiamo che per "spoofing" si intende la sostituzione dell'indirizzo reale con uno falsificato. Un secondo strumento chiave di UNIX, il sistema X-Window, comunica anch'esso in chiaro, usa porte dinamiche (rendendo difficile il filtraggio di pacchetti) e ha un sistema di controllo di accesso, il meccanismo "xhosts" e "xauth", difficile da usare. Pochi utenti lo capiscono per cui il controllo di accesso a X11 sui desktop UNIX è di solito insicuro.

SSH usa l'autenticazione a chiave pubblica/privata RSA per verificare l'identità delle macchine connesse, e la crittograffazione di tutti i dati scambiati (con algoritmi robusti come blowfish, 3DES, IDEA ecc.). La compatibilità all'indietro verso rlogin/rsh e i loro file (rhosts, hosts.equiv) è supportata per permettere la connessione con server non SSH. In opzione, un canale criptato per le comunicazione X11 può essere automaticamente impostato da SSH (usando il controllo xauth e la variabile di ambiente DISPLAY).

SSH protegge da:

·        Intercettazione di dati trasmessi tramite la rete.

·        Manipolazione di dati negli elementi intermedi della rete (come i router).

·        IP address spoofing dove l'host attaccante finge di essere uno affidabile inviando pacchetti con l'indirizzo di questo.

·        DNS spoofing di server DNS fidati.

·        IP source routing

 

SSH non protegge da:

·        Configurazione o utilizzo scorretto (vede gli svantaggi sotto).

·        Un account root compromesso. Se vi loggate da un host a un server e l'aggressore ha i privilegi di root dall'altra parte, può vedere la vostra sessione leggendo il device dello pseudo-terminale. Anche se la cifratura SSH crittografa la rete, deve comunicare in chiaro con i dispotitivi di terminale.

·        Directory home insicure: se un aggressore può modificare i file nella vostra home directory (per esempio via NFS), può essere in grado di aggirare SSH.

 

Funzionalità

SSH può essere usata per loggarsi in modo sicuro su un altro computer in una rete, eseguire comandi sul sistema remoto, e copiare file da una macchina all'altra. SSH fornisce comunicazioni e autenticazioni sicure su canali che non lo sono. Dovrebbe essere usata come rimpiazzo per rlogin, rsh, and rcp. In aggiunta a ciò, SSH fornisce protezione per le connessioni X11 e per l'inoltro dei pacchetti di quelle TCP.

·        Supporta sistemi di autenticazione fortemente protetti come RSA, SecurID, S/Key, Kerberos e TIS (così come la consueta procedura UNIX di username/password).

·        Esistono tre sistemi di sicurezza: shosts, rhosts compatibile e RSA. RSA è la più sicura (usa un sistema a chiave pubblica/privata per identificare le connessioni), ma scavalca l'autenticazione username/password di UNIX.

·        Il server SSH gira su UNIX, Linux e VAX. I Client girano su questi, e anche su Windows e molte altre piattaforme.

·        La compressione dei dati può essere attivata per migliorare le prestazioni su reti lente.

·        Proxy Internet SSH:  SSH può essere compilato in modo che possa attraversare i proxy SOCKS. SOCKS è un protocollo generale per i proxy,    inizialmente sostenuto da NEC, ma disponibile ora presso molti altri fornitori.

SSH2 è la nuova versione del protocollo, proposto all'IETF per approvazione da parte di SSH Communications. Si tratta di una riscrittura (con crittografia migliorata) ed è progettata per VPN a uso generale. SSH2:

·        Include sftp, un ftp cifrato SSH2.

·        Usa file di configurazione separati da SSH1 (/etc/ssh2/ssh2_config), ma può richiamare SSH1 se un client ne richiede i protocolli SSH1 e se SSH1 è disponibile.

·        Mantiene la compatibilità con SSH1, se questo è stato installato prima di SSH2.

·        Supporta scambi con chiavi DSA e Diffie-Hellman.

·        A causa della commercializzazione (si veda la licenza sotto), l'accettazione di SSH2 è stata lenta.

 

Connessioni Crittografate

I dati scambiati con SSH sono cifrati con algoritmi a chiave simmetrica negoziati tra le parti. Le chiavi per gli algoritmi di cifratura sono scambiate in precedenza. La cifratura previene, tra le altre cose, gli attacchi di tipo sniffing (cattura del traffico passante per una interfaccia di rete).

 

Autenticazione Forte

L'autenticazione, nella sua struttura più semplice, consiste nell'inserzione di una password. Scopo di SSH era l'introduzione di un software sicuro e contemporaneamente semplice da usare, cioè, come per i programmi da sostituire (rsh e rslogin), anche SSH deve offrire un metodo semplice di autenticazione. L'autenticazione degli host e in alcuni casi degli utenti, avviene tramite algoritmi a chiave pubblica. Per l'autenticazione su un host remoto il daemon di SSH (Sshd) genera due coppie di chiavi, costituite da una parte pubblica ed una privata. Ogni host su cui è istallato un server SSH ha almeno una coppia di chiavi per ogni algoritmo a chiave pubblica supportato. Tali chiavi sono di solito generate al momento dell'istallazione. Ogni host mantiene un database con le chiavi pubbliche degli altri host conosciuti. In particolare, i client utilizzano  il file /etc/ssh/known_hosts per memorizzare le chiavi dei server SSH conosciuti. In aggiunta, ogni utente ha il suo database personale nel file $HOME/.ssh/known_hosts. I server hanno il file /etc/ssh_known_hosts per memorizzare le chiavi host dei client, inoltre i file  $HOME/.ssh/authorized_keys contengono le chiavi degli utenti autorizzati ad eseguire il login. I database vengono aggiornati nel modo seguente: è aggiunta una nuova chiave pubblica del server, a cui il client si connette per la prima volta,  nel database del client se sono validi i certificati che accompagnano la chiave. In assenza di essi il client chiede all'utente la fiducia nella chiave del server e la memorizza in caso affermativo. Il server memorizza nuove chiavi utente se accompagnate da certificati o se è già certo dell'identità dell'utente perché è già avvenuta l'autenticazione con altri metodi. Per quanto riguarda l'autenticazione utente, invece, SSH la realizza con una supplementare coppia di chiavi, questa volta generata dall'utente stesso. A questo scopo SSH offre il programma di aiuto ssh-keygen. Ad esempio, dopo aver digitato:

giovanni@sole:~> ssh-keygen

Generating RSA keys:

trascorre un po' di tempo prima che la coppia di chiavi sia generata. Viene, inoltre richiesto il file di base per l'archiviazione delle chiavi:

Enter file in which to save the key: /home/giovanni/.ssh/identity

Dopodiché bisogna salvare l'impostazione con una passphrase per poter continuare in seguito:

Enter passphrase (empty for no passphrase):

Anche se il software consiglia di lasciare vuota la passphrase, è preferibile scegliere un testo da 10 a 30 caratteri di lunghezza e, se possibile, bisognerebbe evitare di inserire parole o frasi semplici. Avvenuto l'inserimento, per conferma ne viene richiesta la ripetizione; successivamente viene mostrato l'output del deposito delle chiavi, pubblica e privata, (nel nostro esempio nei file identity e identity.pub). 

Enter same passphrase again:

Your identification has been saved in /home/giovanni/.ssh/identity.

Your public key has been saved in /home/giovanni/.ssh/identity.pub.

The key fingerprint is:

79:c1:79:b2:e1:c8:20:c1:89:0f:99:94:a8:4e:da:e8 giovanni@sole

Bisogna usare una passphrase specialmente nei casi in cui la chiave privata viene creata e rimane in un sistema non amministrato direttamente dal proprietario della suddetta chiave, oppure nei casi in cui si riceve la directory utente via NFS. Usando ssh-keygen -p, è possibile modificare la propria vecchia passphrase. A questo punto bisogna copiare la parte pubblica della chiave (identity.pub) sul computer remoto e lasciarvela come: ~/.ssh/authorized_keys. Come convalida, al prossimo accesso, sarà richiesta la passphrase. Nel tempo, questo procedimento risulta più faticoso dell'inserimento di una password; di conseguenza il pacchetto SSH fornisce un altro programma di aiuto, l'ssh-agent, che tiene pronte le chiavi private per tutta la durata di una "X-session"; per questo scopo, l'X completo viene avviato come processo figlio dell'ssh-agent. Questo procedimento si può semplicemente realizzare ponendo a yes la variabile usessh che si trova nel file .xsession ed eseguendo il login tramite un display manager (ad esempio KDM o XDM). Alternativamente si può usare ssh-agent startx. Appena la sessione è avviata si può sbloccare la propria chiave con ssh-add: purché ssh-add non possa accedere ad un terminale (ad esempio se viene chiamato tramite un menù), appare una richiesta grafica di inserzione x11-ssh-askpass. A questo punto si possono usare ssh e scp come al solito. Distribuendo la chiave privata nel modo sopra citato, non dovrebbe più essere richiesta la password. Infine bisogna fare molta attenzione, quando si smette di usare il computer, a terminare la propria X-session o a bloccarla tramite una chiave dello schermo (ad esempio xlock) protetta da password.

Una nota debolezza nei sistemi UNIX è la vulnerabilità del sistema di autenticazione rhosts ad attacchi di spoofing. Ecco le azioni da compiere per un hacker H in un tipico attacco di IP spoofing. Si suppone che l'attacco venga portato dall'account di root di H all'account di root dell'host target.

·        Scegliere l’host target (B)

·        Scoprire l’indirizzo IP di un host fidato (A): tale indirizzo è contenuto nel file /etc/hosts.equiv di B

·        Disabilitare A per evitare che si accorga dell'attacco: i pacchetti di ritorno da B arrivano di norma ad A, che potrebbe accorgersi quindi del tentativo di connessione di H con il proprio indirizzo IP. Utilizzando la tecnica del TCP SYN flooding è possibile fare in modo che A scarti tutti i pacchetti di sincronizzazione che riceve da B. L'attacco viene portato nel modo seguente: H invia un certo numero di messaggi di sincronizzazione alla porta di A che desidera disabilitare, fino ad eccedere il limite superiore (backlog) per le connessioni incomplete (3-way handshake incompleto) stabilito per quella porta. Una volta raggiunto il backlog, TCP scarta tutti i messaggi di sincronizzazione, finchè le connessioni pendenti non sono completate

·        Utilizzare l’indirizzo IP di B per ottenere una shell su B cercando di indovinare i Seqence Number: N.B.: H potrebbe catturare i pacchetti in uscita da B falsificando la rotta di ritorno (ROUTING SPOOFING)

·        Aggiungere il proprio indirizzo in /etc/hosts.equiv su B

Si può approfittare della debolezza di rhosts anche falsificando le informazioni contenute nel DNS dell'host target; il DNS è un servizio di Internet che, utilizzando un database distribuito, risolve i nomi host in indirizzi IP. Ecco le azioni da compiere per un hacker H in un tipico attacco di DNS spoofing.

SSH risolve il problema della debolezza del meccanismo di autenticazione rhosts aggiungendo un controllo sull'host più rigoroso. Al metodo classico del controllo dell'indirizzo IP è affiancato un controllo basato su algoritmi a chiave pubblica.

 

TCP Port Forwarding

Con Secure Shell è possibile rendere sicuro anche un qualsiasi protocollo allo strato applicazione, come ad esempio FTP, HTTP e SMTP. Facciamo un esempio in cui può essere resa sicura una connessione HTTP. Consideriamo lo scenario nella figura sottostante.

 

 

Sull'host A gira un web browser, che desidererebbe stabilire una connessione sicura con l'host C, su cui gira un Web server. Il percorso che connette A con la sottorete comprendente C è insicuro, e dunque soggetto ad ogni sorta di attacco. Si suppone che la sottorete comprendente C sia sicura e che in essa sia presente un host (B, nel nostro esempio), su cui gira un server SSH. Possiamo brevemente riassumere con i seguenti passi il metodo utilizzato per rendere la connessione sicura sul percorso insicuro da A alla sottorete comprendente C:

 
Deviazione di X, dell'autenticazione ed altre deviazioni

Oltre ai miglioramenti della sicurezza finora descritti, ssh facilita anche l'uso di applicazioni X-remote. Se si inserisce ssh con l'opzione -x, sul sistema remoto viene automaticamente impostata la variabile DISPLAY e tutte le emissioni di X vengono deviate, tramite il collegamento ssh, al computer iniziale. Questa comoda funzione impedisce contemporaneamente le possibilità di intercettazione esistenti finora nelle applicazioni X chiamate su un computer remoto e osservate sul computer locale. Tramite l'opzione impostata -A, il meccanismo di autenticazione ssh-agent viene adottato dal prossimo computer: in questo modo è anche possibile guardare da un computer all'altro senza dover inserire una password; questo, però, può essere fatto solo se in precedenza sono state distribuite e archiviate correttamente le chiavi pubbliche sui computer meta interessati. Per motivi di sicurezza, nella preimpostazione, entrambi i meccanismi sono disattivati, ma possono essere attivati permanentemente nel file di configurazione del sistema (/etc/ssh/sshd.config) o in quello proprio dell'utente (~/.ssh/config). Analogamente alla deviazione di X, è possibile utilizzare ssh per la deviazione di collegamenti TCP/IP. Ad esempio, consideriamo la deviazione di SMTP e POP3:

root@terra:~ # ssh -L 25:sole:25 sole

Qui, tramite il canale criptato, viene deviato ogni collegamento SMTP con "terra port 25" sul port SMTP di "sole". Ciò è utile specialmente per quegli utenti di servers SMTP che non hanno le facoltà SMTP-auth o POP-before-SMTP. In questo modo la mail può essere trasmessa da un qualsiasi luogo e consegnata al mail-server "di casa". Analogamente:

root@terra:~ # ssh -L 110:sole:110 sole

inoltra tutte le richieste POP3, che entrano attraverso il port 110, a terra sul port POP3 di sole. Entrambi questi esempi devono essere eseguiti come utente root perché così si è collegati su porte locali privilegiate. Con un collegamento SSH già esistente, la posta viene spedita e ritirata (come d'uso) come utente normale. L'host SMTP e POP3 devono essere configurati su local host.

 
Licenze e costi

Esistono oggi molte versioni di SSH, alcune delle quali implementano solo il client, altre sia il client che il server. Sono in uso licenze commerciali, freeware e "restricted freeware". La versione originale di SSH (SSH1) implementata da Tatu Ylönen era gratuita, ma quelle successive alla 1.2.12 hanno licenze restrittive. L'attuale SSH1 v1.2.27 indica che può essere usata solo per scopi non commerciali, ma sembra che molte situazioni permettano l'uso gratuito:

“E' possibile  usare il programma solamente per scopi non commerciali, si intende cioè che il programma non deve essere venduto come prodotto separato, come componente di un prodotto o un progetto più grande, o altrimenti utilizzato a scopo di lucro senza una licenza separata...

L'uso da parte di individui e organizzazioni non profit è sempre concesso...

Alle aziende è concesso di usare questo programma finché non è utilizzato a fini di lucro....”

SSH2 ha una licenza più restrittiva, praticamente è gratuito solo per le organizzazioni non profit:

“COMMERCIALE: qualsiasi utilizzo che abbia luogo in organizzazioni commerciali, governative, militari o simili, e che comporti un salario o una retribuzione pecuniaria, a meno che l'uso possa essere considerato EDUCATIVO o a scopo puramente caritatevole.”

 

Credits

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 brevettati, cioè senza restrizioni di utilizzo.

Tutti i prodotti qui descritti sono stati sviluppati al di fuori degli U.S.A.: in questa nazione infatti vigevano alcune leggi che imponevano delle restrizioni sulla esportazione di prodotti che implementano crittografia forte; tali prodotti erano trattati dalle leggi alla stregua di armamenti militari e non potevano utilizzare chiavi con lunghezza superiore ad un certo numero di bit, dipendente dall'algoritmo.

 
 
Esportazione dagli USA e limiti di brevetto

SSH contiene algoritmi di cifratura forte (non ne esiste una versione debole), che ne rende impossibile l'esportazione dagli Stati Uniti con le leggi attuali (cosa che dovrebbe cambiare nei prossimi mesi). Fortunatamente, SSH, è stato sviluppato in Finlandia, per cui non c'è problema per la sua esportazione verso il resto del mondo.

L'algoritmo RSA è brevettato negli USA, gli utenti statunitensi di SSH dovevano usare RSAREF,  una  libreria ufficiale della RSA e pagarne i diritti. Questo brevetto, comunque, è scaduto nel settembre del 2000.

Tutto ciò rende molto difficile per i produttori di sistemi operativi degli USA includere SSH nei loro prodotti, OpenBSD (canadese) e la distribuzione Linux SuSE (tedesca) includono entrambe SSH.

L'algoritmo IDEA, brevettato in Svizzera dalla Ascom (ed è gratuito solo per usi non commerciali), è usato da SSH, ma può essere disabilitato durante la compilazione del server.

Vantaggi:

·        Cifratura internazionale forte, non ne esistono versioni poco sicure.

·        Esistono entrambe le versioni libera e commerciale.

·        Il client SSH gira su molte piattaforme, il server gira su UNIX, Linux e VMS.

·        Il tunneling delle porte TCP statiche funziona bene e può essere automatizzato per l'uso su semplici VPN.

·        Molti sistemi di autenticazioni, inclusi Kerberos, TIS, SecurID e RSA.

·        Gestisce proxy SOCKS5.

Svantaggi:

·        Gruppi di porte e porte dinamiche non possono essere inoltrate con il packet forwarding.

·        Poche verioni per Windows implementano la copia sicura di file o la generazione delle chiavi.

·        Il demone SSH1:

o       Non può limitare quali porte possono o non possono essere inoltrate, per utente.

o       Quando un utente è autenticato dalla password, l'identità del client RSA non è verificata (con ssh_known_hosts). La verifica avviene solo quando si usano .[sr].host.

·        Le prestazioni possono costituire un problema su vecchie macchine (tipo Sun SPARC1 con 16MB di ram, ma quante ce ne sono ancora in giro?).

·        La distribuzione standard di SSH1 include di default un opzione per la trasmissione in chiaro e dei programmi sotto brevetto come IDEA. Comunque, si possono disattivare (vede la configurazione sotto).

·        La licenza dei sorgenti è diventata molto restrittiva (vedi sopra). 

 

1.3 Compilazione & Configurazione

Compilazione SSH1:

·        Uno strumento di installazione per RPM di Linux è disponibile a

ftp.yellowdoglinux.com/pub/yellowdog/install-ssh.

·        Compilare SSH1 per UNIX (gli esempi che seguono sono per Solaris) è semplice. Supponiamo di volere le opzioni standard, ma di voler disabilitare le comunicazioni in chiaro, il vecchio algoritmo RSH/rlogin e l'algoritmo IDEA:

gzcat ssh-1.2.27.tar.gz | tar xf - 
cd ssh-1.2.27; ./configure --prefix=/usr --without-none --without-rsh --without-idea
make
make install

Il demone SSH dovrà essere aggiunto negli script di avvio, operazione che non è svolta da "make install".Un esempio per Solaris potrebbe essere creare il file /etc/rc2.d/S10sshd.

·        Opzioni utili di compilazione:

o       --without-idea: non usa l'algoritmo brevettato IDEA.

o       --without-none: non consente le comunicazioni in chiaro (non cifrate) se uno dei server non ha chiavi.

o       --without-rsh: non consente l'opzione rsh rhosts quando un server non ha chiavi.

o       --prefix=/usr/bsd --sbindir=/usr/bsd --bindir=/usr/bsd: per installare in directory non standard.

o       --with-securid=../ace: aggiunge il supporto per l'autenticazione SecurID (sono necessarie le librerie ACE).

o       --with-socks5=/usr/local/lib: supporto per proxy Socks5.

 

·        Preparazione di un pacchetto di installazione binaria: per semplificare la vita, compilate su una macchina come quella descritta sopra (per esempio), quindi create un file tar dei binari (nella C-Shell). La procedura seguente presuma che abbiate copiato alcuni dei documenti SSH come le FAQ in /usr/localssh-docs:

o       tar uvf ssh_bin.tar /usr/local/bin/ {ssh-keygen1, ssh-keygen, ssh-agent1, ssh-agent}

o       tar uvf ssh_bin.tar /usr/local/bin/ {ssh-add1, ssh-add, ssh-askpass1, ssh-askpass}

o       tar uvf ssh_bin.tar /usr/local/bin/ {make-ssh-known-hosts1, make-ssh-known-hosts}

o       tar uvf ssh_bin.tar /etc/ {sshd_config, ssh_config}

o       tar uvf ssh_bin.tar /etc/rc2.d/ {S10sshd, K10sshd} /etc/init.d/sshd

o       tar uvf ssh_bin.tar /usr/local/sbin/ {sshd, sshd1}

o       tar uvf ssh_bin.tar /usr/local/man/man1/ {ssh-keygen.1, ssh-agent.1, ssh-add.1, ssh.1, ssh1.1, slogin.1, slogin1.1, scp.1, scp1.1, make-ssh-known-hosts.1} /usr/local/man/man8/ {sshd.8, sshd1.8}

o       tar uvf ssh_bin.tar /usr/local/ssh-docs

o       compress ssh_bin.tar

 

·        Installazione su molte macchine:

o       Copiate ssh_bin.tar.Z (creato prima) nel sistema su cui installate, facendo prima un backup dei file di configurazione esistenti, compattatelo nella root, “rehash” (se usate csh) e quindi generate una chiave per l’host:

     ssh-keygen -b 1024 -f /etc/ssh_host_key -N '';

o       Aggiungete il servizio ssh, aggiungendo le linee seguenti a /etc/services:

     ssh 22/tcp # Secure Shell

o       Avviate il demone ssh:

sh /etc/rc2.d/S10sshd start

 

·        Su OpenBSD 2.6, OpenSSH è già installato, ma diciamo che vogliate installare SSH1 o che abbiate una versione vecchia di OpenBSD e non siate residenti negli USA, quindi, a scelta:

o       pkg_add ftp.openbsd.org/pub/OpenBSD/2.6/packages/sparc/ssh-intl-1.2.27.tgz

o       O compilate dai sorgenti:

a)      Aggiornare la lista delle versioni se necessario, ma ricordate che questo richiede tempo e dovete scegliere il server CVS attentamente   

      (controllate www.openbsd.org/anoncvs.html):  

setenv CVSROOT anoncvs@anoncvs.ca.openbsd.org:/cvs

       Per una nuova lista delle versioni:

cd /usr; cvs -q get ports

       Per aggiornare una versione esistente:

cd /usr; cvs -q update ports

b)      Verificate quali versioni di SSH sono disponibili:

cd /usr/ports; make search key=ssh

      Questo indica che ssh-1.2.27 è disponibile (per esempio) in /usr/ports/security/ssh

c)      

cd/usr/ports/security/ssh;

make all install USA_RESIDENT=no;

Questo dovrebbe scaricare il sorgente più una patch e compilarli. Se ci sono errori con il make, aggiornate la lista delle versioni (sopra) e riprovate. Usate "pkg_info" per verificare che sia registrata e installata sul sistema, potete poi cancellarla con "pkg_delete".

 

SSH1 Configurazione

·        File di configurazione: il server ha un file di configurazione, il file /etc/sshd_config, il client legge la configurazione da /etc/ssh_config, che contiene settaggi di default a livello di sistema. La configurazione di questo file può essere scavalcata da file di configurazione specifici di ogni utente (nella directory ~user/.ssh).

·        Server: configurate il demone ssh in modo che l'accesso sia limitato agli host specificati per nome e con chiavi pubbliche note (/etc/ssh_known_hosts)  e l'autenticazione rhosts sia disabilitata. Alcuni esempi commentati si trovano in /etc/sshd_config. In particolare, notate queste opzioni:

o       StrictHostKeyChecking può essere usata per prevenire accessi alle macchine la cui chiave non sia nota o sia cambiata. Se questo flag è impostato a "yes", ssh non aggiungerà mai le chiavi ai file /etc/ssh_known_host o $HOME/.ssh/known_hosts file, e rifiuterà di connettersi a host la cui chiave sia cambiata. Questo fornisce la massima protezione da attacchi basati su trojan. In molti casi, l'ideale è impostare su "ask" per chiedere all'utente se aggiungere la chiave o menol.

o      RhostsRSAAuthentication, se impostata a "yes", permette a ~/.shosts di definire i rapporti di trust. Può essere impostata a "yes", "nopwd", o "no". Se è "nopwd" vengono disabilitati gli accessi come root autenticati da password, a meno che non si tratti di un .shosts che consenta l'accesso senza password. Il login come root con l'autenticazione RSA, se è stata specificata l'opzione "command", sarà permesso qualunque sia il valore di questa impostazione (cosa che può essere utile per effettuare backup in remoto anche se il login come root non è normalmente ammesso).

o      Un file di configurazione vuoto può essere messo nella directory home di ogni utente, posseduto da root e scrivibile solo da root. Questo forzerà l'uso delle impostazioni di sistema da parte di tutti gli utenti.

o      Usate almeno la versione1.2.26 per assicurare la compatibilità con SSH2.

o      Login senza password:

§         Evitatelo se è possibile, ma se fosse necessario, impostatelo attentamente. Usate .shosts piuttosto di .rhosts. Assicuratevi che i file di configurazione abbiano i permessi a 400. Non metteteli in directory home condivise via NFS.

§         Per impostare il trust /.shosts come root dall'host A all'host B: Aggiungete l'hostA a /.shosts e /etc/hosts dell'hostB, aggiungete la chiave pubblica dell'hostA a /etc/ssh_known_hosts o ~/.ssh/known_hosts.

§         Per impostare il trust RSA dall'host A all'host B: il file.ssh/Identity.pub (chiave pubblica) dell'host A deve essere aggiunto alla lista delle chiavi in .ssh/authorized_keys sulla macchina di destinazione. 

·        Configurazione del client: configurate le opzioni globali per il client SSH. Esempi commentati:  /etc/ssh_config

·        SSH e SUID root:

SSH installa due programmi che hanno bisogno di particolari privilegi. Ssh è il programma client, e di default e installato come suid root, poiché necessita di creare una porta privilegiata per poter usare i file .rhosts files per l'autenticazione. Se non è suid root, sarà comunque utilizzabile, ma non si potrà usare l'autenticazione .rhosts. Inoltre, la chiave provata è leggibile solo da root. Sshd è il demone che riceve le connessioni. Dovrebbe preferibilmente girare come root, perché di norma si pone in ascolto su una porta privilegiata (22), e dovrebbe essere in grado di usare setuid(), aggiornare utmp,usare chown su pty ecc. quando un nuovo utente si connette. Se non gira come root, si deve specificare l'opzione "-p port" per indicare un'altra porta (la stessa andrà specificata al client), "- h host_key_file_path" va usata per indicare il file di chiave, e nessun utente si può connettere ad esso mentre lo sta usando un altro (poiché non può chiamare setuid()). Inoltre, se il vostro sistema usa le shadow password, l’autenticazione delle password authentication non funzionerà mentre gira da chiunque non sia root. Sia il server che il client sono stati accuratamente schermati da possibili problemi di sicurezza, e sono ritenuti sicuri. Comunque non ci può essere alcuna garanzia.

 

Ancora di più con SSH

 

·        SSH1:

o       può effettuare facilmente il forwarding dei pacchetti su singole porte (POP3, SMTP, ecc..), sia con client PC o UNIX; esempio:

ssh  L 25:mailhost.target.domain:25 target 

mentre non può instradare porte dinamiche o serie di porte. Mindterm SSH include un opzione per il tunneling FTP.

o       Se PPP è ridirezionato su un socket SSH, SSH può essere usato come una VPN a scopo generale. Un esempio pratico che usa Linux come gateway su entrambi i lati è descritto dal libro di O'Reilly "Virtual Private networks, 2nd Edition", capitolo7  e ulteriori informazioni si possono trovare a sunsite.unc.edu/LDP/HOWTO/mini/VPN.html. Vi servirà Linux su entrambi i lati ed è un'operazione un po' "sporca” (datata 1997).

o       Provate inoltre sites.inka.de/sites/bigred/sw/ssh-ppp-new.txt (datato 1996).

·        Rdist 6.1.2 (versione di pubblico dominio) gira sopra SSH (testata su Solaris 2 & SunOS) e può essere usato per sincronizzare file tra due host, o per verificare le differenze tra file.

·        Fsh è un add-on per tenere aperto un tunnel SSH per permettere di eseguire più comandi in remoto senza riaprire il tunnel ogni volta. www.lysator.liu.se/fsh. Non l'ho ancora provato.

·        Per usare SSH con RPC/keyserv/NFS/NIS+: si veda fy.chalmers.se/~appro/ssh_beyond.html

·        Jean Chouanard ha prodotto patch SecurID/ACE per SSH1 che aggiungono il supporto per "New Pin" e "Next Token", ma che funzionano solo se sia il client che il server SSH sono modificati di conseguenza. Non sembra che queste patch verranno integrate in OpenSSH o Mindterm SSH al momento. Si veda ftp.parc.xerox.com:/pub/jean/sshsdi/README

·        Virtual Network Computing è un programma di "controllo remoto" che vi permette di vedere e usare il desktop di un'altra macchina (NT, Win95, UNIX) in rete. Può anche essere usato per il telelavoro su reti non sicure come internet. Oppure, SSH può essere usato per crittografare le comunicazioni VNC e incrementare così la sicurezza. 

o       Installate un NT VNC server sulla intranet, una che faccia parte del consueto dominio NT e abbia account per coloro che debbano accedervi. [Potrebbe anche essere UNIX, o NT ]. Rendete sicura questa macchina scegliendo una buona password VNC, abilitando l'accesso esclusivo VNC, attivando un salvaschermo con una password dopo cinque minuti di inattività e non rendendola accessibile al pubblico. Monitorate regolarmente i log di sistema.

o       Installate un server SSH UNIX per la intranet.

o       Installate un gateway SSH, che permette connessioni SSH da internet. I login corretti avvengono direttamente sul server SSH.
Sicurezza: Mettere questa macchina nella DMZ in mezzo a due firewall sicuri. Meglio ancora, disabilitate tutti i servizi tranne SSH. Non permettere nessun protocollo da internet, tranne SSH. Confgurate SSH per rifiutare i login di root e disabilitate i meccanismio di trust e l'autenticazione RSA. Configurate gli account degli utenti per usare sistemi di autenticazioni sicuri come SecurID. Configurate la shell in modo che gli utenti si connettano automaticamente al server UNIX della intranet (e non permettere login locali su questo). E' necessario essere paranoici, monitorate i log  attentamente e fare controlli di integrità (come tripwire) di frequente.

o       Installate un client SSH come Mindterm sul client VNC (da qualche parte su internet).

§         Configurazione del client SSH: connettetesi al gateway SSH e autenticarsi con SecurID (o ciò che che si usa). Loggarsi sul server UNIX della intranet e configurate il tunnel sulla porta locale 5902 verso il “NT_VNC_server” sulla porta 5900.

§         Client VNC: lanciare il client VNC locale, connettersi a localhost 2, inserite la password VNC e “voilà”, dovrebbe apparire il desktop. Ora bisognerà loggarsi su NT come al solito.

§         Sicurezza: si suggerisce di usare la propria macchina (non una in un Internet Cafè), con un antivirus aggiornato, condivisione dei file disabilitata, e un firewall personale come BlackICE installato (e impostate il livello di protezione a "paranoico", senza condivisione dei file). Questa macchina dovrebbe essere fisicamente protetta e possibilmente avere un disco crittografato (esempio: PGPdisk).

 

1.4 Open SSH

OpenSSH è una suite di protocolli gratuita che fornisce cifratura per servizi di rete, come il login remoto o il trasferimento di file remoto. Ecco alcune caratteristiche:

 

·        Progetto Open Source Licenza Gratuita

·        Crittografia forte (3DES, Blowfish)

·        X11 Forwarding (cifratura automatica del traffico X11)

·        Port Forwarding (canali criptati per altri protocolli)

·        Autenticazione Forte (Rhosts, Chiave Pubblica, Password)

·        Interoperabilità (Conformità con SSH 1.3, 1.5, e gli Standard del protocollo 2.0)

·        Supporto per client e server SFTP nei protocolli SSH1 e SSH2.

·        Kerberos e AFS Ticket Passing

·        Compressione Dati

 

 

Progetto Open Source

Il codice di OpenSSH è disponibile gratuitamente per chiunque via Internet. Questo incoraggia il riutilizzo e la verifica del codice. Il riesame del codice assicura eventuali bug possano essere trovati e corretti da chiunque.

 

Licenza Gratuita

OpenSSH non è coperto da nessuna licenza restrittiva. Può essere usato per qualsiasi scopo, incluso quello commerciale. Tutte le componenti soggette a brevetto, sono state rimosse dal codice sorgente. Tutte le componenti soggette a restrizioni sulla licenza o brevetto, sono state scelte da librerie esterne (ad esempio OpenSSL).

 

Crittografia forte (3DES, Blowfish)

OpenSSH usa 3DES e Blowfish come algoritmi di cifratura. Nessuno di essi è soggetto a brevetto. 3DES è un cifrario ben conosciuto e "a prova di tempo" che fornisce crittografia forte. Blowfish è un cifrario a blocchi veloce, inventato da Bruce Schneier, che risponde bene all'esigenza di cifratura veloce. La cifratura inizia prima dell'autenticazione e non sono trasmesse password o altre informazioni in chiaro.

 

X11 Forwarding

L'X11 forwarding consente la cifratura del traffico remoto di X11, cosicché nessuno possa curiosare in xterm remoti di altri o inserire comandi maliziosi. Il programma setta automaticamente la variabile di ambiente DISPLAY sulla macchina server e inoltra ogni connessione X11 su di un canale sicuro.

 

Port Forwarding

Il port forwarding consente l'inoltro di connessioni TCP/IP ad una macchina remota verso un canale cifrato. Servizi standard di Internet, come i server POP, possono essere resi sicuri con esso.

 

Autenticazione Forte

L'autenticazione forte protegge contro alcuni problemi di sicurezza, come IP spoofing, rotte false e DNS spoofing. I metodi di autenticazione sono: rhosts con autenticazione host basata su RSA, autenticazione RSA pura e autenticazione con password.

 

Interoperabilità

Le versioni di OpenSSH anteriori alla 2.0 supportano i protocolli SSH 1.3 e SSH 1.5, permettendo la comunicazione con molte versioni di UNIX, Windows ed altre implementazioni commerciali di SSH. OpenSSH supporta anche il protocollo SSH 2.0. Questo protocollo consente di scegliere tra RSA e DSA come algoritmi di firma.

 

Supporto per client e server SFTP nei protocolli SSH1 e SSH2.

OpenSSH include un supporto completo per SFTP, usando il comando sftp(1) come client. Il deamon sftp-server(8) funziona automaticamente sia in SSH1 che in SSH2.

 

Kerberos and AFS Ticket Passing

OpenSSH comunica direttamente con Kerberos e AFS sulla macchina remota. Un utente può così accedere a tutti i suoi servizi Kerberos e AFS senza che debba ridigitare la password.

 

Compressione Dati

La compressione dati prima della cifratura migliora le prestazioni su link lenti.