* [gentoo-docs-it] Tradotta keychain-guide.xml
@ 2006-03-11 13:36 Cristiano Chiucchiolo
2006-03-11 20:23 ` Stefano Rossi
0 siblings, 1 reply; 2+ messages in thread
From: Cristiano Chiucchiolo @ 2006-03-11 13:36 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: keychain-guide.xml --]
[-- Type: text/xml; name="keychain-guide.xml", Size: 11891 bytes --]
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/it/keychain-guide.xml" lang="it">
<title>Gentoo Linux Keychain Guide</title>
<author title="Autore">
<mail link="airuike@gmail.com">Eric Brown</mail>
</author>
<author title="Editor">
<mail link="vanquirius@gentoo.org">Marcelo Góes</mail>
</author>
<author title="Traduzione">
<mail link="cristiano.chiucchiolo@gmail.com">Cristiano Chiucchiolo</mail>
</author>
<abstract>
Questo documento descrive come usare chiavi condivise ssh con il programma
keychain. Si presuppone la conoscenza di base della crittografia con chiave
pubblica.
</abstract>
<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.2</version>
<date>2006-02-05</date>
<chapter>
<title>Introduzione</title>
<section>
<title>Il problema</title>
<body>
<p>
Allora, tutte le vostre amate macchine Gentoo eseguono sshd, ma è un po'
seccante per voi digitare ogni volta tutte quelle password per il login,
giusto? Oppure forse avete uno script o un cron-job che ha bisogno di un modo
conveniente per usare una connessione ssh. In entrambi i casi, c'è una
soluzione a questo problema, ed essa si basa sull'autenticazione con chiave
pubblica.
</p>
</body>
</section>
<section>
<title>Come funziona l'autenticazione con chiave pubblica?</title>
<body>
<p>
Supponiamo di avere un client che vuole connettersi a sshd su un server. Il
client per prima cosa genera un paio di chiavi, e dà la chiave pubblica al
server. Fatto ciò, ogni qualvolta il client cerca di connettersi, il server
invia una sfida crittografata con quella chiave pubblica. Solo il possessore
della corrispondente chiave privata (il client) è il grado di decriptarla,
cosicché, come forse avrete già indovinato, la risposta corretta consente
l'autenticazione.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Come usare l'autenticazione con chiave pubblica</title>
<section>
<title>Generare il vostro paio di chiavi</title>
<body>
<p>
Il primo passo consiste nel creare il vostro paio di chiavi. Per fare ciò,
useremo il comando <c>ssh-keygen</c> come segue:
</p>
<pre caption="Generare un paio di chiavi">
$ <i>ssh-keygen -t dsa</i>
<comment>(Accettate semplicemente i valori di default, ed accertatevi di
inserire una passphrase sicura)</comment>
</pre>
<warn>
Assicuratevi di scegliere una passphrase sicura, specialmente se questa chiave
è utilizzata per i login di root!
</warn>
<p>
Ora dovreste avere una chiave privata in <path>~/.ssh/id_dsa</path> e una
chiave pubblica in <path>~/.ssh/id_dsa.pub</path>. Siamo pronti a copiare la
chiave pubblica sull'host remoto.
</p>
</body>
</section>
<section>
<title>Preparare il server</title>
<body>
<p>
Copieremo il file <path>~/.ssh/id_dsa.pub</path> sul server dove gira sshd.
Lo aggiungeremo anche al file <path>~/.ssh/authorized_keys</path> che
appartiene all'utente che si connette a quel server. Ecco un esempio di
come fare ciò se avete già l'accesso ssh al server.
</p>
<pre caption="Copiare la chiave pubblica sul server">
$ <i>scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub</i>
$ <i>ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"</i>
$ <i>ssh server_user@server "cat ~/.ssh/authorized_keys"</i>
</pre>
<p>
L'output dell'ultima riga dovrebbe mostrare il contenuto del file
<path>~/.ssh/authorized_keys</path>. Assicuratevi che appaia
correttamente.
</p>
</body>
</section>
<section>
<title>Testare la configurazione</title>
<body>
<p>
In teoria, se tutto è andato bene e se il demone ssh sul server lo consente,
ora dovremmo essere in grado di ottenere l'accesso ssh sul server senza
password. Avremo ancora bisogno di decriptare la chiave pubblica sul client
con la passphrase usata prima, ma questa non dovrebbe essere confusa con la
passphrase dell'account utente sul server.
</p>
<pre caption="Testare le chiavi">
$ <i>ssh server_user@server</i>
</pre>
<p>
Con un po' di fortuna, vi sarà stata chiesto la vostra passphrase per id_dsa, e
avrete ottenuto l'accesso ssh sul server come server_user. Se così non è stato,
effettuate il login come server_user, e verificate il contrenuto di
<path>~/.ssh/authorized_keys</path> per assicurarvi che ogni voce stia in una
riga sola. Potreste anche controllare la configurazione sshd per assicurarvi
che dia la precedenza all'autorizzazione con chiave pubblica, quando
disponibile.
</p>
<p>
A questo punto, probabilmente starete pensando: "Qual è lo scopo, ho solo
sostituito una password con un'altra?!" Rilassatevi, la prossima sezione vi
mostrerà esattamente come possiamo usare questo stratagemma per risparmiare
tempo prezioso.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Rendere conveniente l'autenticazione con chiave pubblica</title>
<section>
<title>Tipica gestione delle chiavi con ssh-agent</title>
<body>
<p>
Se avete letto fino a questo punto, starete probabilmente pensando che sarebbe
grandioso se potessimo in qualche modo decriptare le nostre private una sola
volta, ottenendo l'abilità di accedere a ssh liberamente, senza alcuna password.
Siete fortunati, perché questo è esattamente ciò per cui esiste il programma
<c>ssh-agent</c>.
</p>
<p>
Il programma <c>ssh-agent</c> di solito viene eseguito all'avvio della sessione
X, oppure da uno script di shell di avvio come <path>~/.bash_profile</path>.
Esso funziona creando un socket unix e registrando le appropriate variabili
d'ambiente, in modo che tutte le applicazioni eseguite successivamente possano
sfruttare i suoi servizi per connettersi al socket. Ovviamente, ha senso solo
eseguirlo nel processo genitore della vostra sessione X, se volete usare il set
di chiavi decriptate in tutte le successive applicazioni X.
</p>
<pre caption="Preparare ssh-agent">
$ <i>ssh-agent</i>
</pre>
<note>
ssh-agent manterrà le chiavi decriptate finché sarà in esecuzione. Se volete
impostare un periodo di vita per le chiavi, usate l'argomento -t come descritto
in <c>man ssh-agent</c>.
</note>
<p>
Quando eseguite ssh-agent, questo dovrebbe dirvi il PID del processo ssh-agent
in esecuzione, oltre a impostare alcune variabili d'ambiente, ovvero
<c>SSH_AUTH_SOCK</c> e <c>SSH_AGENT_PID</c>. Dovrebbe anche aggiungere
automaticamente <path>~/.ssh/id_dsa</path> alla sua raccolta, chiedendovi la
passphrase corrispondente. Se avete altre chiavi private che volete aggiungere
a ssh-agent, potete usare il comando <c>ssh-add</c> come segue:
</p>
<pre caption="Aggiungere altre chiavi a ssh-agent">
$ <i>ssh-add somekeyfile</i>
</pre>
<p>
E adesso viene il bello. Dato che ora dovreste avere decriptato la vostra
chiave privata, dovreste essere in grado di accedere al server con ssh senza
inserire alcuna password.
</p>
<pre caption="Ssh senza password">
$ <i>ssh server</i>
</pre>
<p>
Sarebbe bello saper come terminare ssh-agent in caso di necessita, giusto?
</p>
<pre caption="Terminare ssh-agent">
$ <i>ssh-agent -k</i>
</pre>
<note>
Se avete avuto problemi a far funzionare ssh-agent, questo potrebbe essere
ancora in esecuzione. Potete killarlo come ogni altro processo, eseguendo
<c>killall ssh-agent</c>.
</note>
<p>
Se volete che ssh-agent vi sia ancora più utile, procedete alla prossima sezione
sull'uso di keychain. Prima di proseguire, assicuratevi di killare il processo ssh-agent in esecuzione, come nell'esempio sopra.
</p>
</body>
</section>
<section>
<title>Sfruttare ssh-agent fino all'ultima goccia</title>
<body>
<p>
Keychain vi consentirà di riutilizzare ssh-agent per diversi login, e
opzionalmente vi suggerirà le passphrase ad ogni login dell'utente. Ma prima di
andare avanti, dobbiamo emergerlo.
</p>
<pre caption="Installare keychain">
# <i>emerge keychain</i>
</pre>
<p>
Supponendo che l'installazione sia andata a buon fine, ora possiamo usare
keychain liberamente. Per attivarlo, aggiungete quanto segue al vostro
<path>~/.bash_profile</path>:
</p>
<pre caption="Attivare keychain in .bash_profile">
keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh
</pre>
<note>
Potete aggiungere altre chiavi private alla linea di comando, se lo desiderate.
Inoltre, se volete che vi vengano chieste le passphrase ogni volta che aprite
una shell, aggiungete l'opzione --clear.
</note>
<note>
Se non state usando bash, consultate la sezione <b>EXAMPLES</b> di <c>man
keychain</c> per esempi d'uso con altre shell. L'idea è quella di far eseguire
quei comandi ogni volta che usate una shell.
</note>
<p>
Proviamo. Per prima cosa assicuratevi di aver killato ssh-agent, eseguito nella
sezione precedente, dopodiché avviate una nuova shell, semplicemente loggandovi
o aprendo un nuovo terminale. Dovrebbe esservi suggerita la password per ogni
chiave specificata sulla linea di comando. Tutte le shell aperte da questo momento
dovrebbero riutilizzare ssh-agent, consentendovi di effettuare connessioni ssh
senza password.
</p>
</body>
</section>
<section>
<title>Usare keychain con KDE</title>
<body>
<p>
Se siete utenti KDE, anziché usare <path>~/.bash_profile</path>, potete far sì
che KDE gestisca ssh-agent per voi. Per fare ciò, dovete editare
<path>/usr/kde/${KDE_VERSION}/env/agent-startup.sh</path>, che viene letto
durante l'avvio di KDE, e
<path>/usr/kde/${KDE_VERSION}/shutdown/agent-shutdown.sh</path>, che viene
eseguito durante la chiusura di KDE, dove ${KDE_VERSION} corrisponde alle prime
due parti della versione di KDE che avete installata. Ad esempio, se state
usando KDE 3.5.1, ecco come potreste editare i file:
</p>
<pre caption="Editare /usr/kde/3.5/env/agent-startup.sh">
if [ -x /usr/bin/ssh-agent ]; then
eval "$(/usr/bin/ssh-agent -s)"
fi
</pre>
<pre caption="Editare /usr/kde/3.5/shutdown/agent-shutdown.sh">
if [ -n "${SSH_AGENT_PID}" ]; then
eval "$(ssh-agent -k)"
fi
</pre>
<p>
Ora, tutto ciò che dovete fare è lanciare un terminare a vostra scelta, come
Konsole, caricando le chiavi che desiderate usare. Per esempio:
</p>
<pre caption="Caricare chiave ssh">
keychain ~/.ssh/id_dsa
<comment>(Inserite la password della chiave)</comment>
</pre>
<p>
Le vostre chiavi verranno ricordate fino a quando non terminerete la vostra
sessione KDE o killerete manualmente ssh-agent.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Note conclusive</title>
<section>
<title>Considerazioni sulla sicurezza</title>
<body>
<p>
Ovviamente, l'uso di ssh-agent può rendere il vostro sistema un po' meno sicuro.
Se un altro utente volesse usare la vostra shell mentre siete in bagno, egli
potrebbe accedere a tutti i vostri server senza alcuna password. Questo è un
rischio per i server a cui vi state collegando, e dovreste assicurarvi di
consultare la politica locale riguardo alla sicurezza. Se lo usate,
assicuratevi di prendere misure appropriate per assicurare la sicurezza delle
vostre sessioni.
</p>
</body>
</section>
<section>
<title>Risoluzione problemi</title>
<body>
<p>
La maggiorparte di quanto detto dovrebbe funzionare abbastanza bene, ma se
incontrate problemi, vi sarà certamente utile sapere un paio di cose.
</p>
<ul>
<li>
Se non siete in grado di connettervi senza ssh-agent, provate ad usare ssh
con gli argomenti -vvv per vedere cosa sta succedendo. A volte il server
non è configurato per usare l'autenticazione con chiave pubblica, talvolta è
configurato per chiedere sempre le password locali! Se questo è il vostro
caso, potreste usare l'opzione -o con ssh, oppure modificare il file
sshd_config del server.
</li>
<li>
Se avete problemi com ssh-agent o keychain, potrebbe darsi che la shell che
state utilizzando non comprenda i comandi che essi usano. Consultate le
man pages di ssh-agent e keychain per i dettagli sul funzionamento con altre
shell.
</li>
</ul>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [gentoo-docs-it] Tradotta keychain-guide.xml
2006-03-11 13:36 [gentoo-docs-it] Tradotta keychain-guide.xml Cristiano Chiucchiolo
@ 2006-03-11 20:23 ` Stefano Rossi
0 siblings, 0 replies; 2+ messages in thread
From: Stefano Rossi @ 2006-03-11 20:23 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1: Type: text/plain, Size: 72 bytes --]
online
--
Gentoo Documentation Project
Italian Follow-Up Translator
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-03-11 20:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-11 13:36 [gentoo-docs-it] Tradotta keychain-guide.xml Cristiano Chiucchiolo
2006-03-11 20:23 ` Stefano Rossi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox