| 1 |
scen 08/05/01 14:14:21 |
| 2 |
|
| 3 |
Added: openssh-key-management-p3.xml |
| 4 |
Log: |
| 5 |
Inital commit: version 1.2, revision 1.4 of EN CVS |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/it/articles/openssh-key-management-p3.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/articles/openssh-key-management-p3.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/it/articles/openssh-key-management-p3.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: openssh-key-management-p3.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding="UTF-8"?> |
| 16 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/it/articles/openssh-key-management-p3.xml,v 1.1 2008/05/01 14:14:20 scen Exp $ --> |
| 17 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 18 |
|
| 19 |
<guide link="/doc/it/articles/openssh-key-management-p3.xml" |
| 20 |
disclaimer="articles" lang="it"> |
| 21 |
<title>OpenSSH gestione delle chiavi, Parte 3</title> |
| 22 |
|
| 23 |
<author title="Autore"> |
| 24 |
<mail link="drobbins@g.o">Daniel Robbins</mail> |
| 25 |
</author> |
| 26 |
<author title="Traduzione"> |
| 27 |
<mail link="hujuice@×××××××××××.org">Sergio Vaccaro</mail> |
| 28 |
</author> |
| 29 |
|
| 30 |
<abstract> |
| 31 |
Nel terzo articolo della serie, Daniel Robbins mostra come trarre vantaggio |
| 32 |
dall'inoltro dell'agent OpenSSH per migliorare la sicurezza. Inoltre presenta i |
| 33 |
recenti miglioramenti allo script shell keychain. |
| 34 |
</abstract> |
| 35 |
|
| 36 |
<!-- The original version of this article was first published on IBM |
| 37 |
developerWorks, and is property of Westtech Information Services. This |
| 38 |
document is an updated version of the original article, and contains |
| 39 |
various improvements made by the Gentoo Linux Documentation team --> |
| 40 |
|
| 41 |
<version>1.2</version> |
| 42 |
<date>2005-10-21</date> |
| 43 |
|
| 44 |
<chapter> |
| 45 |
<title>L'inoltro dell'agent e i miglioramenti a keychain</title> |
| 46 |
<section> |
| 47 |
<body> |
| 48 |
|
| 49 |
<p> |
| 50 |
Molti usano l'eccellente OpenSSH come un sostituto sicuro e cifrato per i |
| 51 |
venerandi telnet e rsh. Una delle opportunità più intriganti di OpenSSH è la sua |
| 52 |
abilità di consentire l'autenticazione degli utenti tramite i protocolli di |
| 53 |
autenticazione RSA e DSA, che sono basati su una coppia di "chiavi" numeriche |
| 54 |
complementari. Una delle principali attrattive dell'autenticazione RSA e DSA è |
| 55 |
la promessa di essere capace di stabilire connessioni a sistemi remoti senza |
| 56 |
fornire una password. Per maggiori informazioni, si possono leggere le parti |
| 57 |
precedenti di questa serie sulla gestione delle chiavi OpenSSH, che riguardano, |
| 58 |
rispettivamente, <uri |
| 59 |
link="/doc/it/articles/openssh-key-management-p1.xml">autenticazione |
| 60 |
RSA/DSA</uri> (Parte 1) e <uri |
| 61 |
link="/doc/it/articles/openssh-key-management-p2.xml">ssh-agent e keychain</uri> |
| 62 |
(Parte 2). |
| 63 |
</p> |
| 64 |
|
| 65 |
<p> |
| 66 |
Da quando la Parte 2 è stata pubblicata su developerWorks nel settembre 2001, e |
| 67 |
più tardi citata su Slashdot e Freshmeat (vedi <uri |
| 68 |
link="#resources">Risorse</uri> più avanti in questo articolo per i link a |
| 69 |
questi siti), molte persone hanno iniziato a usare keychain, e questo ha |
| 70 |
alimentato numerosi cambiamenti. Ho ricevuto qualcosa come 20 patch di qualità |
| 71 |
da sviluppatori di tutto il mondo. Ho incorporato molte di queste patch nel |
| 72 |
codice di keychain, che ora è alla versione 1.8 (vedi <uri |
| 73 |
link="#resources">Risorse</uri>). Invio i miei sinceri ringraziamenti a tutti |
| 74 |
coloro che hanno proposto patch, segnalato bug, suggerito funzionalità e inviato |
| 75 |
note di apprezzamento. |
| 76 |
</p> |
| 77 |
|
| 78 |
</body> |
| 79 |
</section> |
| 80 |
<section> |
| 81 |
<title>Stringere le maglie alla sicurezza ssh</title> |
| 82 |
<body> |
| 83 |
|
| 84 |
<p> |
| 85 |
Nel mio <uri link="/doc/it/articles/openssh-key-management-p2.xml">ultimo |
| 86 |
articolo</uri> ho dedicato qualche tempo ad analizzare i benefici e i |
| 87 |
bilanciamenti alla sicurezza che si ottengono eseguendo ssh-agent. Pochi giorni |
| 88 |
dopo che il secondo articolo è apparso su developerWorks, ho ricevuto una e-mail |
| 89 |
da Charles Karney della Sarnoff Corporation, che mi ha informato con cortesia |
| 90 |
delle possibilità di inoltro del nuovo OpenSSH agent, che esamineremo fra poco. |
| 91 |
Inoltre, Charles ha evidenziato che eseguendo ssh-agent su macchine non fidate è |
| 92 |
leggermente pericoloso: se qualcuno riesce ad ottenere l'accesso al sistema come |
| 93 |
root, allora le chiavi decifrate possono essere estratte dall'ssh-agent. Anche |
| 94 |
se l'estrazione delle chiavi può essere genericamente difficile, è nelle |
| 95 |
possibilità dei "cracker" professionisti. Ed il solo fatto che il furto delle |
| 96 |
chiavi è possibile significa che occorre compiere alcuni passi per garantire che |
| 97 |
questo non accada. |
| 98 |
</p> |
| 99 |
|
| 100 |
<p> |
| 101 |
Per formulare una strategia per proteggere le nostre chiavi private, occorre |
| 102 |
all'inizio classificare le macchine a cui abbiamo accesso in una di due |
| 103 |
categorie. Se un particolare host è ben affidabile o isolato -- in cui |
| 104 |
l'ottenimento dell'accesso come root è davvero improbabile -- allora quella |
| 105 |
macchina deve essere considerata un host affidabile (in inglese, trusted). Se, |
| 106 |
invece, una macchina è usata da molte altre persone o se si hanno dubbi sulla |
| 107 |
sicurezza del sistema, allora la macchina deve essere considerata non affidabile |
| 108 |
(in inglese, untrusted). Per difendere le chiavi private dall'estrazione, |
| 109 |
ssh-agent (e quindi keychain) non devono mai essere eseguiti su un host non |
| 110 |
affidabile. In questo modo, anche se la sicurezza del sistema è compromessa, non |
| 111 |
ci sarà alcun ssh-agent a disposizione dell'intruso che gli consenta |
| 112 |
l'estrazione delle chiavi. |
| 113 |
</p> |
| 114 |
|
| 115 |
<p> |
| 116 |
Tuttavia, questo crea un problema. Se non possiamo eseguire ssh-agent su |
| 117 |
macchine inaffidabili, allora come possiamo stabilire connessioni ssh sicure e |
| 118 |
senza password da questi sistemi? La risposta è semplicemente usare ssh-agent e |
| 119 |
keychain sulle macchine affidabili, e usare le nuove opportunità di inoltro |
| 120 |
dell'autenticazione di OpenSSH per estendere l'autenticazione senza password |
| 121 |
alle macchine inaffidabili. In poche parole, l'inoltro dell'autenticazione |
| 122 |
funziona consentendo a sessioni ssh remote di contattare un ssh-agent in |
| 123 |
esecuzione in un host affidabile. |
| 124 |
</p> |
| 125 |
|
| 126 |
</body> |
| 127 |
</section> |
| 128 |
<section> |
| 129 |
<title>Inoltro dell'agent di autenticazione</title> |
| 130 |
<body> |
| 131 |
|
| 132 |
<p> |
| 133 |
Per aver un'idea di come funziona l'inoltro dell'autenticazione, consideriamo |
| 134 |
un'ipotetica situazione in cui un utente drobbins ha un laptop affidabile |
| 135 |
chiamato lappy, un server affidabile chiamato trustbox, e due altri sistemi non |
| 136 |
affidabili a cui deve accedere, chiamati notrust1 e notrust2, rispettivamente. |
| 137 |
Attualmente, l'utente usa ssh-agent con keychain sulle quattro macchine, come |
| 138 |
segue: |
| 139 |
</p> |
| 140 |
|
| 141 |
<figure link="/images/docs/l-ssh-3.jpg" caption="ssh-agent in esecuzione su |
| 142 |
macchine affidabili e non affidabili"/> |
| 143 |
|
| 144 |
<p> |
| 145 |
Il problema con questo approccio è che se qualcuno ottiene l'accesso come root |
| 146 |
su notrust1 o notrust2, allora è ovviamente possibile per quella persona |
| 147 |
estrarre le chiavi dall'ora vulnerabile processo ssh-agent. Per proteggersi, |
| 148 |
allora, drobbins ferma l'esecuzione di ssh-agent e keychain sugli host non |
| 149 |
affidabili notrust1 e notrust2. Di fatto, per essere estremamente cauto, |
| 150 |
drobbins ha deciso di usare ssh-agent e keychain solo su lappy. Questo limita |
| 151 |
l'esposizione delle sue chiavi private decriptate, proteggendolo dal furto |
| 152 |
delle chiavi private: |
| 153 |
</p> |
| 154 |
|
| 155 |
<figure link="/images/docs/l-ssh-4.jpg" caption="ssh-agent in esecuzione solo su |
| 156 |
lappy; una configurazione più sicura"/> |
| 157 |
|
| 158 |
<p> |
| 159 |
Certamente, il problema con questo approccio è che drobbins ora può stabilire |
| 160 |
connessioni senza password solo da lappy. Vediamo invece come abilitare |
| 161 |
l'inoltro dell'autenticazione e aggirare questo problema. |
| 162 |
</p> |
| 163 |
|
| 164 |
<p> |
| 165 |
Supponendo che tutte le macchine eseguano versioni recenti di OpenSSH, possiamo |
| 166 |
aggirare il problema utilizzando l'inoltro dell'autenticazione. L'inoltro |
| 167 |
dell'autenticazione consente che processi ssh remoti contattino l'ssh-agent in |
| 168 |
esecuzione sulla propria macchina affidabile -- invece che richiedere che una |
| 169 |
versione di ssh-agent sia in esecuzione sulla stessa macchina dalla quale si |
| 170 |
vuole iniziare il dialogo ssh. Questo generalmente consente di eseguire |
| 171 |
ssh-agent (e keychain) su una singola macchina, e significa che tutte le |
| 172 |
connessioni ssh originate (direttamente o indirettamente) da questa macchina |
| 173 |
useranno l'ssh-agent locale. |
| 174 |
</p> |
| 175 |
|
| 176 |
<p> |
| 177 |
Per abilitare l'inoltro dell'autenticazione, aggiungiamo la riga seguente al |
| 178 |
<path>/etc/ssh/ssh_config</path> di lappy e trustbox. Si osservi che questo è il |
| 179 |
file di configurazione di ssh (<path>ssh_config</path>), non il file di |
| 180 |
configurazione del demone sshd (<path>sshd_config</path>): |
| 181 |
</p> |
| 182 |
|
| 183 |
<pre caption="Aggiungiamo questa riga al file /etc/ssh/ssh_config"> |
| 184 |
ForwardAgent Yes |
| 185 |
</pre> |
| 186 |
|
| 187 |
<p> |
| 188 |
Ora, per trarre vantaggio dall'inoltro dell'autenticazione, drobbins può |
| 189 |
connettersi da lappy a trustbox, e poi da trustbox a notrust1 senza fornire |
| 190 |
parole chiave per nessuna delle connessioni. Entrambi i processi ssh attingono |
| 191 |
all'ssh-agent in esecuzione su lappy: |
| 192 |
</p> |
| 193 |
|
| 194 |
<pre caption="Le infiltrazioni di lappy"> |
| 195 |
$ <i>ssh drobbins@trustbox</i> |
| 196 |
Last login: Wed Sep 26 13:42:08 2001 from lappy |
| 197 |
|
| 198 |
Welcome to trustbox! |
| 199 |
$ <i>ssh drobbins@notrust1</i> |
| 200 |
Last login: Tue Sep 25 12:03:40 2001 from trustbox |
| 201 |
|
| 202 |
Welcome to notrust1! |
| 203 |
$ |
| 204 |
</pre> |
| 205 |
|
| 206 |
<p> |
| 207 |
Se si prova una configurazione simile e ci si accorge che l'inoltro dell'agent |
| 208 |
non funziona, si può provare <c>ssh -A</c> invece del semplice vecchio ssh per |
| 209 |
abilitare esplicitamente l'inoltro dell'autenticazione. Ecco un grafico di |
| 210 |
quello che accade dietro le quinte quando ci autentichiamo in trustbox e |
| 211 |
notrust1 usando l'inoltro dell'autenticazione: |
| 212 |
</p> |
| 213 |
|
| 214 |
<figure link="/images/docs/l-ssh-5.jpg" caption="L'inoltro dell'autenticazione |
| 215 |
in azione"/> |
| 216 |
|
| 217 |
<p> |
| 218 |
Come si vede, quando ssh si è connesso a trustbox, ha mantenuto una connessione |
| 219 |
con l'ssh-agent in esecuzione su lappy. Quando una connessione ssh è stabilita |
| 220 |
da trustbox a notrust1, questo nuovo processo ssh ha mantenuto la connessione di |
| 221 |
autenticazione del precedente ssh, estendendo di fatto la catena. Se questa |
| 222 |
catena di autenticazione può essere estesa o meno oltre notrust1 verso altri |
| 223 |
host dipende da come il <path>/etc/ssh/ssh_config</path> di notrust1 è |
| 224 |
configurato. Via via che l'inoltro dell'agente è abilitato, tutte le parti della |
| 225 |
catena possono autenticarsi usando l'ssh-agent in esecuzione sull'affidabile |
| 226 |
lappy. |
| 227 |
</p> |
| 228 |
|
| 229 |
</body> |
| 230 |
</section> |
| 231 |
<section> |
| 232 |
<title>Vantaggi dell'inoltro della connessione dell'agent</title> |
| 233 |
<body> |
| 234 |
|
| 235 |
<p> |
| 236 |
L'inoltro dell'autenticazione offre diversi vantaggi di sicurezza non esaminati |
| 237 |
finora. Per convincermi dell'importanza dell'inoltro della connessione |
| 238 |
dell'agent, Charles Karney mi ha messo a disposizione questi tre vantaggi di |
| 239 |
sicurezza: |
| 240 |
</p> |
| 241 |
|
| 242 |
<ol> |
| 243 |
<li> |
| 244 |
La chiave privata è conservata solo nella macchina affidabile. Questo |
| 245 |
impedisce a utenti malintenzionati di prelevare le chiavi private cifrate |
| 246 |
dal disco e di tentare di svelare la cifratura. |
| 247 |
</li> |
| 248 |
<li> |
| 249 |
ssh-agent è in esecuzione solo sulla macchina affidabile. Questo impedisce a |
| 250 |
un intruso di eseguire un dump della memoria di un processo ssh-agent remoto |
| 251 |
e successivamente estrarre le chiavi private decifrate dal dump. |
| 252 |
</li> |
| 253 |
<li> |
| 254 |
Poiché è necessario digitare la parola chiave solo sulla macchina |
| 255 |
affidabile,si impedisce che i programmi che catturano gli eventi della |
| 256 |
tastiera (keystroke loggers) catturino di nascosto la parola chiave così |
| 257 |
come viene digitata. |
| 258 |
</li> |
| 259 |
</ol> |
| 260 |
|
| 261 |
<p> |
| 262 |
L'unico svantaggio dell'inoltro dell'agent di autenticazione è che non consente |
| 263 |
alle attività in cron di trarre vantaggio dall'autenticazione RSA/DSA. Una |
| 264 |
soluzione a questo problema è configurare tutte le attività in cron che hanno |
| 265 |
bisogno di autenticazione RSA/DSA in modo che vengano eseguite da una macchina |
| 266 |
affidabile della LAN. Se necessario, queste attività cron possono usare ssh per |
| 267 |
connettersi a sistemi remoti dove eseguire backup automatici, sincronizzare |
| 268 |
file, e così via. |
| 269 |
</p> |
| 270 |
|
| 271 |
<p> |
| 272 |
Ora che abbiamo esaminato l'inoltro dell'agent di autenticazione, andiamo a |
| 273 |
vedere i recenti miglioramenti apportati allo stesso script keychain. |
| 274 |
</p> |
| 275 |
|
| 276 |
</body> |
| 277 |
</section> |
| 278 |
<section> |
| 279 |
<title>Miglioramenti alle funzionalità di keychain</title> |
| 280 |
<body> |
| 281 |
|
| 282 |
<p> |
| 283 |
Grazie alle proposte di patch di molti utenti, sono stati apportati molti |
| 284 |
miglioramenti al codice di keychain. Molte delle patch proposte dagli utenti |
| 285 |
riguardavano le funzionalità. Per esempio, si ricorderà che keychain crea un |
| 286 |
file <path>~/.ssh-agent</path>; il nome di questo file è stato cambiato in |
| 287 |
<path>~/.ssh-agent-[hostname]</path> in modo che keychain funzioni con home |
| 288 |
directory montate tramite NFS alle quali si può accedere da diversi host. |
| 289 |
Oltre al file <path>~/.ssh-agent-[hostname]</path>, c'è ora un file |
| 290 |
<path>~/.ssh-agent-csh-[hostname]</path> che può essere utilizzato dalle shell |
| 291 |
csh-compatibili. Infine, una nuova opzione <c>--nocolor</c> è stata aggiunta in |
| 292 |
modo da poter disattivare la "colorizzazione" se si una un terminale non vt100. |
| 293 |
</p> |
| 294 |
|
| 295 |
</body> |
| 296 |
</section> |
| 297 |
<section> |
| 298 |
<title>Correzioni alle compatibilità con le shell</title> |
| 299 |
<body> |
| 300 |
|
| 301 |
<p> |
| 302 |
Mentre i miglioramenti alle funzionalità sono stati significativi, la maggior |
| 303 |
parte delle correzioni ha riguardato la compatibilità con le shell. Come si è |
| 304 |
visto, mentre keychain 1.0 richiede bash, le versioni successive sono state |
| 305 |
modificate per lavorare con qualsiasi shell sh-compatibile. Questa modifica |
| 306 |
consente a keychain di lavorare in modo trasparente in quasi tutti i sistemi |
| 307 |
UNIX, compresi Linux, BSD, Solaris, IRIX e AIX, come anche in altre piattaforme |
| 308 |
UNIX. La transizione verso sh e la compatibilità generale UNIX è stata non solo |
| 309 |
un persorso accidentato, ma anche una straordinaria esperienza di apprendimento. |
| 310 |
Creare uno script che possa essere eseguito su tutte queste piattaforme è |
| 311 |
stato un problema di difficile soluzione, soprattutto perché semplicemente non |
| 312 |
ho accesso alla maggior parte di questi sistemi! Fortunatamente, molti utenti di |
| 313 |
keychain in tutto il mondo possono avere accesso ad altri sistemi, e molti hanno |
| 314 |
fornito una grande assistenza identificando problemi di compatibilità e |
| 315 |
sottoponendo patch per risolverli. |
| 316 |
</p> |
| 317 |
|
| 318 |
<p> |
| 319 |
Ci sono in sostanza due tipi di problemi di compatibilità che devono essere |
| 320 |
risolti. Per prima cosa, ho bisogno di essere certo che keychain usi solo |
| 321 |
espressioni e operatori nativi e pienamente supportati da tutte le |
| 322 |
implementazioni sh, incluse tutte le popolari shell UNIX sh, gratuite e |
| 323 |
commerciali, zsh (in modalità sh-compatibile) e bash nelle versioni 1 e 2. Ecco |
| 324 |
qualcuna delle correzioni per la compatibilità tra le shell proposte dagli |
| 325 |
utenti che sono state applicate al codice di keychain: |
| 326 |
</p> |
| 327 |
|
| 328 |
<p> |
| 329 |
Poiché le vecchie shell sh non supportano la convenzione ~ per far riferimento |
| 330 |
alla directory home, le linee che usano ~ sono state modificate per usare |
| 331 |
invece <c>$HOME</c>: |
| 332 |
</p> |
| 333 |
|
| 334 |
<pre caption="Trasformare in $HOME"> |
| 335 |
hostname=`uname -n` |
| 336 |
pidf=${HOME}/.ssh-agent-${hostname} |
| 337 |
cshpidf=${HOME}/.ssh-agent-csh-${hostname} |
| 338 |
</pre> |
| 339 |
|
| 340 |
<p> |
| 341 |
Inoltre, ogni riferimento al comando source è stato cambiato in . per assicurare |
| 342 |
la compatibilità con la purista /bin/sg di NetBSD, che non supporta il comando |
| 343 |
source:</p> |
| 344 |
|
| 345 |
<pre caption="Accontentare NetBSD"> |
| 346 |
if [ -f $pidf ] |
| 347 |
then |
| 348 |
. $pidf |
| 349 |
else |
| 350 |
SSH_AGENT_PID="NULL" |
| 351 |
fi |
| 352 |
</pre> |
| 353 |
|
| 354 |
<p> |
| 355 |
Lungo la strada, ho anche applicato qualche correzione per migliorare le |
| 356 |
prestazioni. Un programmatore shell di buon senso mi ha informato che invece di |
| 357 |
"toccare" un file scrivendo touch foo, si può fare invece: |
| 358 |
</p> |
| 359 |
|
| 360 |
<pre caption="Creare i file"> |
| 361 |
> <i>foo</i> |
| 362 |
</pre> |
| 363 |
|
| 364 |
<p> |
| 365 |
Facendo riferimento a una sintassi nativa di shell invece che usare un programma |
| 366 |
esterno, si evita un fork() e lo script diventa un po' più efficiente. > foo |
| 367 |
dovrebbe funzionare in tutte le shell sh-compatibili; tuttavia non sembra |
| 368 |
supportato da ash. Questo non dovrebbe essere un problema per la maggior parte |
| 369 |
delle persone, poiché ash è più una shell da disco di emergenza che qualcosa da |
| 370 |
usare per il lavoro quotidiano. |
| 371 |
</p> |
| 372 |
|
| 373 |
</body> |
| 374 |
</section> |
| 375 |
<section> |
| 376 |
<title>Rilasci degli eseguibili diversi tra piattaforme</title> |
| 377 |
<body> |
| 378 |
|
| 379 |
<p> |
| 380 |
Far sì che uno script lavori sotto diversi sistemi operativi UNIX richiede |
| 381 |
qualcosa in più che aderire ad una pura sintassi sh. Occorre ricordare che molti |
| 382 |
script invocano anche comandi esterni, come grep, awk, ps e altri, e questi |
| 383 |
comandi devono essere invocati nel modo più rispettoso possibile degli standard. |
| 384 |
Ad esempio, mentre l'echo incluso in molte versioni di UNIX riconosce l'opzione |
| 385 |
<c>-e</c>, Solaris non ha quell'opzione -- semplicemente stampa <c>-e</c> nello |
| 386 |
stdout quando eseguito. Quindi, per andare incontro a Solaris, keychain ora |
| 387 |
riconosce se <c>echo -e</c> funziona: |
| 388 |
</p> |
| 389 |
|
| 390 |
<pre caption="Accorgersi di Solaris"> |
| 391 |
if [ -z "`echo -e`" ] |
| 392 |
then |
| 393 |
E="-e" |
| 394 |
fi |
| 395 |
</pre> |
| 396 |
|
| 397 |
<p> |
| 398 |
Qui sopra, E è impostato a <c>-e</c> se l'escaping -e è supportato. Quindi echo |
| 399 |
può essere invocato come segue: |
| 400 |
</p> |
| 401 |
|
| 402 |
<pre caption="echo migliorato"> |
| 403 |
echo $E Usage: ${CYAN}${0}${OFF} [ ${GREEN}options${OFF} ] ${CYAN}sshkey${OFF} ... |
| 404 |
</pre> |
| 405 |
|
| 406 |
<p> |
| 407 |
Usando <c>echo $E</c> invece di <c>echo -e</c>, l'opzione -e può essere |
| 408 |
dinamicamente abilitata o disabilitata a secondo.</p> |
| 409 |
|
| 410 |
</body> |
| 411 |
</section> |
| 412 |
<section> |
| 413 |
<title>pidof, ps</title> |
| 414 |
<body> |
| 415 |
|
| 416 |
<p> |
| 417 |
Probabilmente la più importante correzione di compatibilità ha riguardato la |
| 418 |
modalità con cui keychain individua i processi ssh-agent attualmente in |
| 419 |
esecuzione. In precedenza, ho utilizzato il comando pidof per questo scopo, ma |
| 420 |
ho dovuto rimuoverlo perché molti sistemi non hanno un pidof. In realtà, pidof |
| 421 |
non è comunque la miglior soluzione, visto che elenca tutti i processi ssh-agent |
| 422 |
in esecuzione sul sistema, indipendentemente dall'utente, quando invece siamo |
| 423 |
interessati a tutti i processi ssh-agent di proprietà del corrente, effettivo |
| 424 |
UID. |
| 425 |
</p> |
| 426 |
|
| 427 |
<p> |
| 428 |
Quindi, invece di far riferimento a pidof, abbiamo preferito utilizzare una pipe |
| 429 |
in cui ps invia l'output a grep che lo invia ad awk, allo scopo di estrarre i |
| 430 |
necessari id dei processi. Questa è una correzione proposta da un utente: |
| 431 |
</p> |
| 432 |
|
| 433 |
<pre caption="Usare una pipe è meglio di pidof"> |
| 434 |
mypids=`ps uxw | grep ssh-agent | grep -v grep | awk '{print $2}'` |
| 435 |
</pre> |
| 436 |
|
| 437 |
<p> |
| 438 |
Questa pipe imposta la variabile mypids ai valori di tutti i processi ssh-agent |
| 439 |
di proprietà dell'utente corrente. Il comando grep -v grep fa parte della pipe |
| 440 |
per assicurarci che il processo grep ssh-agent non faccia parte della nostra |
| 441 |
lista di PID. |
| 442 |
</p> |
| 443 |
|
| 444 |
<p> |
| 445 |
Mentre questo è un buon approccio sul piano concettuale, l'uso di di ps |
| 446 |
scoperchia un nuovo ricettacolo di problemi, visto che le opzioni di ps non sono |
| 447 |
standardizzate tra derivati di UNIX come vari BSD e System V. Ecco un esempio: |
| 448 |
mentre ps uxw funziona sotto Linux, non funziona invece sotto IRIX. E mentre |
| 449 |
<c>ps -u username -f</c> funziona sotto Linux, IRIX e Solaris, non funziona |
| 450 |
invece sotto BSD, che comprende solo le opzioni ps in stile BSD. Per aggirare il |
| 451 |
problema, keychain determina automaticamente se il ps del sistema corrente |
| 452 |
funziona con la sintassi di BSD o System V prima di eseguire la pipe ps: |
| 453 |
</p> |
| 454 |
|
| 455 |
|
| 456 |
<pre caption="Individuare BSD o System V"> |
| 457 |
psopts="FAIL" |
| 458 |
ps uxw >/dev/null 2>&1 |
| 459 |
if [ $? -eq 0 ] |
| 460 |
then |
| 461 |
psopts="uxw" |
| 462 |
else |
| 463 |
ps -u `whoami` -f >/dev/null 2>&1 |
| 464 |
if [ $? -eq 0 ] |
| 465 |
then |
| 466 |
psopts="-u `whoami` -f" |
| 467 |
fi |
| 468 |
fi |
| 469 |
if [ "$psopts" = "FAIL" ] |
| 470 |
then |
| 471 |
echo $0: unable to use \"ps\" to scan for ssh-agent processes. |
| 472 |
Report KeyChain version and echo system configuration to drobbins@g.o. |
| 473 |
exit 1 |
| 474 |
fi |
| 475 |
|
| 476 |
mypids=`ps $psopts 2>/dev/null | grep "[s]sh-agent" | awk '{print $2}'` > /dev/null 2>&1 |
| 477 |
</pre> |
| 478 |
|
| 479 |
<p> |
| 480 |
Per garantire il funzionamento sia del comando ps di System V che con quello di |
| 481 |
BSD, lo script esegue una esecuzione "secca" di ps uxw, ignorando l'output. |
| 482 |
Se il codice di errore di questo comando è zero, sappiamo che ps uxw funziona e |
| 483 |
l'opzione di ps viene impostata normalmente. Invece, se ps uxw restituisce un |
| 484 |
codice di errore diverso da zero (che indica che stiamo usando opzioni di stile |
| 485 |
BSD), allora eseguiamo un secco <c>ps -u `whoami` -f</c>, di nuovo ignorando |
| 486 |
l'output. A questo punto, auspicabilmente lo script ha trovato una variante di |
| 487 |
BSD o di System V di ps da utilizzare. Se non ha trovato neanche quella, lo |
| 488 |
script stampa un messaggio di errore e esce. Ma è molto probabile che uno dei |
| 489 |
due comandi ps abbia funzionato, nel qual caso viene eseguita la linea finale |
| 490 |
del frammento di codice riportato qui sopra, la nostra pipe ps. Utilizzando |
| 491 |
l'espansione della variabile $psopts subito dopo ps, abbiamo la possibilità di |
| 492 |
passare le opzioni corrette al comando ps. |
| 493 |
</p> |
| 494 |
|
| 495 |
<p> |
| 496 |
Questa linea pipe ps contiene anche una vera perla di grep, che mi è stata |
| 497 |
gentilmente inviata da Hans Peter Verne. Si osservi che <c>grep -v grep</c> non |
| 498 |
fa più parte della linea pipe; piuttosto, è stata rimossa e <c>grep |
| 499 |
"ssh-agent"</c> è stato cambiato in grep <c>"[s]sh-agent"</c>. Questo singolo |
| 500 |
comando grep si conclude dopo aver fatto la stessa cosa di <c>grep ssh-agent | |
| 501 |
grep -v grep</c>; riuscite a capire perché? |
| 502 |
</p> |
| 503 |
|
| 504 |
<pre caption="Un trucco pulito per grep"> |
| 505 |
mypids=`ps $psopts 2>/dev/null | grep "[s]sh-agent" | awk '{print $2}'` > /dev/null 2>&1 |
| 506 |
</pre> |
| 507 |
|
| 508 |
<p> |
| 509 |
Sorpresi? Se abbiamo pensato che le linee estratte da <c>grep "ssh-agent"</c> e |
| 510 |
<c>grep "[s]sh-agent"</c> dovrebbero le stesse, abbiamo ragione. E allora |
| 511 |
perché generano diversi risultati quando l'output di ps è inviato in pipe a quei |
| 512 |
comandi? Ecco come funziona: quando si usa grep "[s]sh-agent", si cambia il modo |
| 513 |
con cui il comando grep appare nella lista generata dal processo ps. In questo |
| 514 |
modo, si impedisce a grep di selezionare se stesso, visto che la stringa |
| 515 |
[s]sh-agent con corrisponde all'espressione regolare [s]sh-agent. Non è |
| 516 |
brillante? Se non vi siete ancora impadroniti di questa tecnica, giocate un |
| 517 |
altro po' con grep e ne sarete presto ricompensati. |
| 518 |
</p> |
| 519 |
|
| 520 |
</body> |
| 521 |
</section> |
| 522 |
<section> |
| 523 |
<title>Conclusioni</title> |
| 524 |
<body> |
| 525 |
|
| 526 |
<p> |
| 527 |
Questo articolo conclude la mia panoramica su OpenSSH. Mi auguro che ne abbiate |
| 528 |
imparato abbastanza per iniziare a usare OpenSSH per rendere sicuri i vostri |
| 529 |
sistemi. Il prossimo mese, le rubriche di Common threads continueranno con la |
| 530 |
serie "Advanced filesystem implementor's guide". |
| 531 |
</p> |
| 532 |
|
| 533 |
</body> |
| 534 |
</section> |
| 535 |
</chapter> |
| 536 |
|
| 537 |
<chapter id="resources"> |
| 538 |
<title>Risorse</title> |
| 539 |
<section> |
| 540 |
<body> |
| 541 |
|
| 542 |
<ul> |
| 543 |
<li> |
| 544 |
Leggete gli altri due articoli di Daniel appartenenti a questa serie, <uri |
| 545 |
link="/doc/it/articles/openssh-key-management-p1.xml">OpenSSH gestione delle |
| 546 |
chiavi, Parte 1</uri> e <uri |
| 547 |
link="/doc/it/articles/openssh-key-management-p2.xml">OpenSSH gestione delle |
| 548 |
chiavi, Parte 2</uri> |
| 549 |
</li> |
| 550 |
<li> |
| 551 |
La versione più recente di keychain è disponibile alla <uri |
| 552 |
link="http://www.gentoo.org/proj/en/keychain/index.xml">pagina di Gentoo |
| 553 |
Linux Keychain</uri> |
| 554 |
</li> |
| 555 |
<li> |
| 556 |
Assicuratevi di vistare la <uri link="http://www.openssh.com/">home page del |
| 557 |
progetto OpenSSH</uri>, e in particolare le <uri |
| 558 |
link="http://www.openssh.com/faq.html">OpenSSH FAQ</uri> |
| 559 |
</li> |
| 560 |
<li> |
| 561 |
<uri link="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY</uri> è |
| 562 |
un eccellente client ssh per macchine Windows |
| 563 |
</li> |
| 564 |
<li> |
| 565 |
Il libro "SSH, The Secure Shell: The Definitive Guide" (O'Reilly & |
| 566 |
Associates, 2001) può essere d'aiuto. Il <uri |
| 567 |
link="http://www.snailbook.com/">sito dell'autore</uri> contiene |
| 568 |
informazioni sul libro, delle FAQ, notizie e aggiornamenti. |
| 569 |
</li> |
| 570 |
</ul> |
| 571 |
|
| 572 |
</body> |
| 573 |
</section> |
| 574 |
</chapter> |
| 575 |
</guide> |
| 576 |
|
| 577 |
|
| 578 |
|
| 579 |
-- |
| 580 |
gentoo-commits@l.g.o mailing list |
Archives