Provided by:
manpages-it_0.3.4-1_all 
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 lautenticazione .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.