Manpages

NOME

ssh — OpenSSH, client SSH (programma per connessione remota)

SINTASSI

ssh [−l nome_utente] nomehost | utente@nomehost [comando]

ssh [−afgknqstvxACNPTX1246] [−b indirizzo_di_bind] [−c tipi_di_cifratura] [−e caratt_di_escape] [−i file_di_identificazione] [−l nome_utente] [−m mac_spec] [−o opzione] [−p porta] [−F file_config] [

−L
porta:host:portahost ] [
−R
porta:host:portahost ] [−D porta] nomehost | utente@nomehost [comando]

DESCRIZIONE

ssh (client SSH) è un programma per connettersi ad una macchina remota e per eseguirvi comandi. È destinato a sostituire rlogin e rsh e a permettere comunicazioni sicure con cifratura tra due host non fidati, attraverso una rete non sicura. Attraverso il canale sicuro così creato, possono essere effettuate anche le connessioni X11 e ogni connessione attraverso qualunque porta TCP/IP.

ssh connette e permette di accedere ad una shell dell’host nomehost. L’utente deve provare la propria identità alla macchina remota utilizzando uno dei vari metodi dipendenti dalla versione di protocollo usata:

Protocollo SSH, versione 1
Anzitutto, se la macchina con la quale l’utente si connette è elencata nei file della macchina remota /etc/hosts.equiv o in /etc/ssh/shosts.equiv e se i nomi di utente sono gli stessi da entrambe le parti, l’utente ha accesso immediato. Inoltre, se nella directory personale (home) dell’utente sulla macchina remota esistono i file .rhosts o .shosts e se in questi file c’è una riga che contiene il nome della macchina client e il nome dell’utente su quella macchina, l’utente ha l’accesso consentito. Solitamente questa forma di autenticazione non viene permessa dal server, perché è insicura.

Il secondo metodo di autenticazione unisce l’uso dei file rhosts o hosts.equiv con l’autenticazione dell’host basata su RSA. Ciò significa che la connessione è permessa solo quando è consentita da $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, o /etc/ssh/shosts.equiv e inoltre solo quando il server può verificare la chiave dell’host client (si veda /etc/ssh/ssh_known_hosts e $HOME/.ssh/known_hosts nella sezione FILE). Questo metodo di autenticazione chiude i buchi di sicurezza dovuti allo spoofing di IP, DNS e routing. [Nota per l’amministratore: /etc/hosts.equiv, $HOME/.rhosts e il protocollo rlogin/rsh in generale, sono intrinsecamente insicuri e dovrebbero essere disabilitati per poter attuare misure di sicurezza].

Come terzo metodo di autenticazione, ssh supporta l’autenticazione basata su RSA. Lo schema di funzionamento è basato sulla cifratura a chiave pubblica: esistono sistemi di cifratura in cui la codifica e la decodifica vengono fatte usando chiavi diverse e non è possibile dedurre la chiave di decodifica da quella di codifica. RSA è uno di questi sistemi. L’idea è che ogni utente si crei una coppia di chiavi pubblica/privata da usare per l’autenticazione. Il server conosce la chiave pubblica e solo l’utente conosce quella privata. Il file $HOME/.ssh/authorized_keys contiene un elenco delle chiavi pubbliche cui è consentita la connessione. Quando l’utente prova a connettersi il programma ssh informa il server riguardo alla coppia di chiavi che si vuole usare per l’autenticazione. Il server verifica se quella chiave è consentita; se è così, invia all’utente (più precisamente al programma ssh funzionante a beneficio dell’utente) un «challenge», cioè una richiesta nella forma di un numero casuale cifrato con la chiave pubblica dell’utente. Il numero può essere decifrato soltanto utilizzando la chiave privata adatta. Quindi, il programma client dell’utente decifra il numero utilizzando la chiave privata, dando prova di conoscere la chiave privata ma senza doverla comunicare al server.

ssh implementa il protocollo di autenticazione RSA in modo automatico. L’utente crea la propria coppia di chiavi per RSA utilizzando il programma ssh-keygen(1). Questo programma salva la chiave privata in $HOME/.ssh/identity e la chiave pubblica nel file $HOME/.ssh/identity.pub presente nella directory home dell’utente. L’utente, quindi, dovrebbe copiare identity.pub nella propria directory personale della macchina remota, rinominandolo come $HOME/.ssh/authorized_keys (il file authorized_keys corrisponde al file convenzionale $HOME/.rhosts ed ha una chiave per riga; nonostante questo le righe possono essere molto lunghe). Fatto ciò, l’utente può connettersi senza dover fornire la password. L’autenticazione RSA è molto più sicura dell’autenticazione basata su rhosts.

La maniera più conveniente per utilizzare l’autenticazione RSA può essere tramite un agente di autenticazione. Per altre informazioni in merito, si veda ssh-agent(1).

Se i metodi di autenticazione falliscono, ssh richiede una password all’utente. La password viene inviata all’host remoto affinché possa verificarla; tuttavia, poiché tutte le comunicazioni vengono cifrate, la password non può essere scoperta da qualcuno in ascolto sulla rete.

Protocollo SSH, versione 2
Metodi di autenticazione simili a quelli appena illustrati sono disponibili anche per utenti che si connettono usando la versione 2 del protocollo. Usando i valori predefiniti per PreferredAuthentications, il client proverà dapprima il metodo basato su host; se questo metodo fallisce viene tentato quello dell’autenticazione con la chiave pubblica; infine, se anche questo metodo fallisce, viene provato il metodo interattivo per l’autenticazione con password.

Il metodo della chiave pubblica è simile all’autenticazione RSA descritta nella precedente sezione e permette l’impiego dell’algoritmo (RSA o DSA): il client utilizza la sua chiave privata, $HOME/.ssh/id_dsa o $HOME/.ssh/id_rsa, per firmare l’identificatore di sessione e ne invia l’esito al server. Il server verifica se la chiave pubblica corrispondente è elencata in $HOME/.ssh/authorized_keys; se entrambe le chiavi vengono trovate e la firma è corretta, allora viene accordato l’accesso. L’identificatore di sessione è ricavato dal valore condiviso Diffie-Hellman, noto soltanto a client e server.

Se l’autenticazione con chiave pubblica fallisce o non è disponibile, per dimostrare l’identità dell’utente si può inviare una password cifrata all’host remoto.

Inoltre, ssh supporta l’autenticazione basata su host o con risposta a un challenge.

Il protocollo 2 fornisce meccanismi aggiuntivi di segretezza (il traffico viene cifrato usando 3DES, Blowfish, CAST128 o Arcfour) e integrità (hmac-md5, hmac-sha1). Si noti che al protocollo 1 manca un solido meccanismo per assicurare l’integrità della connessione.

Sessione di login e esecuzione remota
Quando l’identità dell’utente è stata accertata dal server, il server o esegue il comando impartito o permette all’utente l’accesso alla macchina remota tramite una normale shell. Tutte le comunicazioni con il comando remoto o la shell saranno cifrate automaticamente.

Se è stato allocato uno pseudo-terminale (per una normale sessione di login), l’utente può utilizzare i caratteri di escape riportati più sotto.

Se non è stata allocata alcuna pseudo tty, la sessione è trasparente e può essere utilizzata per trasferire dati binari in modo affidabile. Sulla maggior parte dei sistemi, la sessione sarà resa trasparente anche mediante impostazione del carattere di escape a ’’none’’, anche se viene usata una tty.

La sessione termina quando si conclude il comando o la shell sulla macchina remota e tutte le connessioni X11 e TCP/IP sono state chiuse. L’exit status del programma remoto viene restituito come exit status di ssh.

Caratteri di escape
Quando viene richiesto uno pseudo terminale, ssh supporta numerose funzioni per mezzo dei caratteri di escape.

Una singola tilde può essere inviata come ~~ oppure facendo seguire la tilde da un carattere diverso da quelli descritti di seguito. Affinché il carattere di escape sia interpretato come speciale, esso deve seguire sempre un newline. Il carattere di escape può essere modificato nei file di configurazione usando la direttiva di configurazione EscapeChar oppure usando l’opzione −e a riga di comando.

I caratteri di escape supportati (assumendo quello predefinito ’~’) sono:

~.

Disconnette

~^Z

Mette ssh in background

~#

Elenca le connessioni inoltrate

~&

Mette ssh in background al momento della disconnessione, quando attende la conclusione delle connessioni inoltrate o delle sessioni X11

~?

Visualizza l’elenco dei caratteri di escape

~C

Apre la linea di comando (utile solo per aggiungere l’inoltro di porte usando le opzioni −L e −R )

~R

Richiede la reimpostazione della cifratura (possibile solo con la versione 2 del protocollo SSH e a patto che anche la controparte ne dia supporto)

Inoltro di X11 e TCP
Se la variabile ForwardX11 è impostata a ’’yes’’ (si veda la descrizione delle opzioni −X e −x descritte più avanti) e l’utente sta usando X11 (con impostata la variabile d’ambiente DISPLAY), la connessione a X11 viene automaticamente inoltrata alla parte remota in modo tale che ogni programma (o comando) X11 avviato dalla shell viaggerà attraverso il canale cifrato e la connessione al server X effettivo sarà gestita dalla macchina locale. L’utente non deve impostare manualmente DISPLAY. L’inoltro delle connessioni X11 può essere configurato a riga di comando o nei file di configurazione.

Il valore di DISPLAY impostato da ssh punterà alla macchina che fa da server, ma con un numero di display maggiore di zero; questo è normale e succede perché ssh crea un server X ’’proxy’’ sulla macchina server per inoltrare le connessioni attraverso il canale cifrato.

ssh imposterà automaticamente anche i dati di Xauthority sulla macchina server. A tale scopo, essa genererà un cookie di autorizzazione casuale, lo salverà in Xauthority posto sul server e verificherà che ogni connessione inoltrata si porti dietro questo cookie e lo sostituisca con il vero cookie quando la connessione viene aperta. Il cookie di autenticazione vero non viene mai inviato alla macchina server (e nessun cookie viene inviato in chiaro).

Se la variabile ForwardAgent è impostata a ’’yes’’ (oppure si vedano le opzioni −A e −a descritte più avanti) e l’utente sta usando un agente di autenticazione, la connessione a questo agente viene automaticamente inoltrata alla parte remota.

L’inoltro di connessioni TCP/IP arbitrarie attraverso il canale sicuro può essere specificato sia a riga di comando che in un file di configurazione. Una possibile applicazione dell’inoltro TCP/IP è una connessione sicura ad un portafoglio elettronico; un altro ancora è l’utilizzo di una connessione attraverso i firewall.

Autenticazione del server
ssh mantiene e consulta in modo automatico, un database contenente l’identificazione di tutti gli host con cui è stato usato. Le chiavi degli host sono conservate nel file $HOME/.ssh/known_hosts posto nella directory personale dell’utente. Inoltre, anche il file /etc/ssh/ssh_known_hosts viene automaticamente consultato per identificare gli host noti. Ogni nuovo host viene automaticamente aggiunto al file dell’utente. Se l’identificazione di un host dovesse cambiare, ssh vi dà un avvertimento e disabilita l’autenticazione della password per prevenire che un cavallo di Troia possa carpire la password dell’utente. Un altro motivo di questo meccanismo è quello di evitare attacchi di tipo «man-in-the-middle», che altrimenti potrebbero essere usati per aggirare la cifratura. L’opzione StrictHostKeyChecking (si veda più sotto) può essere usata per impedire i login a macchine la cui chiave di host non sia nota o sia stata modificata.

Le opzioni sono le seguenti:

−a

Disabilita l’inoltro per la connessione dell’agente di autenticazione

−A

Abilita l’inoltro per la connessione dell’agente di autenticazione. Questo può essere indicato anche in base all’host, in un file di configurazione. Quest’opzione dovrebbe essere usata con attenzione; infatti, gli utenti che possono aggirare i permessi sui file dell’host remoto (per il socket di dominio Unix dell’agente) possono avere accesso all’agente locale attraverso la connessione inoltrata. Un potenziale aggresssore non può ottenere dall’agente qualcosa relativo alle chiavi, ma potrebbe tentare alcune operazioni che gli permetterebbero di autenticarsi usando le identità caricate dall’agente.

−b indirizzo_di_bind

Indica l’interfaccia da cui trasmettere su macchine con più interfacce o più indirizzi di alias.

−c blowfish|3des|des

Seleziona il tipo di cifratura da utilizzare per cifrare la sessione. 3des è quello predefinito ed è ritenuto solido. 3des (triplo-des) è una cifratura tripla del tipo cifra-decifra-cifra con tre chiavi diverse. blowfish è un tipo di cifratura rapido a blocchi (fast block); pare sia molto solido e molto più veloce del 3des. des è supportato solo nel client di ssh per garantire l’interoperabilità all’indietro con le implementazioni del protocollo 1 che non supportano il tipo di cifratura 3des. Il suo utilizzo è fortemente sconsigliato per via della sua debolezza.

−c tipi_di_cifratura

Inoltre, con la versione 2 del protocollo possono essere indicati più tipi di cifratura separati da virgole, riportati in ordine di preferenza. Si veda tipi_di_cifratura per altre informazioni.

−e ch|^ch|none

Imposta il carattere di escape per le sessioni con un pty (predefinito come ’~’). Il carattere di escape viene accettato solo all’inizio di una riga. Se è seguito da un punto (’.’) chiude la connessione; se è seguito da control-Z sospende la connessione; se è seguito da sé stesso invia un carattere di escape. Se si imposta il carattere a ’’none’’ si disabilita ogni tipo di escape e si rende la sessione del tutto trasparente.

−f

Ordina a ssh di andare in background poco prima dell’esecuzione del comando. Questo è utile quando ssh richiede le password, ma l’utente ne voglia comunque l’esecuzione in background. Quest’opzione richiede −n. Per avviare programmi X11 presso un sito remoto, si raccomanda di farlo in un modo come questo: ssh -f host xterm.

−g

Permette all’host remoto di connettersi alle porte locali concesse all’inoltro.

−i file_di_identificazione

Seleziona un file dal quale verranno lette le chiavi private di identificazione per l’autenticazione RSA o DSA. Il file predefinito per il protocollo 1 è $HOME/.ssh/identity; quelli predefiniti per il protocollo 2 sono $HOME/.ssh/id_rsa e $HOME/.ssh/id_dsa. I file di identificazione possono essere indicati anche in base all’host nel file di configurazione. È possibile utilizzare più opzioni −i (e si potranno indicare più chiavi di identificazione nei file di configurazione).

−I dispositivo_smartcard

Indica il dispositivo di smartcard da usare. L’argomento è il dispositivo che ssh deve usare per comunicare con una smartcard usata per conservare la chiave privata RSA dell’utente.

−k

Disabilita l’inoltro dei ticket di Kerberos e dei token AFS. Può essere indicato anche in base all’host nel file di configurazione.

−l nome_login

Indica il nome dell’utente con il quale ci si vuole connettere alla macchina remota. Può essere indicato anche in base all’host nel file di configurazione.

−m mac_spec

Con la versione 2 del protocollo può essere indicato un elenco di algoritmi MAC (message authentication code), separati da virgole e indicati in ordine di preferenza. Per altre informazioni si veda la parola chiave MACs.

−n

Ridirige lo stdin da /dev/null (usato, in realtà, per impedire la lettura da stdin). Va usato quando ssh è eseguito in background. Uno stratagemma di uso comune consiste nell’utilizzare quest’opzione per eseguire i programmi X11 su una macchina remota. Per esempio, ssh -n shadows.cs.hut.fi emacs & eseguirà emacs su shadows.cs.hut.fi e la connessione X11 sarà automaticamente inoltrata attraverso un canale cifrato. Il programma ssh sarà messo in background. (questo non funzionerà se ssh dovrà richiedere l’immissione di una password; si veda anche l’opzione −f).

−N

Non esegue un comando remoto; è utile quando si vuole fare l’inoltro delle sole porte (solo con la versione 2 del protocollo).

−o opzione

Può essere usata per far accettare opzioni espresse nel formato dei file di configurazione. È utile per indicare opzioni per le quali non esista un flag unico per la linea di comando.

−p porta

La porta cui connettersi sull’host remoto; può esserne indicata una per ogni host nel file di configurazione.

−q

Modalità silente. Evita l’emissione di tutti i messaggi diagnostici e d’avvertimento.

−s

Può essere usata per chiedere l’invocazione di un sottosistema sul sistema remoto. L’impiego dei sottosistemi è una caratteristica del protocollo SSH2 che facilita l’utilizzo di SSH come trasporto sicuro per altre applicazioni (ad es. sftp). Il sottosistema viene indicato nella forma di un comando remoto.

−t

Forza l’allocazione di uno pseudo-terminale (pseudo-tty). Può essere usata per eseguire qualsiasi programma fondato sull’uso dello schermo su una macchina remota; può essere molto utile, ad esempio per sviluppare servizi selezionabili attraverso menu. Usando più opzioni −t si forza l’allocazione del tty, anche se ssh non ne ha nessuno locale.

−T

Disabilita l’allocazione di pseudo-tty.

−v

Modalità prolissa. Ordina a ssh di stampare i messaggi che ne descrivono il progresso delle attività. È utile per monitorare i problemi di connessione, autenticazione e configurazione. Usando più opzioni −v si aumenta il volume dei messaggi; se ne possono usare un massimo di 3.

−x

Disabilita l’inoltro (detto anche ’forward’) di connessioni X11.

−X

Abilita l’inoltro di connessioni X11. Quest’opzione può anche essere indicata una per ogni host in un file di configurazione. L’inoltro di X11 dovrebbe essere abilitato con attenzione; infatti, gli utenti che possono aggirare i permessi sui file dell’host remoto (per il database delle autorizzazioni X dell’utente) possono avere accesso al display X11 locale attraverso la connessione inoltrata. Un potenziale aggressore potrebbe essere quindi in grado di compiere azioni come l’intercettazione dei tasti premuti.

−C

Richiede la compressione di tutti i dati (compresi quelli di stdin, stdout, stderr e i dati per l’inoltro delle connessioni X11 TCP/IP). L’algoritmo di compressione è lo stesso utilizzato da gzip(1) e il ’’livello’’ di compressione può essere regolato con l’opzione CompressionLevel (si veda più sotto). La compressione è auspicabile per connessioni lente come quelle via modem, ma tende a rallentare le connessioni veloci. Nei file di configurazione può essere indicato un valore predefinito per ogni host; si veda l’opzione Compression descritta più sotto.

−F file_config

Indica di utilizzare un file di configurazione alternativo, specifico dell’utente, nel qual caso verrà ignorato il file di configurazione generale (/etc/ssh/ssh_config). Il file di configurazione predefinito per ogni utente è $HOME/.ssh/config.

−L porta:host:portahost

Indica che la porta sull’host locale (il client) viene messa in comunicazione con host e porta relativi al sistema remoto. Ciò viene effettuato allocando un socket che ascolta sulla porta del sistema locale; qualora venisse usata questa porta per effettuare la connessione, quest’ultima verrebbe inoltrata attraverso il canale sicuro, così da connettere l’host locale con l’ host remoto attraverso la sua porta portahost. La porta per la connessione può essere indicata anche in un file di configurazione. Solo l’utente root può indicare porte privilegiate per le connessioni. Gli indirizzi IPv6 possono essere indicati con una sintassi alternativa: porta/host/portahost

−R porta:host:portahost

Indica che una certa porta dell’host remoto (il server) viene messa in comunicazione con host e porta del sistema locale. Ciò viene effettuato allocando un socket che ascolta sulla porta del sistema remoto; qualora questa porta venisse usata per effettuare la connessione, questa verrebbe inoltrata attraverso il canale sicuro, così da connettere l’ host remoto con quello locale attraverso la sua porta portahost. La porta per la connessione può essere indicata anche in un file di configurazione. Le porte privilegiate possono essere utilizzate solo quando si è connessi come root sulla macchina remota. Gli indirizzi IPv6 possono essere indicati con una sintassi alternativa: porta/host/portahost

−D porta

Indica una porta locale ’’dinamica’’ a livello di applicazione da usare per la comunicazione. Ciò viene effettuato allocando un socket che ascolta sulla porta del sistema locale; qualora questa porta venisse usata per effettuare la connessione, questa verrebbe inoltrata attraverso il canale sicuro e il protocollo dell’applicazione viene usato per determinare dove va effettuata la connessione dalla macchina remota. Attualmente è supportato il protocollo SOCKS4 e ssh funzionerà come server SOCKS4. Solo l’utente root può indicare porte privilegiate per le connessioni. La porta dinamica da usare per le connessioni può essere indicata anche nel file di configurazione.

−1

Forza ssh ad utilizzare soltanto la versione 1 del protocollo.

−2

Forza ssh ad utilizzare soltanto la versione 2 del protocollo.

−4

Forza ssh ad utilizzare soltanto gli indirizzi di IPv4.

−6

Forza ssh ad utilizzare soltanto gli indirizzi di IPv6.

FILE DI CONFIGURAZIONE

ssh può ottenere informazioni ulteriori da due file di configurazione, di cui uno è generale e valido per tutti gli utenti, mentre l’altro è specifico per singolo utente. Formato e opzioni dei file di configurazione sono descritti in ssh_config(5).

AMBIENTE

Normalmente, ssh imposta le seguenti variabili d’ambiente:

DISPLAY

La variabile DISPLAY indica la collocazione del server X11. È impostata automaticamente da ssh per puntare ad un valore della forma ’’nomehost:n’’ dove nomehost indica l’host su cui è in esecuzione la shell; n è un intero >= 1. ssh utilizza questo valore particolare per inoltrare le connessioni X11 attraverso un canale sicuro. Di norma, l’utente dovrebbe evitare di impostare esplicitamente DISPLAY, poiché ciò renderebbe insicura la connessione X11 (e costringerebbe l’utente a copiare manualmente tutti i cookie di autorizzazione).

HOME

Imposta il percorso della directory personale dell’utente (home).

LOGNAME

È un sinonimo per USER; va impostata per mantenere la compatibilità coi sistemi che usano questa variabile.

MAIL

Impostarla al percorso della mailbox dell’utente.

PATH

Impostarla al percorso predefinito PATH, come specificato in fase di compilazione di ssh.

SSH_ASKPASS

Se ssh è stato eseguito da un terminale e richiede una passphrase, la leggerà dal terminale corrente. Se ssh non ha un terminale associato ma sono impostate le variabili DISPLAY e SSH_ASKPASS, verrà eseguito il programma specificato da SSH_ASKPASS e sarà aperta una finestra X11 per leggere la passphrase. Questo risulta particolarmente utile quando si esegue ssh dall’interno di una .Xsession o mediante script correlati (Si noti che, per effettuare questo lavoro, su alcune macchine può essere necessario ridirigere l’input da /dev/null).

SSH_AUTH_SOCK

Identifica il percorso di un socket di dominio unix usato per comunicare con l’agente.

SSH_CONNECTION

Identifica il client e il server terminali della connessione. La variabile contiene quattro valori separati da spazi: l’indirizzo ip del client, il suo numero di porta, l’ip del server e il suo numero di porta.

SSH_ORIGINAL_COMMAND

La variabile contiene il comando originale nel caso in cui sia stato eseguito un comando forzato. Può essere utilizzato per estrarre gli argomenti originali.

SSH_TTY

È impostata al nome del terminale tty (il percorso del dispositivo) associato alla shell corrente o al comando. Se la sessione corrente non ha un tty, questa variabile non è impostata.

TZ

La variabile del fuso orario (timezone); viene impostata per indicare il fuso orario corrente nel caso in cui, all’avvio del demone, questo risultasse impostato (in pratica, il demone trasmette il valore alle nuove connessioni).

USER

È impostata al nome dell’utente connesso.

Inoltre, ssh legge in $HOME/.ssh/environment; le righe del formato ’’VARNAME=valore’’ vengono aggiunte all’ambiente se questo file esiste e se agli utenti è permesso cambiare il loro ambiente. Si veda l’opzione

PermitUserEnvironment

in sshd_config(5).

FILE
$HOME/.ssh/known_hosts

Registra le chiavi di host di tutti gli host a cui l’utente si è connesso e che non sono presenti in /etc/ssh/ssh_known_hosts. Si legga sshd(8).

$HOME/.ssh/identity, $HOME/.ssh/id_dsa, $HOME/.ssh/id_rsa

Contengono le identificazioni per l’autenticazione dell’utente, Sono file specifici per il protocollo 1 RSA, protocollo 2 DSA e protocollo 2 RSA, rispettivamente. Questi file contengono dati sensibili e dovrebbero essere leggibili dall’utente ma non accessibili da altri (per lettura/scrittura/esecuzione). Si noti che ssh ignora un file di chiave privata se è accessibile da altri. Nel generare la chiave, è possibile indicare una passphrase, che sarà usata per cifrare la parte sensibile di questo file mediante 3DES.

$HOME/.ssh/identity.pub, $HOME/.ssh/id_dsa.pub, $HOME/.ssh/id_rsa.pub

Contengono le chiavi pubbliche per l’autenticazione (la parte pubblica del file di identificazione in una forma umanamente leggibile). I contenuti del file $HOME/.ssh/identity.pub andrebbero aggiunti a $HOME/.ssh/authorized_keys su tutte le macchine in cui l’utente desidera connettersi usando la versione 1 del protocollo ssh con autenticazione RSA. I contenuti dei file $HOME/.ssh/id_dsa.pub e $HOME/.ssh/id_rsa.pub andrebbero aggiunti a $HOME/.ssh/authorized_keys su tutte le macchine in cui l’utente desidera connettersi usando la versione 2 del protocollo ssh con autenticazione DSA/RSA. Questi file non sono sensibili e possono essere eventualmente leggibili per chiunque. Questi file non sono mai usati in modo automatico e non sono necessari; sono forniti solo per utilità dell’utente.

$HOME/.ssh/config

È il file di configurazione specifico dell’utente. Il suo formato è descritto in ssh_config(5). Questo file è utilizzato dal client ssh. Solitamente, non contiene alcuna informazione sensibile, ma i permessi raccomandati sono quelli di lettura/scrittura per l’utente proprietario e nessun permesso per gli altri utenti.

$HOME/.ssh/authorized_keys

Elenca le chiavi pubbliche (RSA/DSA) che possono essere usate per connettersi come utente proprietario del file. Il suo formato è descritto nella pagina di manuale sshd(8). Nella sua forma più semplice, il formato è identico a quello dei file di identificazione .pub. Questo file non ha un contenuto particolarmente sensibile, ma i permessi raccomandati sono quelli di lettura/scrittura per l’utente proprietario e nessun permesso per gli altri utenti.

/etc/ssh/ssh_known_hosts

Elenco globale delle chiavi relative agli host conosciuti. Questo file dovrebbe essere redatto dall’amministratore di sistema e dovrebbe ospitare le chiavi pubbliche di host di tutte le macchine dell’organizzazione. Il file dovrebbe essere leggibile per tutti. Contiene le chiavi pubbliche, una per riga, nel seguente formato (campi separati da spazi): nome di sistema, chiave pubblica e campo di commento facoltativo. Quando vengono usati nomi diversi per la stessa macchina, tutti i nomi vanno elencati, separati da virgole. il formato è descritto nella pagina di manuale sshd(8).

Il nome canonico di sistema (quello restituito dai server DNS) è utilizzato da sshd(8) per verificare l’host del client all’atto della connessione; gli altri nomi sono necessari perché ssh non converte il nome fornito dall’utente in un nome canonico prima di verificare la chiave; infatti, se qualcuno avesse accesso al server DNS, potrebbe ingannare l’autenticazione dell’host.

/etc/ssh/ssh_config

File di configurazione globale. Il formato del file e le opzioni di configurazione cono descritte in ssh_config(5). Questo file fornisce i valori predefiniti per quelli non specificati nel file di configurazione specifico dell’utente e per quegli utenti privi di file di configurazione. Il file dovrebbe essere leggibile per tutti.

/etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key

Questi tre file contengono le parti private delle chiavi di host e sono utilizzati per RhostsRSAAuthentication e HostbasedAuthentication. Se si usa il metodo RhostsRSAAuthentication della versione 1 del protocollo, ssh deve essere impostato come setuid root, poiché la chiave dell’host è leggibile solo dal root. Con la versione 2 del protocollo, invece, per accedere alla chiave dell’host col metodo HostbasedAuthentication ssh usa ssh-keysign(8). In questo modo si evita di impostare ssh come setuid root quando si usa quel metodo di autenticazione. Per default, ssh non è impostato come setuid root.

$HOME/.rhosts

Questo file è utilizzato nell’autenticazione .rhosts per elencare la coppie host/utente cui è permessa la connessione (si noti che questo file è utilizzato anche da rlogin e rsh, cosa che ne rende insicuro l’utilizzo). Ogni riga del file contiene il nome di un host (nella forma canonica restituita dai DNS server) e quello di un utente su quell’host, separati da uno spazio. Su qualche macchina può essere necessario rendere leggibile a tutti questo file se la directory home dell’utente è ospitata su una partizione NFS, perché sshd(8) lo legge come root. Inoltre, questo file deve appartenere all’utente e il permesso di scrittura non deve essere concesso a nessun altro. I permessi raccomandati per la maggioranza della macchine sono di lettura/scrittura per l’utente proprietario, e nessun permesso per tutti gli altri utenti. Si noti che come comportamento predefinito sshd(8) sarà installato in modo tale da richiedere un’autenticazione di host RSA prima di permettere l’autenticazione . rhosts. Se la macchina server non ha la chiave di host del client in /etc/ssh/ssh_known_hosts, essa può essere conservata in $HOME/.ssh/known_hosts. Il modo più facile per farlo è tramite una connessione dal server al client usando ssh, che permette di aggiungere automaticamente la chiave di host a $HOME/.ssh/known_hosts.

$HOME/.shosts

Questo file è utilizzato esattamente come .rhosts. Il motivo di utilizzare questo file è di poter usare l’autenticazione rhosts con ssh senza permettere la connessione con rlogin(1) o rsh(1).

/etc/hosts.equiv

Questo file è usato durante l’autenticazione .rhosts. Esso contiene i nomi di host canonici, uno per riga (il loro formato completo è descritto nella pagina di manuale di sshd(8) ). Se l’host client è citato in questo file, la connessione viene concessa automaticamente purché il nome di utente sia lo stesso sul client e sul server. Inoltre, di solito viene richiesta l’autenticazione RSA dell’host. Questo file dovrebbe essere scrivibile solo dal root.

/etc/ssh/shosts.equiv

Questo file viene elaborato nello stesso modo di /etc/hosts.equiv. Può essere utile per permettere le connessioni utilizzando ssh ma non usando rsh/rlogin.

/etc/ssh/sshrc

I comandi in questo file vengono eseguiti da ssh esattamente prima dell’avvio della shell (o del comando). Per altre informazioni, si legga la pagina di manuale sshd(8).

$HOME/.ssh/rc

I comandi in questo file vengono eseguiti da ssh esattamente prima dell’avvio della shell (o del comando). Per altre informazioni, si legga la pagina di manuale sshd(8).

$HOME/.ssh/environment

Contiene le definizioni aggiuntive per le variabili di ambiente; si legga la sezione AMBIENTE più sopra.

DIAGNOSTICA

Se si presenta un errore, ssh esce con l’exit status del comando remoto o con 255.

AUTORI

OpenSSH è un derivato della versione originale e libera ssh 1.2.12 di Tatu Ylonen. Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt e Dug Song ne hanno eliminato molti bug, vi hanno reinserito funzionalità più recenti e hanno creato OpenSSH. Markus Friedl ha contributo con il supporto per le versioni 1.5 e 2.0 del protocollo SSH.

VEDERE ANCHE

rsh(1), scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), telnet(1), ssh_config(5), ssh-keysign(8), sshd(8).

Traduzione di Fabio Teatini. Revisione di Valentino Squilloni.

T. Ylonen

,

T. Kivinen ,
M. Saarinen ,
T. Rinne , and
S. Lehtinen ,
SSH Protocol Architecture ,
draft-ietf-secsh-architecture-09.txt ,
luglio 2001 ,
documentazione in continua evoluzione .