Capitolo 201. LSH

LSH ⁽¹⁾ è un sistema di comunicazione cifrata che consente di sostituirsi alle funzionalità di una shell remota, quale rsh. Il suo sviluppo è nato dalla necessità di realizzare qualcosa di simile e compatibile con il protocollo di Secure Shell (capitolo 202), ovvero quello che qui viene chiamato protocollo SECSH, secondo lo spirito del software libero, anche alla luce della sua standardizzazione attraverso il lavoro di IETF SECSH Working Group, <http://www.ietf.org/html.charters/secsh-charter.html>.

LSH si compone principalmente di quattro eseguibili essenziali: lshd, il demone che offre il servizio; lsh (oppure lshc), il programma cliente; lsh-keygen e lsh-writekey, per generare e memorizzare le chiavi pubbliche e private.

Attualmente, LSH non prevede file di configurazione, per cui i programmi ricevono le opzioni di funzionamento esclusivamente attraverso la riga di comando.

Il nome di questo programma coincide con quello di una shell normale (per l'uso locale del sistema operativo). Per questa ragione, il programma eseguibile lsh, inteso come la parte cliente della comunicazione, potrebbe avere un altro nome, per esempio lshc, onde evitare conflitti.

201.1 Attivazione del servizio LSH

Perché sia possibile attivare il servizio per ricevere connessioni secondo il protocollo SECSH, è necessario avviare il demone lshd, il quale però richiede una coppia di chiavi, privata e pubblica, che deve essere realizzata preventivamente attraverso lsh-keygen e lsh-writekey.

Supponendo di volere collocare i file della coppia di chiavi pubblica e privata nella directory /etc/lsh/, si può agire come si vede nell'esempio seguente. In seguito verrà chiarito il significato delle opzioni usate.

# lsh-keygen -l 8 | lsh-writekey /etc/lsh/lsh_host_key

In questo modo, usando una pipeline, si crea la coppia di file /etc/lsh/lsh_host_key e /etc/lsh/lsh_host_key.pub. Il primo dei due contiene la chiave privata, mentre il secondo contiene la chiave pubblica. Dato lo scopo, la chiave privata non è protetta da una parola d'ordine, dal momento che il servizio deve essere reso automaticamente. Naturalmente, il file della chiave privata deve avere soltanto i permessi indispensabili per permettere a lshd di accedervi.

Per avviare lshd, in qualità di demone, utilizzando la coppia di chiavi appena creata, si potrebbe usare il comando seguente:

# lshd --daemonic -h /etc/lsh/lsh_host_key

In questo modo, lshd si disimpegna dalla shell e si mette a funzionare sullo sfondo (l'opzione --daemonic), utilizzando la coppia di chiavi contenuta nei file /etc/lsh/lsh_host_key e /etc/lsh/lsh_host_key.pub, utilizzando la porta predefinita per le connessioni con questo tipo di protocollo.

A titolo di esempio, viene anche mostrato in che modo potrebbe essere organizzato uno script elementare per il controllo del servizio LSH, attraverso la procedura di inizializzazione del sistema.

#!/bin/sh

test -f /usr/sbin/lshd || exit 0

case "$1" in
  start)
        echo -n "Avvio del servizio LSH: "
        /usr/sbin/lshd --daemonic -h /etc/lsh/lsh_host_key
        echo
        ;;
  stop)
        echo -n "Disattivazione del servizio LSH: "
        killall lshd
        echo
        ;;
  *)
        echo "Utilizzo: lshd {start|stop}"
        exit 1
esac

201.1.1 Gestione delle chiavi

lsh-keygen e lsh-writekey, utilizzati come si vede nello schema sintattico seguente, permettono di generare e memorizzare una coppia di chiavi (privata e pubblica). Il nome del file fornito come argomento di lsh-writekey è quello della chiave privata, intendendo che la chiave pubblica abbia in più l'estensione .pub.

lsh-keygen [opzioni] | lsh-writekey file_chiave_privata

lsh-keygen da solo, genera le informazioni necessarie a definire la coppia di chiavi emettendo un certificato SPKI attraverso lo standard output, da cui lsh-writekey estrapola poi i file necessari. Segue la descrizione di alcune opzioni di lsh-keygen.

Opzione	Descrizione
`-a dsa`	Questa opzione servirebbe a consentire la selezione di un algoritmo particolare per la generazione della chiave. Attualmente è disponibile soltanto l'algoritmo DSA, come si vede dallo schema mostrato, che è ovviamente quello predefinito.
`-l {0\|1\|2\|3\|4\|5\|6\|7\|8}`	Questa opzione permette di definire la dimensione della chiave utilizzata. L'argomento numerico permette di richiedere un minimo di 512 bit, attraverso lo zero, fino a un massimo di 1 024 bit, attraverso il numero otto. Se non si specifica questa opzione, la scelta predefinita corrisponde al livello numero quattro, pari a 768 bit.

Seguono alcuni esempi.

# lsh-keygen -l 8 | lsh-writekey /etc/lsh/lsh_host_key

Genera una coppia di chiavi: /etc/lsh/lsh_host_key e /etc/lsh/lsh_host_key.pub. In particolare, viene richiesta la lunghezza di 1 024 bit.
# lsh-keygen | lsh-writekey

Genera una coppia di chiavi utilizzando le informazioni predefinite. In particolare, dovrebbe trattarsi dei file /etc/lsh_host_key e /etc/lsh_host_key.pub.

201.1.2 Avvio del servente

lshd è il servente del servizio LSH. In linea di principio, si tratta di un programma che viene avviato e fermato automaticamente dalla procedura di inizializzazione del sistema, ma può essere usato anche da un utente comune, se in tal caso ci si limita a sfruttare porte TCP non privilegiate.

lshd [opzioni]

Si può osservare che lshd non si mette a funzionare sullo sfondo in modo automatico; per questo richiede espressamente l'opzione --daemonic. Inoltre, dal momento che non dispone (per ora) di un file di configurazione, tutto viene indicato attraverso la riga di comando.

Opzione	Descrizione
`--port porta \| -p porta`	Definisce una porta di ascolto diversa da quella predefinita per questo tipo di protocollo. La porta predefinita è normalmente la numero 22, corrispondente alla denominazione convenzionale `ssh`.
`--daemonic`	Richiede esplicitamente il funzionamento come demone. Senza questa opzione, `lshd` rimane in primo piano.
`--interface interfaccia`	Consente di limitare l'ascolto all'interfaccia di rete indicata. In condizioni normali, l'ascolto è esteso a tutte le interfacce disponibili.
`-h file_chiave_privata`	Consente di indicare esplicitamente la collocazione del file contenente la chiave privata abbinata al servizio. Si intende che il file della chiave pubblica debba essere collocato nella stessa directory e contenere semplicemente l'estensione `.pub`.
`--pid-file file`	Permette di richiedere il controllo di un file contenente l'informazione sull'identità del processo relativo. Può essere utile quando si usa `lshd` nell'ambito di uno script della procedura di inizializzazione del sistema. In generale, se il file esiste già, anche se in realtà il processo relativo non esiste più, `lshd` non si avvia.
`--no-password`	Disabilita la possibilità di accedere attraverso l'uso di una parola d'ordine.
`--no-publickey`	Disabilita il meccanismo di autenticazione basato sull'uso della chiave pubblica del cliente.
`--root-login`	Consente esplicitamente l'accesso all'utente `root`, cosa che di solito è impedita.

Segue la descrizione di alcuni esempi.

# lshd --daemonic -h /etc/lsh/lsh_host_key

Avvia lshd come demone, utilizzando la chiave privata contenuta nel file lsh_host_key che si trova nella directory /etc/lsh/.
# lshd --daemonic -h /etc/lsh/lsh_host_key --port 4711

Come nell'esempio precedente, ma utilizzando la porta numero 4 711.
# lshd --daemonic -h /etc/lsh/lsh_host_key --root-login

Come nell'esempio precedente, utilizzando la porta normale e concedendo all'utente root di accedere.

201.2 Cliente del servizio LSH

Il collegamento a un servizio LSH avviene attraverso il programma lsh. Anche questo non prevede alcun file di configurazione, per cui la serie di opzioni della riga di comando è molto lunga.

Prima che un utente possa utilizzare lsh è necessario che abbia predisposto la directory ~/.lsh/ (a partire dalla propria directory personale), in cui devono essere presenti inizialmente i file identity e known_hosts, anche se vuoti. Eventualmente, si può creare la propria coppia di chiavi nel modo seguente:

$ lsh-keygen -l 8 | lsh-writekey ~/.lsh/identity

⁽²⁾

Inizialmente è possibile tentare una connessione con un servizio già avviato, più o meno nel modo seguente, dove si immagina di voler accedere al nodo dinkel.brot.dg con il nominativo tizio:

$ lsh --sloppy-host-authentication -l tizio dinkel.brot.dg

Dopo aver completato la connessione ed esserne usciti (probabilmente con un comando exit, a seconda della shell), si può osservare che è stato creato un file aggiuntivo, ~/.lsh/captured_keys, contenente la chiave pubblica del nodo remoto appena contattato. Si tratta di una cosa simile a quella seguente:

; ACL for host dinkel.brot.dg
{KDM6YWNsKDU6ZW50cnkoMTA6cHVibGljLWtleSgz...gtaG9zdGtleTk6bG9jYWxob3N0KSkpKQ==}

Se ci si fida della connessione avvenuta, nel senso che si crede realmente che si tratti della chiave pubblica del nodo che si intendeva contattare, basta ricopiare queste due righe (la prima è un commento) nel file ~/.lsh/known_hosts per poter controllare in seguito la sua identità. Infatti, l'opzione --sloppy-host-authentication era servita proprio per consentire la connessione anche senza disporre di questa informazione; in seguito, per contattare lo stesso nodo, non deve essere più usata.

201.2.1 Utilizzo del programma cliente

lsh è quindi il programma cliente per l'accesso a un servizio LSH.

lsh [opzioni] host

lshc [opzioni] host

In generale viene usato per attivare una shell, in modo da intervenire in un elaboratore remoto presso un'utenza di cui si dispone. In pratica, si tratta di una shell remota, con la quale è possibile anche limitarsi ad avviare dei comandi, il cui risultato si vuole elaborare localmente.

Opzione	Descrizione
`--port porta \| -p porta`	Permette di specificare l'uso di una porta differente da quella predefinita.
`--host-db file_nodi_conosciuti`	Permette di indicare esplicitamente quale file contiene le informazioni sui nodi conosciuti. In modo predefinito si tratta di `~/.lsh/known_hosts`.
`--sloppy-host-authentication`	Permette di ignorare il file dei nodi conosciuti, rinunciando così alla possibilità di verificare l'identità del nodo remoto. Tuttavia, in condizioni normali viene mostrata l'impronta digitale della chiave del nodo remoto, a cui segue una richiesta di conferma esplicita. Se si accetta, la chiave pubblica del nodo remoto viene annotata nel file `~/.lsh/captured_keys`.
`--strict-host-authentication`	Si tratta dell'attivazione della modalità di funzionamento per cui non si accettano connessioni se i nodi remoti non sono già conosciuti. Questo comportamento è quello normale, tanto che per aggirarlo è necessario usare l'opzione inversa `--sloppy-host-authentication`.
`--capture-to file`	Consente di indicare un file alternativo a `~/.lsh/captured_keys` per il salvataggio delle chiavi pubbliche dei nodi remoti.
`-l utente`	Consente di indicare il nominativo con cui accedere presso il sistema remoto. Se non si usa questa opzione, si usa implicitamente lo stesso nome usato nel sistema locale.
`-E comando`	Consente di indicare un comando da eseguire nel sistema remoto, al termine del quale termina la connessione. Il comando può anche essere fornito alla fine, dopo l'indicazione del nodo remoto, come avviene nella migliore tradizione delle shell remote.
`-q`	Riduce al minimo i messaggi e le domande.
`-v`	Dà informazioni utili a comprendere come avviene la connessione.

Segue la descrizione di alcuni esempi.

$ lsh --sloppy-host-authentication _<-'
^`->--capture-to ~/.lsh/known_hosts _<-'
^`->-l tizio dinkel.brot.dg

Ci si connette presso il nodo dinkel.brot.dg utilizzando il nominativo tizio, memorizzando la chiave pubblica di quel nodo direttamente nel file ~/.lsh/known_hosts.
$ lsh -l tizio dinkel.brot.dg

Ci si connette presso il nodo dinkel.brot.dg utilizzando il nominativo tizio, disponendo già di un file ~/.lsh/known_hosts aggiornato in modo tale da poter identificare il nodo remoto.
$ lsh -l tizio -E ls dinkel.brot.dg > prova

Crea localmente il file prova contenente l'elenco della directory personale dell'utente tizio presso il nodo dinkel.brot.dg.
$ lsh -l tizio dinkel.brot.dg ls > prova

Esattamente come nell'esempio precedente, ma senza l'uso esplicito dell'opzione -E.

201.3 Riferimenti

IETF SECSH Working Group

<http://www.ietf.org/html.charters/secsh-charter.html>
Martin Hamilton, psst...

<http://www.net.lut.ac.uk/psst/>

1) LSH GNU GPL

2) Tuttavia, allo stato attuale, manca la possibilità di realizzare un file ~/.lsh/authorized_keys, con il quale si renderebbe disponibile effettivamente questa funzionalità.

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome lsh.html