Ubuntu Manpage: ssh — client de autentificare la distanță OpenSSH

NUME

       ssh — client de autentificare la distanță OpenSSH

SINOPSIS

       ssh  [-46AaCfGgKkMNnqsTtVvXxYy]  [-B  interfață-asociere] [-b adresă-asociere] [-c specificare-cifru] [-D
       [adresă-asociere:]port] [-E fișier-jurnal] [-e caracter-control] [-F fișier-configurare] [-I pkcs11]  [-i
       fișier-identitate]  [-J  destinație]  [-L adresă] [-l nume_utilizator-autentificare] [-m specificare-mac]
       [-O comandă-control] [-o opțiune] [-P etichetă] [-p port] [-R adresă] [-S rută-control]  [-W  gazdă:port]
       [-w tunel-local[:tunel-la_distanță]] destinație [comandă [argument ...]] ssh [-Q opțiune-interogare]

DESCRIERE

ssh (client SSH) este un program pentru autentificarea într-o mașină la distanță și pentru executarea de
comenzi pe o mașină la distanță. Acesta este destinat să asigure comunicații criptate sigure între două
gazde neîncrezătoare printr-o rețea nesigură. Conexiunile X11, porturile TCP arbitrare și soclurile
Unix-domain pot fi de asemenea transmise pe canalul securizat.

ssh se conectează și se autentifică la destinația specificată, care poate fi specificată fie ca
[utilizator@]nume-gazdă sau un URI de forma ssh://[utilizator@]nume-gazdă[:port]. Utilizatorul trebuie
să își dovedească identitatea față de mașina de la distanță folosind una dintre mai multe metode (a se
vedea mai jos).

Dacă este specificată o comandă, aceasta va fi executată pe gazda de la distanță în locul unui shell de
autentificare. O linie de comandă completă poate fi specificată ca comandă, sau poate avea argumente
suplimentare. Dacă sunt furnizate, argumentele vor fi adăugate la comandă, separate prin spații, înainte
ca aceasta să fie trimisă la server pentru a fi executată.

Opțiunile sunt următoarele:

-4 Forțează ssh să utilizeze numai adrese IPv4.

-6 Forțează ssh să utilizeze numai adrese IPv6.

-A Permite redirecționarea conexiunilor de la un agent de autentificare precum ssh-agent(1). Acest
lucru poate fi, de asemenea, specificat pentru fiecare gazdă într-un fișier de configurare.

Transmiterea agentului trebuie activată cu precauție. Utilizatorii care au capacitatea de a ocoli
permisiunile de fișier pe gazda de la distanță (pentru soclul Unix-domain al agentului) pot
accesa agentul local prin conexiunea redirecționată. Un atacator nu poate obține materialul
cheii de la agent, însă poate efectua operații asupra cheilor care îi permit să se autentifice
folosind identitățile încărcate în agent. O alternativă mai sigură poate fi utilizarea unei gazde
de salt (a se vedea -J).

-a Dezactivează redirecționarea conexiunii agentului de autentificare.

-B interfață-asociere
Se leagă la adresa interfață-asociere înainte de a încerca să se conecteze la gazda de
destinație. Acest lucru este util numai pe sistemele cu mai multe adrese.

-b adresă-asociere
Utilizează adresă-asociere de pe mașina locală ca adresă sursă a conexiunii. Utilă numai pe
sistemele cu mai multe adrese.

-C Solicită comprimarea tuturor datelor (inclusiv stdin, stdout, stderr și datele pentru conexiunile
X11, TCP și Unix-domain redirecționate). Algoritmul de comprimare este același cu cel utilizat de
gzip(1). Comprimarea este de dorit pe liniile modem și alte conexiuni lente, dar va încetini
lucrurile doar pe rețelele rapide. Valoarea implicită poate fi stabilită gazdă cu gazdă în
fișierele de configurare; consultați opțiunea Compression din ssh_config(5).

-c specificare-cifru
Selectează specificația cifrului pentru criptarea sesiunii. specificare-cifru este o listă de
cifruri separate prin virgulă, enumerate în ordinea preferințelor. Consultați cuvântul cheie
Ciphers din ssh_config(5) pentru mai multe informații.

-D [adresă-asociere:]port
Specifică o redirecționare de port la nivel de aplicație “dinamică” locală. Aceasta funcționează
prin alocarea unui soclu pentru a asculta port pe partea locală, legat opțional la
adresa-de-asociere specificată. Ori de câte ori se realizează o conexiune la acest port,
conexiunea este redirecționată pe canalul securizat, iar protocolul aplicației este apoi utilizat
pentru a determina unde să se conecteze de la mașina de la distanță. În prezent sunt acceptate
protocoalele SOCKS4 și SOCKS5, iar ssh va acționa ca un server SOCKS. Numai root poate
redirecționa porturile privilegiate. Transmiterea dinamică a porturilor poate fi, de asemenea,
specificată în fișierul de configurare.

Adresele IPv6 pot fi specificate prin includerea adresei între paranteze drepte. Numai
superutilizatorul poate redirecționa porturile privilegiate. În mod implicit, portul local este
legat în conformitate cu valoarea opțiunii GatewayPorts. Cu toate acestea, se poate utiliza o
adresă-de-asociere explicită pentru a lega conexiunea la o anumită adresă. adresa-de-asociere de
“localhost” indică faptul că portul de ascultare trebuie legat numai pentru uz local, în timp ce
o adresă goală sau ‘*’ indică faptul că portul trebuie să fie disponibil de la toate interfețele.

-E fișier-jurnal
Adaugă jurnalele de depanare la fișier-jurnal în loc de la ieșirea de eroare standard.

-e caracter-control
Stabilește caracterul de eludaare(control) pentru sesiunile cu un pty (implicit: ‘~’).
Caracterul de control este recunoscut numai la începutul unei linii. Caracterul de control urmat
de un punct (‘.’) închide conexiunea; urmat de control-Z suspendă conexiunea; și urmat de sine
trimite caracterul de control o dată. Definirea caracterului la “none” dezactivează orice
eludare(control) și face sesiunea complet transparentă.

-F fișier-configurare
Specifică un fișier alternativ de configurare per utilizator. Dacă se indică un fișier de
configurare în linia de comandă, fișierul de configurare la nivel de sistem (/etc/ssh/ssh_config)
va fi ignorat. Valoarea implicită pentru fișierul de configurare per utilizator este
~/.ssh/config. Dacă este definit la “none”, nu va fi citit niciun fișier de configurare.

-f Solicită ssh să treacă în fundal chiar înainte de executarea comenzii. Acest lucru este util în
cazul în care ssh urmează să solicite parole sau fraze de acces, dar utilizatorul dorește ca
aceasta să fie în fundal. Aceasta implică -n. Modul recomandat de a porni programe X11 la
distanță este ceva precum ssh -f gazda xterm.

Dacă opțiunea de configurare ExitOnForwardFailure este stabilită la “yes”, atunci un client
inițiat cu -f va aștepta ca toate redirecționările porturilor la distanță să fie stabilite cu
succes înainte de a se plasa în fundal. Consultați descrierea ForkAfterAuthentication în
ssh_config(5) pentru detalii.

-G Determină ssh să imprime configurația sa după evaluarea blocurilor Host și Match și să iasă.

-g Permite gazdelor de la distanță să se conecteze la porturile locale redirecționate. Dacă este
utilizată pe o conexiune multiplexată, această opțiune trebuie specificată în procesul principal.

-I pkcs11
Specifică biblioteca partajată PKCS#11 pe care ssh ar trebui să o utilizeze pentru a comunica cu
un jeton PKCS#11 care furnizează chei pentru autentificarea utilizatorului.

-i fișier-identitate
Selectează un fișier din care este citită identitatea (cheia privată) pentru autentificarea cu
cheie publică. De asemenea, puteți specifica un fișier de cheie publică pentru a utiliza cheia
privată corespunzătoare care este încărcată în ssh-agent(1) atunci când fișierul de cheie privată
nu este prezent local. Valoarea implicită este ~/.ssh/id_rsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 și ~/.ssh/id_ed25519_sk. Fișierele de identitate pot fi,
de asemenea, specificate pentru fiecare gazdă în fișierul de configurare. Este posibil să aveți
mai multe opțiuni -i (și mai multe identități specificate în fișierele de configurare). Dacă nu
au fost specificate în mod explicit certificate prin directiva CertificateFile, ssh va încerca,
de asemenea, să încarce informații privind certificatele din numele de fișier obținut prin
adăugarea -cert.pub la numele fișierelor de identitate.

-J destinație
Se conectează la gazda țintă realizând mai întâi o conexiune ssh la gazda de salt descrisă de
destinație și apoi stabilind de acolo o redirecționare TCP către destinația finală. Se pot
specifica mai multe gazde de salt separate prin virgule. Adresele IPv6 pot fi specificate prin
includerea adresei între paranteze drepte. Aceasta este o scurtătură pentru a specifica o
directivă de configurare ProxyJump. Rețineți că directivele de configurare furnizate în linia de
comandă se aplică în general gazdei de destinație și nu oricăror gazde de salt specificate.
Utilizați ~/.ssh/config pentru a specifica configurația pentru gazdele de salt.

-K Activează autentificarea bazată pe GSSAPI și transmiterea (delegarea) credențialelor GSSAPI către
server.

-k Dezactivează redirecționarea (delegarea) credențialelor GSSAPI către server.

-L [gazdă-asociere:]port:gazdă:port-gazdă
-L [adresă-asociere:]port:soclu-la-distanță
-L soclu-local:gazdă:port-gazdă
-L soclu-local:soclu-la-distanță
Specifică faptul că conexiunile către portul TCP sau către soclul Unix dat de pe gazda locală
(client) trebuie redirecționate către gazda și portul sau către soclul Unix dat de pe partea de
la distanță. Aceasta funcționează prin alocarea unui soclu pentru a asculta fie un port TCP
file ... pe partea locală, legat opțional la adresa adresă-asociere specificată, fie un soclu
Unix. Ori de câte ori se realizează o conexiune la portul sau soclul local, conexiunea este
transmisă pe canalul securizat și se realizează o conexiune fie la portul gazdă port-gazdă, fie
la soclul Unix soclu-la-distanță, de pe mașina de la distanță.

De asemenea, redirecționările de porturi pot fi specificate în fișierul de configurare. Numai
superutilizatorul poate redirecționa porturile privilegiate. Adresele IPv6 pot fi specificate
prin includerea adresei între paranteze drepte.

În mod implicit, portul local este legat în conformitate cu valoarea opțiunii GatewayPorts. Cu
toate acestea, se poate utiliza o adresă-de-asociere explicită pentru a lega conexiunea la o
anumită adresă. adresa-de-asociere de “gazdă-locală” indică faptul că portul de ascultare
trebuie legat numai pentru uz local, în timp ce o adresă goală sau ‘*’ indică faptul că portul
trebuie să fie disponibil de la toate interfețele.

-l nume_utilizator-autentificare
Specifică utilizatorul cu care trebuie să vă conectați pe mașina de la distanță. Acest lucru
poate fi, de asemenea, specificat pentru fiecare gazdă în fișierul de configurare.

-M Plasează clientul ssh în modul “master” pentru partajarea conexiunii. Mai multe opțiuni -M
plasează ssh în modul “master”, dar cu confirmarea necesară folosind ssh-askpass(1) înainte de
fiecare operație care modifică starea de multiplexare (de exemplu, deschiderea unei noi sesiuni).
Consultați descrierea ControlMaster în ssh_config(5) pentru detalii.

-m specificare-mac
O listă de algoritmi MAC (cod de autentificare a mesajelor) separați prin virgule, specificați în
ordinea preferințelor. Consultați cuvântul cheie MACs din ssh_config(5) pentru mai multe
informații.

-N Nu execută o comandă de la distanță. Acest lucru este util doar pentru redirecționarea
porturilor. Consultați descrierea SessionType în ssh_config(5) pentru detalii.

-n Redirecționează stdin de la /dev/null (de fapt, împiedică citirea din stdin). Acest lucru trebuie
utilizat atunci când ssh este rulat în fundal. Un truc comun este utilizarea acestuia pentru a
rula programe X11 pe o mașină la distanță. De exemplu, ssh -n shadows.cs.hut.fi emacs & va porni
un emacs pe shadows.cs.hut.fi, iar conexiunea X11 va fi transmisă automat pe un canal criptat.
Programul ssh va fi pus în fundal; (acest lucru nu funcționează dacă ssh trebuie să solicite o
parolă sau o frază de acces; a se vedea și opțiunea -f). Consultați descrierea StdinNull în
ssh_config(5) pentru detalii.

-O comandă-control
Controlează un proces master de multiplexare a conexiunii active. Atunci când este specificată
opțiunea -O, argumentul comandă-control este interpretat și transmis procesului master. Comenzile
valide sunt: “check” (verifică dacă procesul master rulează), “forward” (solicită redirecționări
fără executarea comenzii), “cancel” (anulează redirecționările), “proxy” (se conectează la un
master de multiplexare în funcțiune în modul proxy), “exit” (solicită masterului să iasă) și
“stop” (solicită masterului să nu mai accepte alte cereri de multiplexare).

-o opțiune
Poate fi utilizată pentru a oferi opțiuni în formatul utilizat în fișierul de configurare. Acest
lucru este util pentru specificarea opțiunilor pentru care nu există un fanion de linie de
comandă separat. Pentru detalii complete privind opțiunile enumerate mai jos și valorile lor
posibile, consultați ssh_config(5).

AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Comprimare
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation

-P etichetă
Specifică un nume de etichetă care poate fi utilizat pentru a selecta configurația în
ssh_config(5). Consultați cuvintele cheie Tag și Match din ssh_config(5) pentru mai multe
informații.
-p port
Portul de conectare la gazda de la distanță. Acesta poate fi specificat pentru fiecare gazdă în
parte în fișierul de configurare.

-Q opțiune-interogare
Interogări pentru algoritmii acceptați de una dintre următoarele caracteristici: cipher (cifrări
simetrice acceptate), cipher-auth (cifrări simetrice acceptate care acceptă criptarea
autentificată), help (termeni de interogare acceptați pentru utilizarea cu fanionul -Q), mac
(coduri de integritate a mesajelor acceptate), kex (algoritmi de schimb de chei), kex-gss
(algoritmi de schimb de chei GSSAPI), key (tipuri de chei), key-ca-sign (algoritmi de semnătură
CA valabili pentru certificate), key-cert (tipuri de chei de certificat), key-plain (tipuri de
chei fără certificat), key-sig (toate tipurile de chei și algoritmi de semnătură),
protocol-version (versiuni de protocol SSH acceptate) și sig (algoritmi de semnătură acceptați).
Alternativ, orice cuvânt-cheie din ssh_config(5) sau sshd_config(5) care acceptă o listă de
algoritmi poate fi utilizat ca alias pentru opțiunea opțiune-interogare corespunzătoare.

-q Mod silențios. Face ca majoritatea mesajelor de avertizare și diagnosticare să fie suprimate.

-R [gazdă-asociere:]port:gazdă:port-gazdă
-R [adresă-asociere:]port:soclu-local
-R soclu-la-distanță:gazdă:port-gazdă
-R soclu-la-distanță:soclu-local
-R [adresă-asociere:]port
Specifică faptul că conexiunile către portul TCP sau soclul Unix dat de pe gazda de la distanță
(server) trebuie transmise către partea locală.

Aceasta funcționează prin alocarea unui soclu pentru a asculta fie un port TCP, fie un soclu Unix
pe partea de la distanță. Ori de câte ori se realizează o conexiune la acest port sau soclu Unix,
conexiunea este redirecționată pe canalul securizat și se realizează o conexiune de la mașina
locală fie către o destinație explicită specificată de gazdă port port-gazdă, fie către
soclu-local sau, dacă nu a fost specificată nicio destinație explicită, ssh va acționa ca un
proxy SOCKS 4/5 și va redirecționa conexiunile către destinațiile solicitate de clientul SOCKS de
la distanță.

De asemenea, redirecționările de porturi pot fi specificate în fișierul de configurare. Porturile
privilegiate pot fi redirecționate numai atunci când vă conectați ca root pe mașina de la
distanță. Adresele IPv6 pot fi specificate prin includerea adresei între paranteze drepte.

În mod implicit, soclurile TCP de ascultare de pe server vor fi legate numai la interfața
loopback. Acest lucru poate fi anulat prin specificarea unei adrese adresă-asociere. O adresă
adresă-asociere goală, sau adresa ‘*’, indică faptul că soclul de la distanță trebuie să asculte
pe toate interfețele. Specificarea unei adrese adresă-asociere la distanță va reuși numai dacă
opțiunea GatewayPorts a serverului este activată (consultați sshd_config(5)).

Dacă argumentul port este ‘0’, portul de ascultare va fi alocat dinamic pe server și raportat
clientului la momentul rulării. Atunci când este utilizat împreună cu -O forward, portul alocat
va fi imprimat la ieșirea standard.

-S rută-control
Specifică locația unui soclu de control pentru partajarea conexiunii sau șirul “none” pentru a
dezactiva partajarea conexiunii. Consultați descrierea ControlPath și ControlMaster în
ssh_config(5) pentru detalii.

-s Poate fi utilizată pentru a solicita invocarea unui subsistem pe sistemul de la distanță.
Subsistemele facilitează utilizarea SSH ca transport securizat pentru alte aplicații (de exemplu,
sftp(1)). Subsistemul este specificat ca comandă la distanță. Consultați descrierea SessionType
în ssh_config(5) pentru detalii.

-T Dezactivează alocarea pseudo-terminalelor.

-t Forțează alocarea de pseudo-terminale. Aceasta poate fi utilizată pentru a executa programe
arbitrare bazate pe ecran pe o mașină la distanță, ceea ce poate fi foarte util, de exemplu, la
implementarea serviciilor de meniu. Opțiunile multiple -t forțează alocarea tty, chiar dacă ssh
nu are un tty local.

-V Afișează numărul versiunii, și iese.

-v Modul de informații detaliate. Determină ssh să afișeze mesaje de depanare cu privire la
progresul său. Acest lucru este util în depanarea problemelor de conectare, autentificare și
configurare. Opțiunile -v multiple măresc gradul de detaliere. Valoarea maximă este 3.

-W gazdă:port
Solicită ca intrarea și ieșirea standard de pe client să fie transmise către gazdă pe portul pe
canalul securizat. Implică -N, -T, ExitOnForwardFailure și ClearAllForwardings, deși acestea pot
fi anulate în fișierul de configurare sau utilizând opțiunile din linia de comandă -o.

-w tunel-local[:tunel-la_distanță]
Solicită redirecționarea dispozitivului tunel cu dispozitivele tun(4) specificate între clientul
(local_tun) și serverul (remote_tun).

Dispozitivele pot fi specificate prin ID numeric sau prin cuvântul-cheie “any”, care utilizează
următorul dispozitiv tunel disponibil. Dacă remote_tun nu este specificat, se utilizează în mod
implicit “any”. Consultați și directivele Tunnel și TunnelDevice din ssh_config(5).

Dacă directiva Tunnel nu este definită, acesta va fi stabilit la modul tunel implicit, care este
“point-to-point”. Dacă se dorește un alt mod de expediere Tunnel, atunci acesta trebuie
specificat înainte de -w.

-X Activează redirecționarea X11. Acest lucru poate fi, de asemenea, specificat pentru fiecare gazdă
într-un fișier de configurare.

Redirecționarea X11 trebuie să fie activată cu precauție. Utilizatorii care au capacitatea de a
ocoli permisiunile de fișier pe gazda de la distanță (pentru baza de date de autorizare X a
utilizatorului) pot accesa afișajul X11 local prin conexiunea redirecționată. Un atacator poate
fi capabil să efectueze activități precum monitorizarea apăsării tastelor.

Din acest motiv, redirecționarea X11 este supusă implicit restricțiilor extensiei X11 SECURITY.
Consultați opțiunea ssh -Y și directiva ForwardX11Trusted din ssh_config(5) pentru mai multe
informații.

(Specific Debian: Redirecționarea X11 nu este supusă implicit restricțiilor extensiei X11
SECURITY, deoarece prea multe programe se blochează în prezent în acest mod. Definiți opțiunea
ForwardX11Trusted la “no” pentru a restabili comportamentul din fluxul de dezvoltare. Acest lucru
se poate schimba în viitor în funcție de îmbunătățirile pe partea de client).

-x Dezactivează redirecționarea X11.

-Y Activează redirecționarea X11 de încredere. Redirecționările X11 de încredere nu sunt supuse
controalelor extensiei X11 SECURITY.

(Specific Debian: În configurația implicită, această opțiune este echivalentă cu -X, deoarece
ForwardX11Trusted are ca valoare implicită “yes” așa cum este descris mai sus. Definiți opțiunea
ForwardX11Trusted la “no” pentru a restabili comportamentul din fluxul de dezvoltare. Acest lucru
se poate schimba în viitor în funcție de îmbunătățirile pe partea de client).

-y Trimite informații de jurnal utilizând modulul de sistem syslog(3). În mod implicit, aceste
informații sunt trimise la ieșirea de eroare standard (stderr).

ssh poate obține în plus date de configurare dintr-un fișier de configurare pentru fiecare utilizator și
dintr-un fișier de configurare la nivelul întregului sistem. Formatul fișierului și opțiunile de
configurare sunt descrise în ssh_config(5).

AUTENTIFICARE

Clientul SSH OpenSSH acceptă protocolul SSH 2.

Metodele disponibile pentru autentificare sunt: GSSAPI-based authentication, host-based authentication,
public key authentication, keyboard-interactive authentication și password authentication. Metodele de
autentificare sunt încercate în ordinea specificată mai sus, deși PreferredAuthentications poate fi
utilizată pentru a schimba ordinea implicită.

Autentificarea bazată pe gazdă funcționează după cum urmează: Dacă mașina de pe care se conectează
utilizatorul este listată în /etc/hosts.equiv sau /etc/ssh/shosts.equiv pe mașina de la distanță,
utilizatorul este non-root și numele de utilizator sunt aceleași pe ambele părți, sau dacă fișierele ~/.
rhosts sau ~/.shosts există în directorul personal al utilizatorului de pe mașina la distanță și conțin o
linie care conține numele mașinii client și numele utilizatorului de pe acea mașină, utilizatorul este
luat în considerare pentru autentificare. În plus, serverul trebuie să poată verifica cheia de gazdă a
clientului (a se vedea descrierea /etc/ssh/ssh_known_hosts și ~/.ssh/known_hosts, mai jos) pentru a
permite autentificarea. Această metodă de autentificare închide găurile de securitate datorate
falsificării IP, DNS și de direcționare. [Notă pentru administrator: /etc/hosts.equiv, ~/.rhosts și
protocolul rlogin/rsh în general sunt inerent nesigure și ar trebui dezactivate dacă se dorește
securitate].

Autentificarea cu cheie publică funcționează după cum urmează: Sistemul se bazează pe criptografia cu
cheie publică, utilizând criptosisteme în care criptarea și decriptarea se realizează utilizând chei
separate, iar cheia de decriptare nu poate fi derivată din cheia de criptare. Ideea este că fiecare
utilizator creează o pereche de chei publice/private în scopul autentificării. Serverul cunoaște cheia
publică și numai utilizatorul cunoaște cheia privată. ssh implementează automat protocolul de
autentificare cu cheie publică, utilizând unul dintre algoritmii ECDSA, Ed25519 sau RSA.

Fișierul ~/.ssh/authorized_keys enumeră cheile publice care sunt permise pentru autentificare. Atunci
când utilizatorul se conectează, programul ssh indică serverului ce pereche de chei ar dori să utilizeze
pentru autentificare. Clientul dovedește că are acces la cheia privată, iar serverul verifică dacă cheia
publică corespunzătoare este autorizată să accepte contul.

Serverul poate informa clientul cu privire la erorile care au împiedicat autentificarea cu cheie publică
să reușească după ce autentificarea se încheie folosind o metodă diferită. Acestea pot fi vizualizate
prin creșterea LogLevel la DEBUG sau mai sus (de exemplu, prin utilizarea fanionului -v).

Utilizatorul își creează perechea de chei executând ssh-keygen(1). Aceasta stochează cheia privată în
~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (cheie ECDSA găzduită de un autentificator), ~/.
ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (cheie Ed25519 găzduită de un autentificator) sau
~/.ssh/id_rsa (RSA) și stochează cheia publică în ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub
(cheie ECDSA găzduită de un autentificator), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub
(cheie Ed25519 găzduită de un autentificator) sau ~/.ssh/id_rsa.pub (RSA) în directorul personal al
utilizatorului. Utilizatorul trebuie apoi să copieze cheia publică în ~/.ssh/authorized_keys în
directorul său personal de pe calculatorul de la distanță. Fișierul authorized_keys corespunde fișierului
convențional ~/.rhosts și are o cheie pe linie, deși liniile pot fi foarte lungi. După aceasta,
utilizatorul se poate conecta fără a da parola.

O variație a autentificării prin cheie publică este disponibilă sub forma autentificării prin certificat:
în loc de un set de chei publice/private, se utilizează certificate semnate. Aceasta are avantajul că o
singură autoritate de certificare de încredere poate fi utilizată în locul mai multor chei
publice/private. Consultați secțiunea CERTIFICATES din ssh-keygen(1) pentru mai multe informații.

Cel mai convenabil mod de a utiliza autentificarea prin cheie publică sau certificat poate fi cu ajutorul
unui agent de autentificare. Consultați ssh-agent(1) și (opțional) directiva AddKeysToAgent din
ssh_config(5) pentru mai multe informații.

Autentificarea interactivă prin tastatură funcționează după cum urmează: Serverul trimite un text
arbitrar "challenge" și solicită un răspuns, eventual de mai multe ori. Exemple de autentificare
interactivă prin tastatură includ autentificarea BSD (a se vedea login.conf(5)) și autentificarea PAM
(unele sisteme non-OpenBSD).

În cele din urmă, dacă alte metode de autentificare eșuează, ssh solicită utilizatorului o parolă. Parola
este trimisă la gazda de la distanță pentru verificare; cu toate acestea, deoarece toate comunicațiile
sunt criptate, parola nu poate fi văzută de cineva care ascultă pe rețea.

ssh menține și verifică automat o bază de date care conține datele de identificare pentru toate gazdele
cu care a fost utilizat vreodată. Cheile gazdelor sunt stocate în ~/.ssh/known_hosts în directorul
personal al utilizatorului. În plus, fișierul /etc/ssh/ssh_known_hosts este verificat automat pentru
gazdele cunoscute. Orice gazde noi sunt adăugate automat la fișierul utilizatorului. Dacă identificarea
unei gazde se modifică vreodată, ssh avertizează în acest sens și dezactivează autentificarea prin parolă
pentru a preveni falsificarea serverului sau atacurile man-in-the-middle (de intermediar), care ar putea
fi utilizate pentru a eluda criptarea. Opțiunea StrictHostKeyChecking poate fi utilizată pentru a
controla conectările la mașini a căror cheie de gazdă nu este cunoscută sau s-a schimbat.

Atunci când identitatea utilizatorului a fost acceptată de server, serverul fie execută comanda dată
într-o sesiune neinteractivă, fie, dacă nu a fost specificată nicio comandă, se conectează la mașină și
oferă utilizatorului un shell normal ca o sesiune interactivă. Toate comunicațiile cu comanda sau shell-
ul de la distanță vor fi criptate automat.

Dacă este solicitată o sesiune interactivă, ssh va solicita în mod implicit un pseudo-terminal (pty)
pentru sesiunile interactive numai atunci când clientul are unul. Fanioanele -T și -t pot fi utilizate
pentru a anula acest comportament.

Dacă a fost alocat un pseudo-terminal, utilizatorul poate folosi caracterele de control menționate mai
jos.

Dacă nu a fost alocat niciun pseudo-terminal, sesiunea este transparentă și poate fi utilizată pentru a
transfera în mod fiabil date binare. Pe majoritatea sistemelor, stabilirea caracterului de control la
“none” va face, de asemenea, sesiunea transparentă chiar dacă se utilizează un tty.

Sesiunea se încheie atunci când comanda sau shell-ul de pe calculatorul de la distanță se încheie și
toate conexiunile X11 și TCP au fost închise.

CARACTERE DE CONTROL

       Atunci  când  a  fost  solicitat  un pseudo-terminal, ssh acceptă o serie de funcții prin utilizarea unui
       caracter de control.

       Un singur caracter tilde poate fi trimis ca ~~ sau urmând tilda cu un alt caracter  decât  cele  descrise
       mai  jos.  Caracterul  de  control  trebuie să urmeze întotdeauna o linie nouă pentru a fi interpretat ca
       fiind special. Caracterul de control poate fi modificat în fișierele de configurare folosind directiva de
       configurare EscapeChar sau în linia de comandă prin opțiunea -e.

       Caracterele de control acceptate (presupunând ‘~’ implicit) sunt:

       ~.      Deconectare.

       ~^Z     Plasează în fundal .

       ~#      Listează conexiunile redirecționate.

       ~&      Plasează  în  fundal  ssh  la  deconectare  atunci  când  se   așteaptă   terminarea   conexiunii
               redirecționate / a sesiunilor X11.

       ~?      Afișează o listă de caractere de control.

       ~B      Trimite un BREAK către sistemul de la distanță (util numai dacă mașina respectivă îl acceptă).

       ~C      Deschide  linia  de  comandă.  În  prezent,  aceasta  permite adăugarea de redirecționări de port
               utilizând opțiunile  -L,  -R  și  -D  (a  se  vedea  mai  sus).  De  asemenea,  permite  anularea
               redirecționărilor    de    port    existente    cu    -KL[adresă-asociere:]port   pentru   local,
               -KR[adresă-asociere:]port pentru la distanță și -KD[adresă-asociere:]port  pentru  redirecționări
               de  port  dinamice.   !comandă  permite  utilizatorului să execute o comandă locală dacă opțiunea
               PermitLocalCommand este activată în ssh_config(5).   Ajutorul  basic  este  disponibil,  folosind
               opțiunea -h.

       ~R      Solicită  resigilarea (reverificarea cheilor de securitate) conexiunii (util numai dacă mașina de
               la distanță o acceptă).

       ~V      Reduce cantitatea de informații din mesaje (LogLevel) atunci când erorile sunt scrise la  ieșirea
               de eroare standard.

       ~v      Mărește cantitatea de informații din mesaje (LogLevel) atunci când erorile sunt scrise la ieșirea
               de eroare standard.

REDIRECȚIONARE TCP

       Redirecționarea  conexiunilor  TCP  arbitrare  pe un canal securizat poate fi specificată fie pe linia de
       comandă, fie într-un fișier de configurare. O posibilă aplicație a redirecționării TCP este  o  conexiune
       securizată la un server de poștă electronică; o alta este trecerea prin paravane de protecție.

       În  exemplul  de mai jos, analizăm criptarea comunicării pentru un client IRC, chiar dacă serverul IRC la
       care se conectează nu acceptă  direct  comunicarea  criptată.  Aceasta  funcționează  după  cum  urmează:
       utilizatorul  se  conectează la gazda de la distanță utilizând ssh, specificând porturile care urmează să
       fie utilizate pentru redirecționarea conexiunii. După aceea, este posibil să porniți programul local, iar
       ssh va cripta și va redirecționa conexiunea către serverul de la distanță.

       Următorul  exemplu  efectuează  tunelarea  unei  sesiuni  IRC  de  la  client  la  un   server   IRC   la
       “server.example.com”, intrând pe canalul “#users”, porecla “pinky”, folosind portul IRC standard, 6667:

           $ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
           $ irc -c '#users' pinky IRC/127.0.0.1

       Opțiunea  -f  pune  în fundal ssh și comanda de la distanță “sleep 10” este specificată pentru a acorda o
       anumită perioadă de timp (10 secunde, în exemplu) pentru a porni programul care va utiliza tunelul.  Dacă
       nu se realizează nicio conexiune în timpul specificat, ssh va ieși.

REDIRECȚIONARE X11

Dacă variabila ForwardX11 este definită la “yes” (sau consultați descrierea opțiunilor -X, -x și -Y de
mai sus) și utilizatorul utilizează X11 ( variabila de mediu DISPLAY este definită), conexiunea la
afișarea X11 este redirecționată automat către partea la distanță în așa fel încât orice program X11
pornit din shell (sau comandă) va trece prin canalul criptat, iar conexiunea la serverul X real se va
face de pe mașina locală. Utilizatorul nu trebuie să definească manual DISPLAY. Redirecționarea
conexiunilor X11 poate fi configurată în linia de comandă sau în fișierele de configurare.

Valoarea DISPLAY definită de ssh va indica mașina server, dar cu un număr de afișare mai mare decât zero.
Acest lucru este normal și se întâmplă deoarece ssh creează un server “proxy” X pe calculatorul
serverului pentru redirecționarea conexiunilor pe canalul criptat.

ssh va configura automat și datele Xauthority pe server. În acest scop, va genera un cookie de autorizare
aleatoriu, îl va stoca în Xauthority pe server și va verifica dacă orice conexiune redirecționată poartă
acest cookie și îl înlocuiește cu cookie-ul real atunci când conexiunea este deschisă. Cookie-ul real de
autentificare nu este trimis niciodată către server (și nu sunt trimise cookie-uri în clar).

Dacă variabila ForwardAgent este definită la “yes” (sau consultați descrierea opțiunilor -A și -a de mai
sus) și utilizatorul utilizează un agent de autentificare, conexiunea la agent este redirecționată
automat către partea la distanță.

VERIFICAREA CHEILOR GAZDEI

       Atunci când se conectează pentru prima dată la un server, utilizatorului i se prezintă o amprentă a cheii
       publice  a  serverului  (cu  excepția cazului în care opțiunea StrictHostKeyChecking a fost dezactivată).
       Amprentele digitale pot fi determinate utilizând ssh-keygen(1):

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

       Dacă amprenta digitală este deja cunoscută, aceasta poate fi comparată, iar cheia poate fi acceptată  sau
       respinsă.  În  cazul  în care sunt disponibile doar amprente digitale vechi (MD5) pentru server, opțiunea
       ssh-keygen(1) -E poate fi utilizată pentru  a  retrograda  algoritmul  amprentei  digitale  pentru  a  se
       potrivi.

       Din  cauza  dificultății  de  comparare  a  cheilor  de  gazdă doar prin examinarea șirurilor de amprente
       digitale, există și suport pentru compararea vizuală a cheilor de gazdă, utilizând desen grafic aleatoriu
       (random art).  Prin definirea opțiunii VisualHostKey la “yes”, un mic grafic ASCII este afișat la fiecare
       conectare la un server, indiferent dacă sesiunea în sine este interactivă sau nu. Învățând modelul produs
       de un server cunoscut, un utilizator poate descoperi cu ușurință că cheia de gazdă  s-a  schimbat  atunci
       când  este  afișat  un model complet diferit. Cu toate acestea, deoarece aceste modele nu sunt lipsite de
       ambiguitate, un model care arată similar cu modelul memorat oferă doar o bună probabilitate ca  cheia  de
       gazdă să fie aceeași, nu o dovadă garantată.

       Pentru  a  obține  o  listă  a amprentelor digitale împreună cu desenul lor grafic aleatoriu pentru toate
       gazdele cunoscute, poate fi utilizată următoarea linie de comandă:

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

       Dacă amprenta digitală este necunoscută, este disponibilă o metodă alternativă de verificare:  Amprentele
       digitale SSH verificate prin DNS. O înregistrare de resursă (RR) suplimentară, SSHFP, este adăugată la un
       fișier  de  zonă,  iar  clientul  care  se  conectează  poate  compara  amprenta  digitală cu cea a cheii
       prezentate.

       În acest exemplu, conectăm un client la un server, “host.example.com”.  Înregistrările  resurselor  SSHFP
       trebuie adăugate mai întâi la fișierul de zonă pentru host.example.com:

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

       Liniile de ieșire vor trebui să fie adăugate la fișierul de zonă. Pentru a verifica dacă zona răspunde la
       interogările privind amprentele digitale:

             $ dig -t SSHFP host.example.com

       În final, se conectează clientul:

             $ ssh -o "VerifyHostKeyDNS ask" host.example.com
             [...]
             Matching host key fingerprint found in DNS.
             Are you sure you want to continue connecting (yes/no)?

       A se vedea opțiunea VerifyHostKeyDNS din ssh_config(5) pentru mai multe informații.

REȚELE PRIVATE VIRTUALE BAZATE PE SSH

       ssh  conține suport pentru tuneluri de rețea privată virtuală (VPN) utilizând pseudodispozitivul de rețea
       tun(4),  permițând  conectarea  securizată  a  două  rețele.  Opțiunea  de   configurare   sshd_config(5)
       PermitTunnel controlează dacă serverul acceptă acest lucru și la ce nivel (trafic de nivel 2 sau 3).

       Următorul  exemplu ar conecta rețeaua client 10.0.50.0/24 cu rețeaua la distanță 10.0.99.0/24 utilizând o
       conexiune punct la punct de la 10.1.1.1 la 10.1.1.2, cu condiția ca serverul SSH care rulează  pe  poarta
       de acces către rețeaua la distanță, la 192.168.1.15, să permită acest lucru.

       Pe client:

             # ssh -f -w 0:1 192.168.1.15 true
             # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
             # route add 10.0.99.0/24 10.1.1.2

       Pe server:

             # ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
             # route add 10.0.50.0/24 10.1.1.1

       Accesul  clienților poate fi ajustat mai fin prin intermediul fișierului /root/.ssh/authorized_keys (a se
       vedea mai jos) și al opțiunii de server PermitRootLogin.  Următoarea  intrare  ar  permite  conexiuni  pe
       tun(4)  dispozitivul 1 de la utilizatorul “jane” și pe tun dispozitivul 2 de la utilizatorul “john”, dacă
       PermitRootLogin este definită la “forced-commands-only”:

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

       Deoarece o configurare bazată pe SSH implică o cantitate destul de mare de supraîncărcare, aceasta  poate
       fi  mai  potrivită  pentru configurații temporare, cum ar fi VPN-urile wireless. VPN-urile mai permanente
       sunt mai bine furnizate de instrumente precum ipsecctl(8) și isakmpd(8).

MEDIU

ssh va configura în mod normal următoarele variabile de mediu:

DISPLAY Variabila DISPLAY indică locația serverului X11. Aceasta este definită automat de
ssh pentru a indica o valoare de forma “hostname:n”, unde “hostname” indică gazda
unde rulează shell-ul, iar ‘n’ este un număr întreg ≥ 1. ssh utilizează această
valoare specială pentru a redirecționa conexiunile X11 pe canalul securizat. În mod
normal, utilizatorul nu ar trebui să definească explicit DISPLAY, deoarece acest
lucru va face conexiunea X11 nesigură (și va necesita ca utilizatorul să copieze
manual orice cookie de autorizare necesar).

HOME Stabilește ruta către directorul personal al utilizatorului.

LOGNAME Sinonim pentru USER; configurată pentru compatibilitate cu sistemele care
utilizează această variabilă.

MAIL Stabilește ruta către căsuța poștală a utilizatorului.

PATH Stabilită la PATH implicit, așa cum a fost specificată la compilarea .

SSH_ASKPASS Dacă ssh are nevoie de o frază de acces, acesta va citi fraza de acces de la
terminalul curent, dacă a fost rulat de la un terminal. Dacă ssh nu are asociat un
terminal, dar DISPLAY și SSH_ASKPASS sunt definite, acesta va executa programul
specificat de SSH_ASKPASS și va deschide o fereastră X11 pentru a citi fraza de
acces. Acest lucru este deosebit de util atunci când apelați ssh dintr-un script
.xsession sau un script similar; (rețineți că pe unele mașini poate fi necesar să
redirecționați intrarea din /dev/null pentru a face acest lucru să funcționeze).

SSH_ASKPASS_REQUIRE Permite un control suplimentar asupra utilizării unui program de solicitare a
parolei. Dacă această variabilă este definită la “never”, atunci ssh nu va încerca
niciodată să utilizeze unul. Dacă este definită la “prefer”, atunci ssh va prefera
să utilizeze programul de solicitare a parolei în locul TTY atunci când solicită
parole. În cele din urmă, dacă variabila este definită la “force”, atunci programul
askpass va fi utilizat pentru toate introducerile de parole, indiferent dacă este
definită DISPLAY.

SSH_AUTH_SOCK Identifică ruta unui soclu Unix-domain utilizat pentru a comunica cu agentul.

SSH_CONNECTION Identifică capetele conexiunii (client și server). Variabila conține patru valori
separate prin spațiu: adresa IP a clientului, numărul portului clientului, adresa
IP a serverului și numărul portului serverului.

SSH_ORIGINAL_COMMAND Această variabilă conține linia de comandă originală în cazul în care este
executată o comandă forțată. Aceasta poate fi utilizată pentru a extrage
argumentele originale.

SSH_TTY Aceasta este definită la numele tty-ului (ruta către dispozitiv) asociat cu shell-
ul sau comanda curentă. Dacă sesiunea curentă nu are tty, această variabilă nu este
definită.

SSH_TUNNEL Definită opțional de sshd(8) pentru a conține numele interfețelor atribuite dacă
clientul a solicitat redirecționarea tunelului.

SSH_USER_AUTH Definită opțional de sshd(8), această variabilă poate conține un nume de rută către
un fișier care enumeră metodele de autentificare utilizate cu succes atunci când a
fost stabilită sesiunea, inclusiv orice chei publice care au fost utilizate.

TZ Această variabilă este definită pentru a indica fusul orar actual dacă a fost
definită la pornirea demonului (adică demonul transmite valoarea noilor conexiuni).

USER Stabilește numele utilizatorului care se conectează.

În plus, ssh citește ~/.ssh/environment și adaugă linii de format “NUME_VARIABILĂ=valoare” la mediu dacă
fișierul există și utilizatorii au permisiunea de a-și modifica mediul. Pentru mai multe informații,
consultați opțiunea PermitUserEnvironment din sshd_config(5).

FIȘIERE

~/.rhosts
Acest fișier este utilizat pentru autentificarea bazată pe gazdă (a se vedea mai sus). Pe unele
mașini, este posibil ca acest fișier să trebuiască să poată fi citit de toată lumea dacă
directorul personal al utilizatorului este pe o partiție NFS, deoarece sshd(8) îl citește ca
root. În plus, acest fișier trebuie să fie deținut de utilizator și nu trebuie să aibă permisiuni
de scriere pentru nimeni altcineva. Permisiunea recomandată pentru majoritatea mașinilor este de
citire/scriere pentru utilizator și neaccesibilă pentru alții.

~/.shosts
Acest fișier este utilizat exact în același mod ca .rhosts, dar permite autentificarea bazată pe
gazdă fără a permite autentificarea cu rlogin/rsh.

~/.ssh/
Acest director este locația implicită pentru toate informațiile de configurare și autentificare
specifice utilizatorului. Nu există nicio cerință generală de a păstra secret întregul conținut
al acestui director, dar permisiunile recomandate sunt de citire/scriere/executare pentru
utilizator și neaccesibil pentru alții.

~/.ssh/authorized_keys
Listează cheile publice (ECDSA, Ed25519, RSA) care pot fi utilizate pentru conectarea ca acest
utilizator. Formatul acestui fișier este descris în pagina de manual sshd(8). Acest fișier nu
este foarte sensibil, dar permisiunile recomandate sunt de citire/scriere pentru utilizator și
neaccesibil pentru alții.

~/.ssh/config
Acesta este fișierul de configurare per utilizator. Formatul fișierului și opțiunile de
configurare sunt descrise în ssh_config(5). Din cauza potențialului de abuz, acest fișier
trebuie să aibă permisiuni stricte: citire/scriere pentru utilizator și nu poate fi scris de
alții. Acesta poate fi scris de grup, cu condiția ca grupul în cauză să conțină doar
utilizatorul.

~/.ssh/environment
Conține definiții suplimentare pentru variabilele de mediu; a se vedea “MEDIU”, mai sus.

~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Conține cheia privată pentru autentificare. Aceste fișiere conțin date sensibile și trebuie să
poată fi citite de utilizator, dar să nu fie accesibile pentru alții (citire/scriere/executare).
ssh va ignora pur și simplu un fișier de cheie privată dacă acesta este accesibil pentru alții.
Este posibil să se specifice o frază de acces la generarea cheii care va fi utilizată pentru a
cripta partea sensibilă a acestui fișier utilizând AES-128.

~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Conține cheia publică pentru autentificare. Aceste fișiere nu sunt sensibile și pot (dar nu
trebuie) să fie citite de oricine.

~/.ssh/known_hosts
Conține o listă de chei de gazdă pentru toate gazdele la care utilizatorul s-a autentificat și
care nu sunt deja în lista de chei de gazdă cunoscute la nivel de sistem. Consultați sshd(8)
pentru detalii suplimentare privind formatul acestui fișier.

~/.ssh/rc
Comenzile din acest fișier sunt executate de ssh atunci când utilizatorul se autentifică, chiar
înainte ca shell-ul (sau comanda) utilizatorului să fie pornit. Consultați pagina de manual
sshd(8) pentru mai multe informații.

/etc/hosts.equiv
Acest fișier este pentru autentificarea bazată pe gazdă (a se vedea mai sus). Ar trebui să poată
fi scris numai de către root.

/etc/ssh/shosts.equiv
Acest fișier este utilizat exact în același mod ca hosts.equiv, dar permite autentificarea pe
bază de gazdă fără a permite autentificarea cu rlogin/rsh.

/etc/ssh/ssh_config
Fișier de configurare la nivel de sistem. Formatul fișierului și opțiunile de configurare sunt
descrise în ssh_config(5).

/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
Aceste fișiere conțin părțile private ale cheilor de gazdă și sunt utilizate pentru
autentificarea bazată pe gazdă.

/etc/ssh/ssh_known_hosts
Lista la nivel de sistem a cheilor de gazdă cunoscute. Acest fișier ar trebui să fie pregătit de
administratorul sistemului pentru a conține cheile publice de gazdă ale tuturor mașinilor din
organizație. Acesta trebuie să poată fi citit de toată lumea. Consultați sshd(8) pentru detalii
suplimentare privind formatul acestui fișier.

/etc/ssh/sshrc
Comenzile din acest fișier sunt executate de ssh atunci când utilizatorul se autentifică, chiar
înainte ca shell-ul (sau comanda) utilizatorului să fie pornit. Consultați pagina de manual
sshd(8) pentru mai multe informații.

STARE DE IEȘIRE

       ssh iese cu starea de ieșire a comenzii de la distanță sau cu 255 dacă a apărut o eroare.

CONSULTAȚI ȘI

       scp(1),   sftp(1),   ssh-add(1),   ssh-agent(1),  ssh-argv0(1),  ssh-keygen(1),  ssh-keyscan(1),  tun(4),
       ssh_config(5), ssh-keysign(8), sshd(8)

STANDARDE

S. Lehtinen and C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, ianuarie 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, ianuarie 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, ianuarie 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, ianuarie 2006.

T. Ylonen and C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, ianuarie 2006.

J. Schlyter and W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255,
ianuarie 2006.

F. Cusack and M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH),
RFC 4256, ianuarie 2006.

J. Galbraith and P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, ianuarie
2006.

M. Bellare, T. Kohno, and C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC
4344, ianuarie 2006.

B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, ianuarie
2006.

M. Friedl, N. Provos, and W. Simpson, Schimb de grupuri Diffie-Hellman pentru protocolul de transport
Secure Shell (SSH), RFC 4419, martie 2006.

J. Galbraith and R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, noiembrie 2006.

D. Stebila and J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC
5656, decembrie 2009.

A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999,
International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99).

AUTORI

       OpenSSH  este  un derivat al versiunii originale și libere ssh 1.2.12 de Tatu Ylonen. Aaron Campbell, Bob
       Beck, Markus Friedl, Niels Provos, Theo de Raadt și Dug Song au eliminat multe erori, au adăugat din  nou
       caracteristici  noi  și au creat OpenSSH. Markus Friedl a contribuit la suportul pentru versiunile 1.5 și
       2.0 ale protocolului SSH.

TRADUCERE

       Traducerea   în   limba   română   a   acestui   manual   a   fost   făcută   de   Remus-Gabriel    Chelu
       <remusgabriel.chelu@disroot.org>

       Această  traducere  este  documentație  gratuită;  citiți  Licența  publică  generală  GNU  Versiunea  3:
       https://www.gnu.org/licenses/gpl-3.0.html sau o  versiune  ulterioară  cu  privire  la  condiții  privind
       drepturile de autor.  NU se asumă NICIO RESPONSABILITATE.

       Dacă   găsiți   erori   în   traducerea   acestui   manual,   vă   rugăm   să   trimiteți  un  e-mail  la
       translation-team-ro@lists.sourceforge.net .

Debian                                          4 decembrie, 2024                                         SSH(1)