Attachment 70119 Details for Bug 108433 – openssh-key-management-p1.xml

openssh-key-management-p1.xml

openssh-key-management-p1.xml (text/plain), 20.81 KB, created by Michele Schiavo on 2005-10-07 15:03:29 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Michele Schiavo

Created: 2005-10-07 15:03:29 UTC

Size: 20.81 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/it/articles/openssh-key-management-p1.xml">
><title>OpenSSH gestione delle chiavi, Parte 1</title>
><author title="Autore">
>  <mail link="drobbins@gentoo.org">Daniel Robbins</mail>
></author>
><author title="Traduzione">
>  <mail link="micheleschi@libero.it">Michele Schiavo</mail>
></author>
>
>
><abstract>
>In questo capitolo conoscerai come funzionano le autentificazioni RSA e DSA, 
>e vedrai come impostare nel modo corretto autentificazioni senza password. 
>Questo primo articolo della serie, di Daniel Robbins, Ã¨ focalizzato 
>sull' introduzione del protocollo di autentificazione RSA e DSA ed 
>inoltre mostra come sia possibile farli lavorare sulla rete.
></abstract>
>
>
>
><version>1.0</version>
><date>2005-09-29</date>
>
><chapter>
><title>Capire l'autentificazione RSA/DSA</title>
><section>
><body>
>
><p>
>Molti di noi stanno gia utilizzando l'ottimo OpenSSH (vedi <uri link="#resources">
>Resources</uri> piÃ¹ avanti in questo capitolo) come alternativa sicura, e 
>criptata per i comandi vulnerabili di <c>telnet</c> e <c>rsh</c>.
>Una delle piÃ¹ intriganti caratteristiche Ã¨ la possibilitÃ  di autenticare gli 
>utenti usando i protocolli RSA e DSA, i quali sono basati su una coppia 
>complementare di chiavi completamente numeriche. Tra le sue migliori 
>caratteristiche, RSA and DSA hanno la capacitÃ  di stabilire connessioni a sistemi 
>remoti <e>senza digitare la password</e>. Per questa caratteristica, i nuovi 
>utenti di OpenSSH configurano spesso RSA/DSA in modo rapido e grossolano con 
>conseguenti login privi di password, ma aprendo grandi e gravi falle di 
>sicurezza nel processo.
></p>
>
></body>
></section>
><section>
><title>Cos'Ã¨ l'autentificazione RSA/DSA ?</title>
><body>
>
><p>
>SSH, per l'esattezza OpenSSH (un' implementazione free di SSH), Ã¨ uno 
>strumento incredibile. Come <c>telnet</c> o <c>rsh</c>, il client ssh puÃ² 
>essere utilizzato per loggarsi ad una macchina remota.Tutto quello che Ã¨ 
>richiesto sulla macchina remota Ã¨ che sia in esecuzione <c>sshd</c>, il 
>servizio del precesso <c>ssh</c>. A differenza di <c>telnet</c>, il protocollo 
>ssh Ã¨ veramente sicuro.Esso utilizza uno speciale algoritmo di criptatura del 
>flusso di dati, aumentando e garantendo l'integritÃ  di essi, realizzando
>autentificazioni in modo sicuro.
></p>
>
><p>
>Tuttavia anche se <c>ssh</c> Ã¨ realmente grande, c'Ã¨ un certo componente 
>della sue funzionalitÃ  che Ã¨ spesso ignorato o pericolosamente abusato o 
>semplicemente mal compreso. Questo componente di OpenSSH Ã¨ il sistema di 
>autentificazione a chiave RSA/DSA, un'alternativa al sistema standard di 
>autentificazione che OpenSSH utilizza di default.
></p>
>
><p>
>I protocolli di autentificazione RSA e DSA di OpenSSH sono basati su di una 
>copia speciale generata di chiavi cifrate, chiamate <e>private key</e>
>(chiave privata) e <e>public key</e>(chiave pubblica). Il vantaggio di 
>utilizzare questo sistema di autentificazione basato sul chiavi Ã¨ che in molti 
>casi Ã¨ possibile stabilire connessioni sicure senza aver digitato manualmente 
>la password.
></p>
>
><p>
>Mentre i protocolli basati su chiavi di autenticazione sono relativamente 
>sicuri, i problemi si presentano quando gli utenti prendono determinate 
>scorciatoie in nome di convenienza, senza aver completamente capito le loro 
>implicazioni sulla sicurezza.In questo articolo, daremo una buona occhiata a 
>come usare correttamente i protocolli di autenticazione DSA ed RSA senza 
>esporsi a rischi inutili di sicurezza.
>Nel mio seguente articolo vi mostrerÃ² come usare <c>ssh-agent</c> per 
>nascondere le chiavi private ed introdurre <c>keychain</c>, un <c>ssh-agent
></c> front-end che offre un certo numero di vantaggi della convenienza senza 
>sacrificare la sicurezza. Se tu sei interessato ad appendere piÃ¹ in dettaglio 
>le caratteristiche di OpenSSH, continua a leggere.
></p>
>
></body>
></section>
><section>
><title>Come lavorano le chiavi RSA/DSA</title>
><body>
>
><p>
>Ora una breve e generale spiegazione di come lavorano le chiavi RSA/DSA.
>Partiamo con un ipotetico scenario dove vogliamo usare l'autentificazione RSA 
>per permettere ad una workstation locale con sistema linux (di nome
><e>localbox</e>) di aprire una shell su <e>remotebox</e>, una macchina del 
>tuo ISP. Bene adesso, noi proveremo a connetterci a <e>remotebox</e> 
>utilizzando <c>ssh</c> client, noi otterremmo il seguente prompt:
></p>
>
><pre caption="Connessione a remotebox">
>$ <i>ssh drobbins@remotebox</i>
>drobbins@remotebox's password:
></pre>
>
><p>
>Qui si vede un esempio di autentificazione di <e>default</e> di <c>ssh</c>. 
>Normalmete questo chiede la password di <e>drobbins</e> account su <e>remotebox
></e>. Se noi digitiamo la nostra password per <e>remotebox</e>,<c>ssh</c> 
>utilizza il suo protocollo sicuro di autentificazione della password, 
>trasmettendola  al <e>remotebox</e> per la verifica.
>Tuttavia diversamente da come fa <c>telnet</c>, qui la nostra password Ã¨ 
>cifrata cosÃ¬ da non essere intercettata da nessuno che stia catturando i dati 
>della nostra connessione. Appena <e>remotebox</e> autentica la password che 
>abbiamo fornito con il suo database, se ha successo, noi siamo abilitati al 
>logon dopo il greeting, <e>remotebox</e> ci offre il prompt della shell.
>. FinchÃ¨ il metodo di autentificazione di default di <c>ssh</c> sembra 
>essere abbastanza sicuro, l'autentificazione di RSA e DSA apre nuove 
>possibilitÃ .
></p>
>
><p>
>Tuttavia, diversamente dall' autentificazione sicura della password <c>ssh</c>, 
>, l'autentificazione RSA richiede qualche configurazione iniziale. Noi abbiamo 
>bisogno di eseguire questi passi iniziali una sola volta. Dopo di che l' 
>autentificazione RSA tra <e>localbox</e> e <e>remotebox</e> sarÃ  totalmente 
>senza paura. Per impostare l'autentificazione RSA, noi dobbiano dapprima 
>generare una coppia di chiavi, una privata ed una pubblica. Queste due chiavi 
>hanno delle proprietÃ  molto importanti. La chiave pubblica puÃ² essere 
>utilizzata  per crifrare un messaggio e solo il proprietario della rispettiva 
>chiave privata puÃ² decifrarlo. La chiave pubblica puÃ² solo essere usata per 
><e>encryption</e>, e la chiave privata puÃ² solo essere utilizzata per 
><e>decryption</e> di un messaggio codificato dalla corrispondente chive pubblica. 
>Il Protocollo di autentificazione RSA (e DSA) utilizza questa speciale 
>peculiaritÃ  della coppia di chiavi per realizzare l'autentificazione sicura 
>senza dover trasmettere nessuna informazione riservata sulla rete.
></p>
>
><p>
>Per far si che l'autentificazione RSA o DSA lavori, noi dobbiamo fare il 
>primo passo. Copiamo la nostra <e>public key</e> su <e>remotebox</e>.
>La chiave pubblica Ã¨ chiamata "pubblica" per una ragione. Visto che essa 
>Ã¨ utilizzata solo per <e>cifrare</e> i nostri messaggi, noi non dobbiamo 
>preoccuparci che vada in mani sbagliate. Cosi una volta che abbiamo 
>copiato la nostra chiave pubblica su <e>remotebox</e> e la abbiamo messa 
>nel file speciale (<path>~/.ssh/authorized_keys</path>) cosÃ¬ che il servizio
><c>sshd</c> su <e>remotebox</e> la possa trovare, noi siamo pronti a loggarci 
>su <e>remotebox</e>.
></p>
>
><p>
>Per far ciÃ², scriviamo sempicemente <c>ssh drobbins@remotebox</c> dalla 
>nostra console su <e>localbox</e>. PerÃ² questa volta, <c>ssh</c> lascia al 
>servizio <c>sshd</c> su <e>remotebox</e> decidere se preferisce utilizzare 
>l'autentificazione del protocollo RSA. Cosa succede adesso Ã¨ molto 
>interessante. Il servizio <c>sshd</c> di <e>Remotebox</e> genera un numero 
>casuale, e lo cifra utilizzando la nostra chiave pubblica.(Quella che noi 
>abbiamo copiato prima). Cosi <c>sshd</c> spedisce questo numero casuare 
>cifrato al nostro <c>ssh</c> funzionante su <e>localbox</e>. Dopodiche il 
>nostro <c>ssh</c> utilizza la nostra <e>private key</e> per decifrare questo 
>numero, e lo spedisce di ritorno a <e>remotebox</e>, come se dicesse "Vedi,io 
><e>ho</e> la corrispondente chiave privata;Sono stato in grado di decifrare il 
>tuo messggio!" Cosi, <c>sshd</c> conclude che noi possiamo fare il log in, in 
>quando possediamo la corrisponente chiave privata. Di fatto noi dobbiamo 
>possedere la chiave privata per avere l'accesso a <e>remotebox</e>.
></p>
>
></body>
></section>
><section>
><title>Due osservazioni</title>
><body>
>
><p>
>Ci sono due importanti osservazioni riguardo l'autentificazione RSA e DSA.
>La prima Ã¨ che noi dobbiamo per forza generare la coppia di chiavi. Noi 
>possiamo poi copiare la chiave pubblica nelle macchine remote per averne 
>accesso tramite la nostra sola chiave privata. In altre parole, non abbiamo 
>bisogno di una copia di chiavi per <e>ogni</e> sistema al quale vogliamo 
>avere accesso, me Ã¨ sufficiente una sola una copia.
></p>
>
><p>
>L'altra osservazione Ã¨ che la nostra <e>chiave privata non deve assolutamente 
>finire nelle mani sbagliate</e>. 
>La chiave privata Ã¨ l'unica cosa che ci garantisce l'accesso ai sistemi remoti, 
>ed ognuno che la possiede ha accesso esattamente come noi. CosÃ¬ come non ci 
>farebbe piacere che qualcunaltro avesse le nostre chiavi di casa, nello stesso 
>modo dobbiamo proteggere la nostra chiave privata da ogni utilizzo 
>inappropriato. Nel mondo dei bits and bytes, questo significa che nessuno deve 
>essere in grado di leggere o copiare la nostra chiave privata.
></p>
>
><p>
>Sicuramente gli sviluppatori di <c>ssh</c> conoscono l'importanza della chiave 
>privata ed hanno creato alcune sicurezze all'interno di <c>ssh</c> e 
><c>ssh-keygen</c> cosÃ¬ che la nostra chiave privata non venga abusata. Primo, 
><c>ssh</c> Ã¨ configurato per visualizzare un avviso nel caso in cui la nosta 
>chiave privata abbia dei permessi che concedono a qualcuno di leggerla. 
>Secondo, quando creiamo la nostra copia di chiavi pubblica/privata utilizzando 
><c>ssh-keygen</c>, <c>ssh-keygen</c> ci chiederÃ  di inserire una 
>parola-segreta (passphrase). Se noi la inseriamo, la nostra chiave privata 
>viene cifrata utilizzando quest'ultima, cosÃ¬ se qualcuno ci ruba la chiave 
>privata essa sarÃ  inutilizzabile a chiunque non conosca anche la nostra parola 
>segreta. Armati di queste conoscenze andiamo a vedere come configurare 
><c>ssh</c> per utilizzare il protocollo di autentificazione RSA e DSA.
></p>
>
></body>
></section>
><section>
><title>ssh-keygen up close</title>
><body>
>
><p>
>Il primo passo per impostare l'autentificazione RSA Ã¨ quello di generare la 
>copia pubblica/privata di chiavi. In origine l'autentificazione RSA fu 
>implementata in <c>ssh</c>, cosÃ¬ RSA puÃ² funzionare con qualsiasi versione di 
>OpenSSH, anche se raccomando sempre che nel sistema sia installata l' ultima  
>versione disponibile, (mentro sto scrivendo questo articolo, openssh-2.9_p2). 
>Ora generiamo una copia di chiavi come segue:
></p>
>
><pre caption="Utilizzando ssh-keygen">
>$ <i>ssh-keygen</i>
>Generating public/private rsa1 key pair.
>Enter file in which to save the key (/home/drobbins/.ssh/identity): <comment>(premi invio)</comment>
>Enter passphrase (empty for no passphrase): <comment>(inserisci la parola chiave)</comment>
>Enter same passphrase again: <comment>(inserisci nuovamente la parola chiave)</comment>
>Your identification has been saved in /home/drobbins/.ssh/identity.
>Your public key has been saved in /home/drobbins/.ssh/identity.pub.
>The key fingerprint is:
>a4:e7:f2:39:a7:eb:fd:f8:39:f1:f1:7b:fe:48:a1:09 drobbins@localbox
></pre>
>
><p>
>Quando <c>ssh-keygen</c> chiede dove salvare la chiave, premiamo invio per 
>accettare la posizione predefinita di <path>/home/drobbins/.ssh/identity</path>.
> <c>ssh-keygen</c> memorizzera la chiave privata nel percorso sopra definito e 
>la chiave <e>pubblica</e> sarÃ  anchessa nella stessa posizione, in un file 
>chiamato identity.pub.
></p>
>
><p>
>Da tenere presente anche che <c>ssh-keygen</c> domanda di inserire la parola 
>chiave. Quando richiesto noi inseriamo una buona parola chiave (sette o 
>piÃ¹ caratteri difficili da prevedere). <c>ssh-keygen</c> allora cifra la nostra 
>chiave privata (<path>~/.ssh/identity</path>) utilizzando questa parola chiave, 
>in modo tale che nessuno possa utilizzarla senza conoscere la nostra parola 
>chiave.
></p>
>
></body>
></section>
><section>
><title>Il piccolo compromesso</title>
><body>
>
><p>
>Quando specifichiamo la parola chiave, abilitiamo <c>ssh-keygen</c> a prevenire 
>degli abusi, ma questo crea un piccolo inconveniente. Ora, ogni volta che 
>vogliamo connetterci al nostro account <e>drobbins@remotebox</e> utilizzando 
><c>ssh</c>, <c>ssh</c> chiderÃ  di inserire la parola chiave, in modo tale da 
>porter decifrare la nostra chiave privata da utilizzare per l'autentificazione 
>RSA. Ma attenzione noi non dobbiamo digitare la nostra password per l'account 
>di <e>drobbins</e> su <e>remotebox</e>, ma la parola chiave necessaria per 
>decifrare localmente la chiave privata. Dopo che la chiave privata Ã¨ stata 
>decifrata, il nostro client <c>ssh</c> si prenderÃ  cura del resto. Questo 
>meccanismo di autentificazione Ã¨ completamente differente, dato che  noi 
>stiamo digirando la "frase segreta" di <c>ssh</c>.
></p>
>
><pre caption="Loggarsi con l'utilizzo della parola chiave">
>$ <i>ssh drobbins@remotebox</i>
>Enter passphrase for key '/home/drobbins/.ssh/identity': <comment>(inserire la parola chiave)</comment>
>Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org 
>
>Welcome to remotebox!
>
>$
></pre>
>
><p>
>Tuttavia finchÃ¨ non si Ã¨ capito bene l'impatto sulla sicurezza Ã¨ meglio 
>utilizzare questo piccolo inconveniente. Con una chiave privata non cifrata, 
>se qualcuno attaccasse il nostro sistema, egli avrebbe pieno accesso a 
><e>remotebox</e> ed a tutti gli altri host che sono configurati con la 
>rispettiva chiave pubblica.
></p>
>
><p>
>So quello che stai pensando. Autentificazioni senza password sono belle ma 
>hanno pur sempre qualche richio. Ma <e>c'Ã¨ un modo migliore!</e> 
>Stai con me e capirai come trarre vantaggi da un autentificazione priva di 
>password senza compromettere la sicurezza della tua chiave privata.
>Ti mostrerÃ² come trarre i massimi benefici utilizzando <c>ssh-agent</c> 
>(l'oggetto che permette autentificazioni <e>sicure</e> senza password pensando 
>in primo luogo alla sicurezza) nel prossimo articolo. Per adesso vediamo come 
>utilizzare <c>ssh-agent</c> per impostare autentificazioni RSA e DSA. 
>Passo dopo passo.
></p>
>
></body>
></section>
><section>
><title>Generazione della copia di chiavi RSA</title>
><body>
>
><p>
>Per impostare l'autentificazione RSA dobbiamo fare alcuni piccoli passi per 
>generare la copia di chiavi pubblica/privata. Per fare questo scriviamo :
></p>
>
><pre caption="Generazione delle chiavi...">
>$ <i>ssh-keygen</i>
></pre>
>
><p>
>Accettare la locazione di default per le chiavi quando richiesto  (di norma
><path>~/.ssh/identity</path> e <path>~/.ssh/identity.pub</path> per la chiave 
>pubblica), e fornire ad <c>ssh-keygen</c> una sicura parola chiave. Qunado 
><c>ssh-keygen</c> ha finito, otterrai una chiave pubblica ed una chiave privata 
>cifrata.
></p>
>
></body>
></section>
><section>
><title>Installazione della chiave pubblica RSA</title>
><body>
>
><p>
>Il prossimo passo consiste nel configurare il sistema remoto dove sia in 
>esecuzione il servizio <c>sshd</c> ad utilizzare la nostra chiave 
><e>pubblica</e> per l'autentificazione RSA. Normalmente lo si fa copiando 
>la chiave pubblica nel sistema remoto nel modo seguente :
></p>
>
><pre caption="Copiare la chiave pubblica ">
>$ <i>scp ~/.ssh/identity.pub drobbins@remotebox:</i>
></pre>
>
><p>
>Dato che ancora la configuarazione dell'autentificazione RSA non Ã¨ completata 
>dobbiamo inserire la nostra password su <e>remotebox</e>. Fatto questo , 
>aggiungiamo la chiave pubblica al seguente file <path>~/.ssh/authorized_keys
></path> cosÃ¬:
></p>
>
><pre caption="Installazione delle chiave pubblica">
>$ <i>ssh drobbins@remotebox</i>
>drobbins@remotebox's password: <comment>(digia la password)</comment>
>Last login: Thu Jun 28 20:28:47 2001 from localbox.gentoo.org 
>
>Welcome to remotebox!
>
>$ <i>cat identity.pub >> ~/.ssh/authorized_keys</i>
>$ <i>exit</i>
></pre>
>
><p>
>Adesso con l'autentificazione RSA configurata saremo invitati a digitare la 
>nostra <e>parla chiave</e> (anzichÃ¨ la nostra <e>password</e>) quando 
>proveremo a connetterci a <e>remotebox</e> utilizzando <c>ssh</c>.
></p>
>
><pre caption="Loggarsi tramite l'autentificazione a chiave pubblica">
>$ <i>ssh drobbins@remotebox</i>
>Enter passphrase for key '/home/drobbins/.ssh/identity': 
></pre>
>
><p>
>Evvai!, l'autentificazione RSA Ã¨ completata! Se non sei riuscito ad ottenere 
>il prompt della parola chiave ci sono alcune cosa da verificare. Prima cosa 
>proviano ad effettuare il login scrivendo <c>ssh -1 drobbins@remotebox</c>. 
>Questo dirÃ  ad ssh di utilizzare la versione 1 del protocollo, che potrebbe 
>essere per qualche ragione l'autentificazione dei default nel sistema remoto. 
>Se anche cosÃ¬ non dovesse funzionare prova a verificare che tu non abbia una 
>linea simile a questa <c>RSAAuthentication no</c> nel tuo 
><path>/etc/ssh/ssh_config</path>. Se cosÃ¬ fosse, prova a commentarla 
>aggiungendo questo "#" all'inizio. Altrimenti prova a contattare l'
>ammisitratore di sistema di <e>remotebox</e> e verificare che abbia abilitato 
>l'autentificazione RSA nel suo sistema, ed eventualmente a verificare i 
>parametri di <path>/etc/ssh/sshd_config</path>.
></p>
>
></body>
></section>
><section>
><title>Generazione della chiave DSA</title>
><body>
>
><p>
>Mentre le chiavi di RSA utilizzano la versione 1 del protocollo dello 
><c>ssh</c>, le chiavi DSA sono utilizzatr  per il Livello 2, una versione 
>aggiornata del protocollo dello <c>ssh</c>.  Tutta una qualunque versione 
>recente di OpenSSH dovrebbe essere in grado di utilizzare sia le chiavi DSA 
>che RSA. Generalmente le chiavi DSA utilizzate <c>ssh-keygen</c> di OpenSSH 
>sono simili alle chiavi RSA nel seguente modo :
></p>
>
><pre caption="Generazione di una copia di chiavi DSA">
>$ <i>ssh-keygen -t dsa</i>
></pre>
>
><p>
>Nuovamente ci viene richiesto di inserire la parola chiave. Digitarne una 
>corretta dal punto di vista della sicurezza. Ci verrÃ  anche richiesto il 
>percorso per salvare le nostre chiavi DSA. Normalmente 
><path>~/.ssh/id_dsa</path> e <path>~/.ssh/id_dsa.pub</path>, dovrebbero andare 
>bene. Dopodiche la nostra genereazione DSA Ã¨ completata, Ã¨ ora di installare 
>la nostra chiave pubblica sul sistema remoto.
></p>
>
></body>
></section>
><section>
><title>Installazione di chiave pubbliva DSA</title>
><body>
>
><p>
>Nuovamente l'installazione della chiave pubblica DSA Ã¨ identica a quella 
>RSA. Nel caso della DSA, dobbiamo copiare il nostro file  
><path>~/.ssh/id_dsa.pub</path> su <e>remotebox</e>, ed appenderlo al file 
><path>~/.ssh/authorized_keys2</path> sempre su <e>remotebox</e>. 
>Da noteare che questo file ha un nome diverso da quello RSA 
><path>authorized_keys</path> . Una volta configurato siamo in grado di fare un 
>login su  <e>remotebox</e> scrivendo la nostra parola chiave per la chiave 
>privata di DSA anzichÃ¨ la nostra normale password di <e>remotebox</e>.
></p>
>
><note>
>Al giorno d'oggi si dovrebbe utilizzare soltanto la versione 2 del protocollo 
>ssh, poichÃ¨ la versione 1 presenta alcune debolezze.
></note>
>
></body>
></section>
><section>
><title>La prossima volta</title>
><body>
>
><p>
>Bene, adesso dovresti avere le autentificazioni RSA e DSA funzionanti ma con 
>la necessitÃ  di dover digitare la parola chiave per ogni nuova connessione. 
>Nel prosssimo articolo, noi vedremo come utilizzare <c>ssh-agent</c>, un 
>comodo metodo per abilitarci a stabile connessioni <e>senza</e> fornire la 
>parla chiave, ma comunque ad avere la chiave privata cifrata sul nostro disco. 
>Introdurro innoltre <c>keychain</c>, un front-end molto comodo di 
><c>ssh-agent</c> che lo rende ancora piÃ¹ sicuro, comodo e facile da usare. 
>Fino ad allora tieni a portata di mano le risorse qua sotto.
></p>
>
></body>
></section>
></chapter>
><chapter id="resources">
><title>Risorse</title>
><section>
><body>
>
><ul>
>  <li>
>    Gli altri due articoli di Read Daniel della serie, <uri
>    link="/doc/en/articles/openssh-key-management-p2.xml">OpenSSH key 
>    management, Parte 2</uri> and <uri 
>    link="/doc/en/articles/openssh-key-management-p3.xml">OpenSSH key 
>    management, Parte 3</uri>
>  </li>
>  <li>
>    Sii sicuro di vistare l'homepage degli svilupparoti di <uri
>    link="http://www.openssh.com">OpenSSH</uri> .
>  </li>
>  <li>
>    Controla le FAQ di <uri link="http://www.openssh.com/faq.html">OpenSSH
>    FAQ</uri>.
>  </li>
>  <li>
>    <uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY</uri>
>    un ottimo client <c>ssh</c> per macchine Windows.
>  </li>
>  <li>
>    Puoi innoltre trovare Reilly's <e>SSH, The Secure Shell: The Definitive Guide</e>
>    per essere soddisfatto. Il sito <uri link="http://www.snailbook.com/">dell autore
>    </uri> contiene informazioni sul libro, FAQ, news, ed aggiornamenti.
>  </li>
></ul>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 108433: 70119