[>a2306.html>] [<a2304.html<] [^a2.html^]
Il protocollo SecSH è nato a seguito dello sviluppo di Secure Shell, un sistema per l'accesso remoto «sicuro», che si sostituisce a quello tradizionale dei programmi come rlogin e telnet. Secure Shell, ovvero SSH, è oggi un software proprietario, ma esistono diverse realizzazioni, più o meno libere, con funzionalità analoghe, o equivalenti, che usano lo stesso protocollo.
Attraverso il protocollo SecSH si possono gestire diversi livelli di sicurezza, in cui il minimo in assoluto è rappresentato dalla cifratura della comunicazione, estendendosi a vari metodi di riconoscimento reciproco da parte dei nodi che si mettono in comunicazione.
Il software che utilizza il protocollo SecSH può instaurare un collegamento tra due elaboratori utilizzando diverse modalità, come accennato, in cui l'unica costante comune è la cifratura della comunicazione.
Semplificando molto le cose, da una parte si trova il servente che offre l'accesso e mette a disposizione una chiave pubblica, attraverso la quale i clienti dovrebbero poter verificare l'autenticità del servente a cui si connettono. Appena si verifica la connessione, prima ancora che sia stata stabilita l'identità dell'utente, cliente e servente concordano un sistema di cifratura.
Alcune realizzazioni del software che utilizza il protocollo SecSH consentono ancora, se lo si desidera, di utilizzare il vecchio meccanismo dell'autenticazione attraverso i file /etc/hosts.equiv e ~/.rhosts, che in pratica sono quelli utilizzati da rlogin e rsh.
Attraverso questi file, o un'altra coppia analoga per non interferire con rlogin e rsh, si può stabilire semplicemente quali clienti e quali utenti possono accedere senza che venga richiesta loro la password. Si tratta ovviamente di un sistema di riconoscimento molto poco sicuro, che rimane solo per motivi storici, ma in generale viene lasciato disabilitato.
Per attenuare lo stato di debolezza causato da un sistema che accetta di autenticare i clienti e gli utenti esclusivamente in base alla configurazione di /etc/hosts.equiv e ~/.rhosts (o simili), si può aggiungere la verifica della chiave pubblica del cliente.
In pratica, se il cliente dispone di una sua chiave pubblica può dimostrare al servente la sua identità.
A fianco dei metodi di autenticazione derivati da rlogin si aggiunge il metodo RSA, attraverso cui, ogni utente che intende utilizzarlo deve creare una propria chiave RSA, e nel proprio profilo personale nel servente deve indicare la parte pubblica di questa chiave. Quando l'utente tenta di accedere in questo modo, le chiavi vengono confrontate, e la corrispondenza è sufficiente a concedere l'accesso senza altre formalità.
Quando si utilizza questo tipo di autenticazione, la parte privata della chiave generata dall'utente, viene cifrata generalmente attraverso una password. In questo modo, prima di ottenere l'autenticazione, l'utente deve anche fornire questa password.
Quando tutti gli altri tipi di autenticazione falliscono, il software che utilizza il protocollo SecSH verifica l'identità dell'utente attraverso la password relativa all'accesso normale presso quel sistema.
In pratica, questa forma di autenticazione è quella più comune, dal momento che consente l'accesso senza bisogno di alcuna configurazione (a parte la generazione della chiave del nodo). Infatti, il protocollo SecSH garantisce che la password viaggi cifrata, e questo è già un grande risultato per la sicurezza dei sistemi coinvolti.
Il software che si avvale del protocollo SecSH, deve essere provvisto generalmente di un programma per la preparazione di coppie di chiavi pubbliche e private. Queste servono necessariamente per attivare il servizio, dal momento che un servente del genere non può fare nulla senza queste; inoltre possono servire dal lato cliente per facilitare l'autenticazione.
La chiave pubblica e quella privata vengono conservate in due file separati, con permessi di accesso molto restrittivi nel caso del file della chiave privata. Tuttavia, si tende a considerare che entrambi questi file debbano trovarsi nella stessa directory; inoltre, si intende generalmente che il nome del file della chiave pubblica si distingua solo perché ha in più l'estensione .pub. In questo modo, per fare riferimento alle chiavi, si indica generalmente solo il nome del file della chiave privata, intendendo implicitamente quale sia il nome del file della chiave pubblica.
Tradizionalmente, questi file hanno nomi molto simili da una realizzazione all'altra che utilizza il protocollo SecSH. Nel caso delle chiavi del servente, si tratta di qualcosa del tipo /etc/.../..._host_key e /etc/.../..._host_key.pub, mentre nel caso di chiavi personali dell'utente, si tratta di nomi del tipo ~/.../identity e ~/.../identity.pub. Gli utenti che predispongono una propria coppia di chiavi, lo fanno generalmente per poter utilizzare un'autenticazione di tipo RSA.
In generale, la chiave privata del servente non può essere protetta attraverso una password, dal momento che il servizio deve essere gestito in modo automatico; al contrario, è opportuno che la chiave privata di un utente sia protetta, dal momento che non può impedire all'amministratore del sistema di accedervi.
Un elemento importante per la garanzia della sicurezza nelle comunicazioni è la verifica dell'identità del servente. Per farlo, è necessario che il cliente possegga una copia della chiave pubblica del servente a cui si vuole accedere.
In generale, la fiducia dovrebbe essere un fatto personale, per cui tali informazioni dovrebbero essere gestite singolarmente da ogni utente che intenda sfruttare tale protocollo. Tuttavia, alcune realizzazioni tradizionali di software che sfruttano questo protocollo, consentono di definire un elenco generale di chiavi pubbliche convalidate. Di solito si tratta di file del tipo /etc/.../..._known_hosts, che oltre alle chiavi contendono le informazioni sui serventi a cui si riferiscono (a meno che queste indicazioni siano già inserite in un certificato completo).
Nello stesso modo possono agire gli utenti in file del tipo ~/.../known_hosts e ciò è preferibile in generale.
Di solito, per lo scopo che ha il protocollo SecSH, non ci si crea il problema di ottenere la chiave pubblica del servente per vie sicure, accontentandosi di accettarla la prima volta che si ha un contatto. Ciò che si ottiene in questo modo è di verificare che il servente non venga sostituito con un altro durante gli accessi successivi.
A questo proposito, il software che utilizza il protocollo SecSH può arrangiarsi a fare tutto da solo, dopo aver richiesto una conferma, oppure può pretendere che gli venga chiesto espressamente di accettare la chiave pubblica della controparte anche se questa non può essere verificata. Quello che segue è un esempio di ciò che potrebbe essere segnalato in tali circostanze.
Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?
yes[Invio]
Host 'linux.brot.dg' added to the list of known hosts.
Ovviamente, nel momento in cui si scopre che la chiave pubblica di cui si dispone non consente più di autenticare un servente, il programma che si utilizza deve dare una segnalazione adeguata. Anche in questo caso ci possono essere modi diversi di reagire: impedire l'accesso, oppure chiedere all'utente il da farsi.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the host key has just been changed. Please contact your system administrator.Appunti di informatica libera 2000.07.31 --- Copyright © 2000 Daniele Giacomini -- daniele @ swlibero.org
1) Il problema maggiore nella realizzazione di software libero di questo tipo sta nei problemi legali dovuti all'uso di questo o quell'algoritmo crittografico, che potrebbe essere brevettato, oppure potrebbe non essere ammesso dalle leggi del proprio paese.
2) Se si vuole mantenere la possibilità di utilizzare un sistema di autenticazione RHOST+RSA, in cui l'utente non debba intervenire in alcun modo, è necessario che la sua chiave privata non sia protetta da password. Ma è già stato spiegato che si tratta di un modo molto poco sicuro di gestire tale tipo di comunicazione.