SSH

PROGRAMMA:

NOME

SSH — Client SSH OpenSSH (programma di accesso remoto)

SINOSSI

SSH [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_indirizzo] [-c specifica_cifra] [-D [bind_indirizzo:]porto]
[-E file_log] [-e escape_char] [-F file di configurazione] [-I pkcs11] [-i file_identità]
[-L indirizzo] [-l nome di login] [-m mac_spec] [-O ctl_cmd] [-o opzione] [-p porto]
[-Q opzione_query] [-R indirizzo] [-S ctl_percorso] [-W host:porto] [-w local_tun[:telecomando_tun]]
[Utente@]hostname [command]

DESCRIZIONE

SSH (client SSH) è un programma per accedere a una macchina remota e per eseguire comandi
su una macchina remota. Ha lo scopo di fornire comunicazioni crittografate sicure tra due
host non attendibili su una rete non sicura. Connessioni X11, porte TCP arbitrarie e
I socket di dominio UNIX possono anche essere inoltrati sul canale protetto.

SSH si connette e accede al specificato hostname (con optional Utente nome). L'utente deve
dimostrare la propria identità alla macchina remota utilizzando uno dei vari metodi (vedi sotto).

If command è specificato, viene eseguito sull'host remoto invece che su una shell di login.

Le opzioni sono le seguenti:

-1 Forze SSH per provare solo la versione 1 del protocollo.

-2 Forze SSH per provare solo la versione 2 del protocollo.

-4 Forze SSH per utilizzare solo indirizzi IPv4.

-6 Forze SSH per utilizzare solo indirizzi IPv6.

-A Abilita l'inoltro della connessione dell'agente di autenticazione. Questo può anche essere
specificato in base all'host in un file di configurazione.

L'inoltro dell'agente deve essere abilitato con cautela. Utenti con la possibilità di bypassare
i permessi dei file sull'host remoto (per il socket del dominio UNIX dell'agente) possono accedere
l'agente locale tramite la connessione inoltrata. Un utente malintenzionato non può ottenere la chiave
materiale dall'agente, tuttavia possono eseguire operazioni sui tasti che abilitano
loro di autenticarsi utilizzando le identità caricate nell'agente.

-a Disabilita l'inoltro della connessione dell'agente di autenticazione.

-b bind_indirizzo
Usa il bind_indirizzo sulla macchina locale come indirizzo di origine della connessione. Soltanto
utile su sistemi con più di un indirizzo.

-C Richiede la compressione di tutti i dati (inclusi stdin, stdout, stderr e i dati per
connessioni di dominio X11, TCP e UNIX inoltrate). L'algoritmo di compressione è il
lo stesso usato da gzip(1), e il “livello” può essere controllato dal Livello di compressione
opzione per la versione del protocollo 1. La compressione è desiderabile su linee modem e altro
connessioni lente, ma rallenterà solo le cose su reti veloci. Il predefinito
il valore può essere impostato su base host per host nei file di configurazione; vedere il
Compressione opzione.

-c specifica_cifra
Seleziona la specifica di crittografia per crittografare la sessione.

La versione 1 del protocollo consente la specifica di un singolo codice. I valori supportati
sono "3des", "blowfish" e "des". Per il protocollo versione 2, specifica_cifra è una virgola-
elenco separato di cifre elencate in ordine di preferenza. Vedi il Ciphers parola chiave in
ssh_config(5) per maggiori informazioni.

-D [bind_indirizzo:]porto
Specifica un port forwarding locale "dinamico" a livello di applicazione. Questo funziona da
allocare una presa da ascoltare porto da parte locale, facoltativamente vincolato al
specificato bind_indirizzo. Ogni volta che viene effettuata una connessione a questa porta, la connessione
viene inoltrato sul canale sicuro e il protocollo dell'applicazione viene quindi utilizzato per
determinare dove connettersi dalla macchina remota. Attualmente il SOCKS4 e
I protocolli SOCKS5 sono supportati e SSH fungerà da server SOCKS. Solo la radice può
porte privilegiate in avanti. I port forwarding dinamici possono essere specificati anche nel
file di configurazione.

Gli indirizzi IPv6 possono essere specificati racchiudendo l'indirizzo tra parentesi quadre. Soltanto
il superutente può inoltrare porte privilegiate. Per impostazione predefinita, la porta locale è vincolata in
in accordo con il Porte gateway collocamento. Tuttavia, un esplicito bind_indirizzo può essere
utilizzato per associare la connessione a un indirizzo specifico. Il bind_indirizzo di “localhost”
indica che la porta di ascolto è vincolata solo per uso locale, mentre un vuoto
indirizzo o '*' indica che la porta dovrebbe essere disponibile da tutte le interfacce.

-E file_log
Aggiungi i log di debug a file_log invece dell'errore standard.

-e escape_char
Imposta il carattere di escape per le sessioni con un pty (predefinito: '~'). La fuga
carattere viene riconosciuto solo all'inizio di una riga. Il personaggio di fuga
seguito da un punto ('.') chiude la connessione; seguito da control-Z sospende il
connessione; e seguito da solo invia il carattere di escape una volta. Impostazione del
carattere su "none" disabilita eventuali escape e rende la sessione completamente trasparente.

-F file di configurazione
Specifica un file di configurazione per utente alternativo. Se un file di configurazione è
dato sulla riga di comando, il file di configurazione a livello di sistema (/ Etc / ssh / ssh_config)
verrà ignorato. L'impostazione predefinita per il file di configurazione per utente è ~ / .ssh / config.

-f Richieste SSH per andare in background appena prima dell'esecuzione del comando. Questo è utile se
SSH chiederà password o passphrase, ma l'utente lo vuole nel
sfondo. Ciò implica -n. Il modo consigliato per avviare i programmi X11 da un telecomando
il sito è con qualcosa come SSH -f host xterm.

Se l' ExitOnForwardFailure l'opzione di configurazione è impostata su "sì", quindi un client
iniziato con -f aspetterà che tutti i port forwarding remoti abbiano successo
stabilito prima di porsi in secondo piano.

-G Cause SSH per stampare la sua configurazione dopo aver valutato ospite e partita blocchi e
Uscita.

-g Consente agli host remoti di connettersi alle porte di inoltro locali. Se utilizzato su un multiplex
connessione, allora questa opzione deve essere specificata sul processo master.

-I pkcs11
Specifica la libreria condivisa PKCS#11 SSH dovrebbe usare per comunicare con un PKCS#11
token che fornisce la chiave RSA privata dell'utente.

-i file_identità
Seleziona un file da cui l'identità (chiave privata) per l'autenticazione con chiave pubblica
viene letto. L'impostazione predefinita è ~/.ssh/identità per la versione 1 del protocollo e ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 e ~/.ssh/id_rsa per il protocollo versione 2.
I file di identità possono anche essere specificati in base all'host nel file di configurazione.
È possibile avere più -i opzioni (e identità multiple specificate in
file di configurazione). Se nessun certificato è stato esplicitamente specificato dal
FileCertificato direttiva, SSH proverà anche a caricare le informazioni sul certificato da
il nome del file ottenuto aggiungendo -cert.pub per identificare i nomi dei file.

-K Abilita l'autenticazione basata su GSSAPI e l'inoltro (delega) di GSSAPI
credenziali al server.

-k Disabilita l'inoltro (delega) delle credenziali GSSAPI al server.

-L [bind_indirizzo:]porto:host:porta ospite
-L [bind_indirizzo:]porto:presa_remota
-L presa_locale:host:porta ospite
-L presa_locale:presa_remota
Specifica che le connessioni alla data porta TCP o socket Unix sul locale
(client) devono essere inoltrati all'host e alla porta dati, o socket Unix, sul
lato remoto. Funziona allocando un socket per ascoltare un TCP porto on
il lato locale, facoltativamente legato a quello specificato bind_indirizzo, o a un socket Unix.
Ogni volta che viene effettuata una connessione alla porta o socket locale, la connessione è
inoltrato sul canale protetto e viene stabilita una connessione a entrambi host porto
porta ospite, o il socket Unix presa_remota, dalla macchina remota.

I port forwarding possono essere specificati anche nel file di configurazione. Solo il
il superutente può inoltrare le porte privilegiate. Gli indirizzi IPv6 possono essere specificati da
racchiudendo l'indirizzo tra parentesi quadre.

Per impostazione predefinita, la porta locale è vincolata in conformità con il Porte gateway impostazione.
Tuttavia, un esplicito bind_indirizzo può essere utilizzato per associare la connessione a uno specifico
indirizzo. Il bind_indirizzo di “localhost” indica che la porta di ascolto è vincolata
solo per uso locale, mentre un indirizzo vuoto o '*' indica che la porta dovrebbe essere
disponibile da tutte le interfacce.

-l nome di login
Specifica l'utente per accedere come sulla macchina remota. Anche questo può essere specificato
in base all'host nel file di configurazione.

-M Posiziona il SSH client in modalità “master” per la condivisione della connessione. multiplo -M
opzioni posti SSH in modalità “master” con richiesta di conferma prima dello slave
le connessioni sono accettate. Fare riferimento alla descrizione di Controllo Master in
ssh_config(5) per i dettagli.

-m mac_spec
Un elenco separato da virgole di algoritmi MAC (codice di autenticazione del messaggio), specificato in
ordine di preferenza. Vedi il MAC parola chiave per ulteriori informazioni.

-N Non eseguire un comando remoto. Questo è utile solo per le porte di inoltro.

-n Reindirizza lo stdin da / Dev / null (in realtà, impedisce la lettura da stdin). Questo deve
essere usato quando SSH viene eseguito in background. Un trucco comune è usarlo per eseguire X11
programmi su una macchina remota. Per esempio, SSH -n ombre.cs.hut.fi emacs & andrete a
avvia un emacs su shadows.cs.hut.fi e la connessione X11 sarà automaticamente
inoltrato su un canale crittografato. Il SSH programma verrà messo in background.
(Questo non funziona se SSH ha bisogno di chiedere una password o una passphrase; vedi anche il
-f opzione.)

-O ctl_cmd
Controllare un processo master multiplexing di connessione attiva. Quando il -O opzione è
specificato, il ctl_cmd l'argomento viene interpretato e passato al processo master.
I comandi validi sono: “check” (verifica che il processo master sia in esecuzione), “forward”
(richiesta inoltri senza esecuzione del comando), “cancel” (annulla inoltri),
“exit” (chiedere al master di uscire) e “stop” (richiedere al master di fermarsi
accettare ulteriori richieste di multiplexing).

-o opzione
Può essere utilizzato per fornire opzioni nel formato utilizzato nel file di configurazione. Questo è
utile per specificare le opzioni per le quali non esiste un flag della riga di comando separato. Per
dettagli completi delle opzioni elencate di seguito e i loro possibili valori, vedere
ssh_config(5).

Aggiungi chiavi ad agente
IndirizzoFamiglia
Modalità batch
BindAddress
Domini canonici
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePerposedCNAMEs
FileCertificato
SfidaRispostaAutenticazione
ControllaHostIP
Cifra
Ciphers
CancellaTuttiInoltri
Compressione
Livello di compressione
Tentativi di connessione
ConnectTimeout
Controllo Master
ControlPath
ControlloPersistere
Dinamico in avanti
Fuga Char
ExitOnForwardFailure
Impronta digitale Hash
Agente di inoltro
AvantiX11
InoltraX11Timeout
ForwardX11Affidabile
Porte gateway
File GlobalKnownHosts
Autenticazione GSSAPI
GSSAPIDelegateCredentials
HashKnownHost
ospite
Autenticazione basata sull'host
Tipi di chiavi basati su host
HostKeyAlgorithm
HostKeyAlias
Nome host
FileIdentità
Solo identità
IPQos
KbdInteractiveAuthentication
KbdInteractiveDevices
Algoritmi Kex
Comando Locale
LocalForward
Loglevel
MAC
partita
NoHostAuthenticationForLocalhost
Numero di richieste di password
Autenticazione password
PermessoComandoLocale
PKCS11 Provider
Porto
Autenticazioni preferite
Protocollo
Comando Proxy
ProxyUseFdpass
PubkeyAcceptedKeyTypes
PubkeyAutenticazione
RekeyLimit
Inoltro remoto
RichiestaTTY
RhostsRSAAuthentication
Autenticazione RSA
InviaEnv
ServerAliveIntervallo
ServerAliveCountMax
StreamLocalBindMask
StreamLocalBindUnlink
Controllo rigoroso della chiave host
TCP Keep Alive
Tunnel
TunnelDispositivo
AggiornaHostKeys
UsaPorta Privilegiata
Utente
UserKnownHostsFile
VerificaHostKeyDNS
VisualHostKey
XAuthLocation

-p porto
Porta a cui connettersi sull'host remoto. Questo può essere specificato in base all'host in
il file di configurazione.

-Q opzione_query
Query SSH per gli algoritmi supportati per la versione specificata 2. Il disponibile
le caratteristiche sono: cifra (cifrari simmetrici supportati), cifratura-auth (supportato simmetrico
cifrari che supportano la crittografia autenticata), Mac (integrità del messaggio supportata
codici), KEX (algoritmi di scambio di chiavi), chiave (tipi chiave), chiave-cert (chiave di certificato
tipi), chiave-semplice (tipi di chiavi non certificati), e versione-protocollo (supportato SSH
versioni del protocollo).

-q Modalità silenziosa. Provoca la soppressione della maggior parte dei messaggi di avvertenza e diagnostica.

-R [bind_indirizzo:]porto:host:porta ospite
-R [bind_indirizzo:]porto:presa_locale
-R presa_remota:host:porta ospite
-R presa_remota:presa_locale
Specifica che le connessioni alla data porta TCP o socket Unix sul telecomando
(server) host devono essere inoltrati all'host e alla porta dati, o socket Unix, sul
lato locale. Funziona allocando un socket per ascoltare un TCP porto oppure
un socket Unix sul lato remoto. Ogni volta che viene effettuata una connessione a questa porta o
Socket Unix, la connessione viene inoltrata sul canale protetto e una connessione
è fatto per entrambi host porto porta ospite, o presa_locale, dalla macchina locale.

I port forwarding possono essere specificati anche nel file di configurazione. Porte privilegiate
può essere inoltrato solo quando si effettua il login come root sulla macchina remota. Indirizzi IPv6
può essere specificato racchiudendo l'indirizzo tra parentesi quadre.

Per impostazione predefinita, i socket di ascolto TCP sul server saranno associati al loopback
solo interfaccia. Questo può essere sovrascritto specificando a bind_indirizzo. Un vuoto
bind_indirizzo, o l'indirizzo '*', indica che il socket remoto dovrebbe restare in ascolto
tutte le interfacce. Specificare un telecomando bind_indirizzo avrà successo solo se il server è
Porte gateway l'opzione è abilitata (vedi sshd_config(5)).

Se l' porto l'argomento è '0', la porta di ascolto sarà allocata dinamicamente sul
server e segnalato al client in fase di esecuzione. Se usato insieme a -O inoltrare
la porta assegnata verrà stampata sullo standard output.

-S ctl_percorso
Specifica la posizione di un socket di controllo per la condivisione della connessione o la stringa
“none” per disabilitare la condivisione della connessione. Fare riferimento alla descrizione di ControlPath e
Controllo Master in ssh_config(5) per i dettagli.

-s Può essere utilizzato per richiedere l'invocazione di un sottosistema sul sistema remoto. sottosistemi
facilitare l'uso di SSH come trasporto sicuro per altre applicazioni (ad es
sftp(1)). Il sottosistema è specificato come comando remoto.

-T Disabilita l'allocazione dello pseudo-terminale.

-t Forza l'allocazione dello pseudo-terminale. Questo può essere usato per eseguire schermate arbitrarie
programmi basati su una macchina remota, che può essere molto utile, ad esempio durante l'implementazione
servizi di menù. multiplo -t le opzioni forzano l'allocazione di tty, anche se SSH non ha locale
tty.

-V Visualizza il numero di versione ed esci.

-v Modalità dettagliata. cause SSH per stampare messaggi di debug sui suoi progressi. Questo è
utile per il debug di problemi di connessione, autenticazione e configurazione.
multiplo -v le opzioni aumentano la verbosità. Il massimo è 3.

-W host:porto
Richiede che l'input e l'output standard sul client vengano inoltrati a host on porto
sul canale protetto. Implica -N, -T, ExitOnForwardFailure e
CancellaTuttiInoltri.

-w local_tun[:telecomando_tun]
Richiede l'inoltro del dispositivo del tunnel con lo specificato fare(4) dispositivi tra i
cliente (local_tun) e il server (telecomando_tun).

I dispositivi possono essere specificati tramite ID numerico o la parola chiave "any", che utilizza il
prossimo dispositivo tunnel disponibile. Se telecomando_tun non è specificato, il valore predefinito è "qualsiasi".
Vedi anche il Tunnel e TunnelDispositivo direttive in ssh_config(5). Se la Tunnel
non è impostata, è impostata sulla modalità tunnel predefinita, che è "punto a punto".

-X Abilita l'inoltro X11. Questo può anche essere specificato in base all'host in a
file di configurazione.

L'inoltro X11 deve essere abilitato con cautela. Utenti con la possibilità di bypassare
i permessi dei file sull'host remoto (per il database di autorizzazione X dell'utente) possono
accedere al display X11 locale tramite la connessione inoltrata. Un attaccante può quindi
essere in grado di eseguire attività come il monitoraggio della pressione dei tasti.

Per questo motivo, l'inoltro X11 è soggetto alle restrizioni dell'estensione X11 SECURITY
per impostazione predefinita. Si prega di fare riferimento al SSH -Y opzione e il ForwardX11Affidabile Direttive
in ssh_config(5) per maggiori informazioni.

(Specifico per Debian: l'inoltro X11 non è soggetto all'estensione X11 SECURITY
restrizioni per impostazione predefinita, perché troppi programmi attualmente si bloccano in questa modalità.
Impostare il ForwardX11Affidabile opzione su "no" per ripristinare il comportamento a monte. Questo
potrebbe cambiare in futuro a seconda dei miglioramenti lato client.)

-x Disabilita l'inoltro X11.

-Y Abilita l'inoltro X11 affidabile. Gli inoltri X11 attendibili non sono soggetti a
X11 comandi di estensione SICUREZZA.

(Specifico per Debian: questa opzione non fa nulla nella configurazione predefinita: lo è
equivalente a "ForwardX11Affidabile yes", che è l'impostazione predefinita come descritto sopra. Set
, il ForwardX11Affidabile opzione su "no" per ripristinare il comportamento a monte. Questo potrebbe
cambiare in futuro a seconda dei miglioramenti lato client.)

-y Invia le informazioni di registro utilizzando il syslog(3) modulo di sistema. Per impostazione predefinita queste informazioni
viene inviato a stderr.

SSH può inoltre ottenere i dati di configurazione da un file di configurazione per utente e a
file di configurazione a livello di sistema. Il formato del file e le opzioni di configurazione sono descritti in
ssh_config(5).

AUTENTICAZIONE

Il client SSH OpenSSH supporta i protocolli SSH 1 e 2. L'impostazione predefinita prevede l'utilizzo del protocollo 2
solo, anche se questo può essere modificato tramite il Protocollo opzione ssh_config(5) o il -1 e -2
opzioni (vedi sopra). Il protocollo 1 non deve essere utilizzato ed è offerto solo per supportare l'eredità
dispositivi. Soffre di una serie di debolezze crittografiche e non supporta molti di
le funzionalità avanzate disponibili per il protocollo 2.

I metodi disponibili per l'autenticazione sono: autenticazione basata su GSSAPI, basata su host
autenticazione, autenticazione con chiave pubblica, autenticazione challenge-response e password
autenticazione. Tuttavia, i metodi di autenticazione vengono provati nell'ordine specificato sopra
Autenticazioni preferite può essere utilizzato per modificare l'ordine predefinito.

L'autenticazione basata su host funziona come segue: Se la macchina da cui l'utente accede è elencata
in /etc/hosts.equiv or /etc/ssh/shosts.equiv sulla macchina remota e i nomi utente sono
lo stesso su entrambi i lati, o se i file ~/.rhost or ~/.shost esiste nella casa dell'utente
directory sulla macchina remota e contenere una riga contenente il nome della macchina client
e il nome dell'utente su quella macchina, l'utente viene considerato per il login. Inoltre,
il server devono obbligatoriamente: essere in grado di verificare la chiave host del client (vedere la descrizione di
/etc/ssh/ssh_host_noti e ~/.ssh/host_noti, sotto) per consentire l'accesso. Questo
Il metodo di autenticazione chiude le falle di sicurezza dovute a IP spoofing, DNS spoofing e routing
spoofing. [Nota per l'amministratore: /etc/hosts.equiv, ~/.rhost, e rlogin/rsh
protocollo in generale, sono intrinsecamente insicuri e dovrebbero essere disabilitati se si desidera la sicurezza.]

L'autenticazione a chiave pubblica funziona come segue: lo schema si basa sulla crittografia a chiave pubblica,
utilizzando sistemi crittografici in cui la crittografia e la decrittografia vengono eseguite utilizzando chiavi separate, ed è
impossibile derivare la chiave di decrittazione dalla chiave di crittografia. L'idea è che ogni utente
crea una coppia di chiavi pubblica/privata per scopi di autenticazione. Il server conosce il pubblico
key e solo l'utente conosce la chiave privata. SSH implementa l'autenticazione con chiave pubblica
automaticamente, utilizzando uno degli algoritmi DSA, ECDSA, Ed25519 o RSA. La storia
sezione di ssl(8) (su sistemi non OpenBSD, vedere
http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY) contiene una breve
discussione degli algoritmi DSA e RSA.

Il file ~ / .ssh / authorized_keys elenca le chiavi pubbliche consentite per l'accesso.
Quando l'utente accede, il SSH programma dice al server quale coppia di chiavi vorrebbe usare
per l'autenticazione. Il client dimostra di avere accesso alla chiave privata e al server
verifica che la chiave pubblica corrispondente sia autorizzata ad accettare l'account.

L'utente crea la propria coppia di chiavi eseguendo ssh-keygen(1). Questo memorizza la chiave privata in
~/.ssh/identità (protocollo 1), ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA),
~/.ssh/id_ed25519 (Ed25519), o ~/.ssh/id_rsa (RSA) e memorizza la chiave pubblica in
~/.ssh/identity.pub (protocollo 1), ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA),
~/.ssh/id_ed25519.pub (Ed25519), o ~ / .ssh / id_rsa.pub (RSA) nella home directory dell'utente.
L'utente deve quindi copiare la chiave pubblica in ~ / .ssh / authorized_keys nella sua directory home
sulla macchina remota. Il Authorized_keys file corrisponde al convenzionale ~/.rhost
file e ha una chiave per riga, anche se le righe possono essere molto lunghe. Dopo questo, l'utente può
accedere senza fornire la password.

Una variazione sull'autenticazione a chiave pubblica è disponibile sotto forma di certificato
autenticazione: al posto di un insieme di chiavi pubbliche/private vengono utilizzati certificati firmati. Questo
ha il vantaggio che un'unica autorità di certificazione attendibile può essere utilizzata al posto di molte
chiavi pubbliche/private. Consulta la sezione CERTIFICATI di ssh-keygen(1) per maggiori informazioni.

Il modo più conveniente per utilizzare la chiave pubblica o l'autenticazione del certificato può essere con un
agente di autenticazione. Vedere ssh-agent(1) e (opzionalmente) il Aggiungi chiavi ad agente direttiva in
ssh_config(5) per maggiori informazioni.

L'autenticazione Challenge-Response funziona come segue: Il server invia un
testo "sfida" e richiede una risposta. Esempi di autenticazione challenge-response
includi l'autenticazione BSD (vedi login.conf(5)) e PAM (alcuni sistemi non OpenBSD).

Infine, se altri metodi di autenticazione falliscono, SSH richiede all'utente una password. Il
la password viene inviata all'host remoto per il controllo; tuttavia, poiché tutte le comunicazioni sono
crittografata, la password non può essere vista da qualcuno in ascolto sulla rete.

SSH mantiene e controlla automaticamente un database contenente l'identificazione per tutti gli host
è mai stato usato con. Le chiavi dell'host sono memorizzate in ~/.ssh/host_noti a casa dell'utente
directory. Inoltre, il file /etc/ssh/ssh_host_noti viene verificato automaticamente per
padroni di casa conosciuti. Eventuali nuovi host vengono aggiunti automaticamente al file dell'utente. Se un host è
l'identificazione cambia sempre, SSH avverte di ciò e disabilita l'autenticazione della password per
prevenire lo spoofing del server o attacchi man-in-the-middle, che potrebbero altrimenti essere utilizzati per
aggirare la crittografia. Il Controllo rigoroso della chiave host l'opzione può essere utilizzata per controllare gli accessi
alle macchine la cui chiave host non è nota o è stata modificata.

Quando l'identità dell'utente è stata accettata dal server, il server esegue il
dato il comando in una sessione non interattiva o, se non è stato specificato alcun comando, accede a
la macchina e fornisce all'utente una normale shell come sessione interattiva. Tutta la comunicazione
con il comando remoto o la shell verrà automaticamente crittografato.

Se è richiesta una sessione interattiva SSH per impostazione predefinita richiederà solo uno pseudo-terminale
(pty) per le sessioni interattive quando il client ne ha una. le bandiere -T e -t può essere utilizzato per
ignorare questo comportamento.

Se è stato assegnato uno pseudo-terminale, l'utente può utilizzare i caratteri di escape indicati di seguito.

Se non è stato assegnato alcuno pseudo-terminale, la sessione è trasparente e può essere utilizzata per
trasferire dati binari in modo affidabile. Sulla maggior parte dei sistemi, l'impostazione del carattere di escape su "none" lo farà
anche rendere trasparente la sessione anche se viene utilizzata una tty.

La sessione termina quando il comando o la shell sulla macchina remota esce e tutti X11 e
Le connessioni TCP sono state chiuse.

ESCAPE PERSONAGGI

Quando è stato richiesto uno pseudo-terminale, SSH supporta una serie di funzioni attraverso il
uso di un carattere di escape.

Un singolo carattere tilde può essere inviato come ~~ o seguendo la tilde da un carattere altro
rispetto a quelli descritti di seguito. Il carattere di escape deve sempre seguire una nuova riga per essere
interpretato come speciale. Il carattere di escape può essere modificato nei file di configurazione usando
, il Fuga Char direttiva di configurazione o sulla riga di comando dal -e opzione.

Gli escape supportati (assumendo il valore predefinito '~') sono:

~. Disconnetti.

~^Z sfondo SSH.

~# Elenca le connessioni inoltrate.

~& sfondo SSH al logout durante l'attesa della connessione inoltrata / sessioni X11 a
terminare.

~? Visualizza un elenco di caratteri di escape.

~B Invia un BREAK al sistema remoto (utile solo se il peer lo supporta).

~C Apri riga di comando. Attualmente questo permette l'aggiunta di port forwarding usando il
-L, -R e -D opzioni (vedi sopra). Consente inoltre la cancellazione di esistenti
port forwarding con -KL[bind_indirizzo:]porto per locale, -KR[bind_indirizzo:]porto per
remoto e -KD[bind_indirizzo:]porto per port forwarding dinamici. !command consente
all'utente di eseguire un comando locale se PermessoComandoLocale l'opzione è abilitata in
ssh_config(5). L'aiuto di base è disponibile, utilizzando il -h opzione.

~R Richiedere il rekey della connessione (utile solo se il peer lo supporta).

~V Diminuire la verbosità (Loglevel) quando gli errori vengono scritti su stderr.

~v Aumenta la verbosità (Loglevel) quando gli errori vengono scritti su stderr.

TCP INOLTRO

L'inoltro di connessioni TCP arbitrarie sul canale protetto può essere specificato su
la riga di comando o in un file di configurazione. Una possibile applicazione dell'inoltro TCP è
una connessione sicura a un server di posta; un altro sta attraversando i firewall.

Nell'esempio seguente, esaminiamo la crittografia della comunicazione tra un client e un server IRC,
anche se il server IRC non supporta direttamente le comunicazioni crittografate. Questo funziona
come segue: l'utente si connette all'host remoto usando SSH, specificando una porta da utilizzare per
inoltrare le connessioni al server remoto. Dopodiché è possibile avviare il servizio
che deve essere crittografato sulla macchina client, collegandosi alla stessa porta locale e SSH
crittograferà e inoltrerà la connessione.

L'esempio seguente esegue il tunneling di una sessione IRC dalla macchina client "127.0.0.1" (localhost) a
server remoto “server.example.com”:

$ ssh -f -L 1234:localhost:6667 server.example.com sonno 10
$ irc -c '#utenti' -p 1234 pinky 127.0.0.1

Questo incanala una connessione al server IRC "server.example.com", unendo il canale "#users",
soprannome "pinky", utilizzando la porta 1234. Non importa quale porta viene utilizzata, purché sia
maggiore di 1023 (ricorda, solo root può aprire socket su porte privilegiate) e non lo fa
conflitto con qualsiasi porta già in uso. La connessione viene inoltrata alla porta 6667 sul
server remoto, poiché è la porta standard per i servizi IRC.

-f sfondi di opzione SSH e il comando remoto “sleep 10” è specificato per consentire un
quantità di tempo (10 secondi, nell'esempio) per avviare il servizio che deve essere tunnellizzato.
Se non vengono effettuati collegamenti entro il tempo specificato, SSH uscirà.

X11 INOLTRO

Se l' AvantiX11 variabile è impostata su "sì" (o vedere la descrizione del -X, -x e -Y
opzioni sopra) e l'utente sta usando X11 (la variabile d'ambiente DISPLAY è impostata), il
la connessione al display X11 viene automaticamente inoltrata al lato remoto in questo modo
che qualsiasi programma X11 avviato dalla shell (o comando) passerà attraverso il criptato
canale e la connessione al server X reale verrà effettuata dalla macchina locale. Il
l'utente non deve impostare manualmente DISPLAY. L'inoltro delle connessioni X11 può essere configurato su
la riga di comando o nei file di configurazione.

Il valore DISPLAY impostato da SSH punterà alla macchina server, ma con un numero di visualizzazione
maggiore di zero. Questo è normale e succede perché SSH crea un server X "proxy" su
la macchina server per l'inoltro delle connessioni sul canale crittografato.

SSH imposterà automaticamente anche i dati Xauthority sulla macchina server. Per questo scopo,
genererà un cookie di autorizzazione casuale, lo memorizzerà in Xauthority sul server e
verificare che eventuali connessioni inoltrate contengano questo cookie e sostituirlo con il cookie reale
quando viene aperta la connessione. Il vero cookie di autenticazione non viene mai inviato al server
macchina (e nessun cookie viene inviato in pianura).

Se l' Agente di inoltro variabile è impostata su "sì" (o vedere la descrizione del -A e -a
opzioni sopra) e l'utente sta utilizzando un agente di autenticazione, la connessione all'agente è
automaticamente inoltrato al lato remoto.

VERIFICA HOST CHIAVI

Quando ci si connette a un server per la prima volta, un'impronta digitale della chiave pubblica del server è
presentato all'utente (a meno che l'opzione Controllo rigoroso della chiave host è stato disabilitato).
Le impronte digitali possono essere determinate utilizzando ssh-keygen(1)

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Se l'impronta digitale è già nota, può essere abbinata e la chiave può essere accettata oppure
respinto. Se sono disponibili solo impronte digitali legacy (MD5) per il server, ssh-keygen(1)
-E L'opzione può essere utilizzata per eseguire il downgrade dell'algoritmo dell'impronta digitale in modo che corrisponda.

A causa della difficoltà di confrontare le chiavi host semplicemente osservando le stringhe delle impronte digitali,
c'è anche il supporto per confrontare visivamente le chiavi host, usando con arte. Impostando il
VisualHostKey opzione su "sì", un piccolo grafico ASCII viene visualizzato ad ogni accesso a a
server, indipendentemente dal fatto che la sessione stessa sia interattiva o meno. Imparando il modello a
server noto produce, un utente può facilmente scoprire che la chiave dell'host è cambiata quando a
viene visualizzato un modello completamente diverso. Perché questi modelli non sono univoci
tuttavia, un modello che sembra simile al modello ricordato dà solo un buon risultato
probabilità che la chiave host sia la stessa, prova non garantita.

Per ottenere un elenco delle impronte digitali insieme alla loro arte casuale per tutti gli host conosciuti, il
è possibile utilizzare la seguente riga di comando:

$ ssh-keygen -lv -f ~/.ssh/host_noti

Se l'impronta digitale è sconosciuta, è disponibile un metodo di verifica alternativo: SSH
impronte digitali verificate dal DNS. Un record di risorse aggiuntivo (RR), SSHFP, viene aggiunto a a
zonefile e il client che si connette è in grado di abbinare l'impronta digitale a quella della chiave
presentati.

In questo esempio, stiamo connettendo un client a un server, "host.example.com". L'SSHFP
i record di risorse devono essere prima aggiunti al file zone per host.example.com:

$ ssh-keygen -r host.esempio.com.

Le righe di output dovranno essere aggiunte al zonefile. Per verificare che la zona risponda
query sulle impronte digitali:

$ dig -t SSHFP host.esempio.com

Infine il client si connette:

$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Fingerprint della chiave host corrispondente trovata nel DNS.
Sei sicuro di voler continuare a connetterti (sì / no)?

Vedere la VerificaHostKeyDNS opzione ssh_config(5) per maggiori informazioni.

A BASE SSH VIRTUALE PRIVATO NETWORKS

SSH contiene il supporto per il tunneling della rete privata virtuale (VPN) utilizzando il fare(4) rete
pseudo-dispositivo, che consente l'unione sicura di due reti. Il sshd_config(5)
opzione di configurazione PermessoTunnel controlla se il server lo supporta e in che modo
livello (traffico di livello 2 o 3).

L'esempio seguente collegherebbe la rete client 10.0.50.0/24 con la rete remota
10.0.99.0/24 utilizzando un collegamento punto-punto dal 10.1.1.1 al 10.1.1.2, a condizione che il
Il server SSH in esecuzione sul gateway per la rete remota, a 192.168.1.15, lo consente.

Sul cliente:

# ssh -f -w 0:1 192.168.1.15 vero
# ifconfig tun0 10.1.1.1 10.1.1.2 maschera di rete 255.255.255.252
# percorso aggiungi 10.0.99.0/24 10.1.1.2

Sul server:

# ifconfig tun1 10.1.1.2 10.1.1.1 maschera di rete 255.255.255.252
# percorso aggiungi 10.0.50.0/24 10.1.1.1

L'accesso del cliente può essere regolato più finemente tramite il /root/.ssh/chiavi_autorizzate file (vedi sotto)
e le PermessoRootLogin opzione server. La seguente voce consentirebbe le connessioni su
fare(4) dispositivo 1 dall'utente "jane" e su tun dispositivo 2 dall'utente "john", se PermessoRootLogin is
impostato su "solo comandi forzati":

tunnel="1", comando="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2", comando="sh /etc/netstart tun2" ssh-rsa ... giovanni

Poiché una configurazione basata su SSH comporta una discreta quantità di sovraccarico, potrebbe essere più adatta a
configurazioni temporanee, come per le VPN wireless. VPN più permanenti sono meglio fornite da
strumenti come ipsec(8) e isakmpd(8).

AMBIENTE

SSH normalmente imposterà le seguenti variabili di ambiente:

DISPLAY La variabile DISPLAY indica la posizione del server X11. è
impostato automaticamente da SSH per puntare a un valore della forma "hostname:n",
dove "hostname" indica l'host in cui viene eseguita la shell e 'n' è
un intero ≥ 1. SSH usa questo valore speciale per inoltrare X11
connessioni sul canale protetto. L'utente normalmente non dovrebbe impostare
DISPLAY esplicitamente, in quanto ciò renderebbe insicura la connessione X11
(e richiederà all'utente di copiare manualmente qualsiasi autorizzazione richiesta
biscotti).

HOME Impostato sul percorso della directory home dell'utente.

LOGNAME Sinonimo di USER; impostato per la compatibilità con i sistemi che utilizzano questo
variabile.

MAIL Impostato sul percorso della casella di posta dell'utente.

PATH Imposta il PATH predefinito, come specificato durante la compilazione SSH.

SSH_ASKPASS Se SSH ha bisogno di una passphrase, leggerà la passphrase dal
terminale corrente se è stato eseguito da un terminale. Se SSH non ha
un terminale ad esso associato ma DISPLAY e SSH_ASKPASS sono impostati, it
eseguirà il programma specificato da SSH_ASKPASS e aprirà un X11
finestra per leggere la passphrase. Ciò è particolarmente utile quando
chiamata SSH da parte di un .xsession o script correlato. (Nota che su alcuni
macchine potrebbe essere necessario reindirizzare l'input da / Dev / null a
fare questo lavoro.)

SSH_AUTH_SOCK Identifica il percorso di un socket di dominio UNIX utilizzato per comunicare con
l'agente.

SSH_CONNECTION Identifica le estremità client e server della connessione. La variabile
contiene quattro valori separati da spazi: indirizzo IP client, porta client
numero, indirizzo IP del server e numero di porta del server.

SSH_ORIGINAL_COMMAND Questa variabile contiene la riga di comando originale se un comando forzato
viene eseguito. Può essere usato per estrarre gli argomenti originali.

SSH_TTY Questo è impostato sul nome del tty (percorso del dispositivo) associato
con la shell o il comando corrente. Se la sessione corrente non ha tty,
questa variabile non è impostata.

TZ Questa variabile è impostata per indicare il fuso orario attuale se è stata impostata
quando il demoneèstato avviato (cioè il demone passa il valore a
nuovi collegamenti).

UTENTE Impostato sul nome dell'utente che effettua il login.

Inoltre, SSH legge ~/.ssh/ambientee aggiunge righe del formato "NOMEVAR=valore" a
l'ambiente se il file esiste e gli utenti possono modificare il proprio ambiente. Per
maggiori informazioni, vedere il Ambiente utente permesso opzione sshd_config(5).

Usa ssh online usando i servizi onworks.net