Scroll to navigation

SSH(1) General Commands Manual SSH(1)

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:

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

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

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).

Dezactivează redirecționarea conexiunii agentului de autentificare.

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.

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

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).

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.

[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.

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

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ă.

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.

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.

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

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.

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.

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.

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.

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

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

[gazdă-asociere:]port:gazdă:port-gazdă
 
[adresă-asociere:]port:soclu-la-distanță
 
soclu-local:gazdă:port-gazdă
 
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.

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.

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.

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.

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.

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.

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).

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
 
CanonicalDomains
 
CanonicalizeFallbackLocal
 
CanonicalizeHostname
 
CanonicalizeMaxDots
 
CanonicalizePermittedCNAMEs
 
CASignatureAlgorithms
 
CertificateFile
 
CheckHostIP
 
Ciphers
 
ClearAllForwardings
 
Comprimare
 
ConnectionAttempts
 
ConnectTimeout
 
ControlMaster
 
ControlPath
 
ControlPersist
 
DynamicForward
 
EnableEscapeCommandline
 
EscapeChar
 
ExitOnForwardFailure
 
FingerprintHash
 
ForkAfterAuthentication
 
ForwardAgent
 
ForwardX11
 
ForwardX11Timeout
 
ForwardX11Trusted
 
GatewayPorts
 
GlobalKnownHostsFile
 
GSSAPIAuthentication
 
GSSAPIKeyExchange
 
GSSAPIClientIdentity
 
GSSAPIDelegateCredentials
 
GSSAPIKexAlgorithms
 
GSSAPIRenewalForcesRekey
 
GSSAPIServerIdentity
 
GSSAPITrustDns
 
HashKnownHosts
 
Host
 
HostbasedAcceptedAlgorithms
 
HostbasedAuthentication
 
HostKeyAlgorithms
 
HostKeyAlias
 
Hostname
 
IdentitiesOnly
 
IdentityAgent
 
IdentityFile
 
IPQoS
 
KbdInteractiveAuthentication
 
KbdInteractiveDevices
 
KexAlgorithms
 
KnownHostsCommand
 
LocalCommand
 
LocalForward
 
LogLevel
 
MACs
 
Match
 
NoHostAuthenticationForLocalhost
 
NumberOfPasswordPrompts
 
PasswordAuthentication
 
PermitLocalCommand
 
PermitRemoteOpen
 
PKCS11Provider
 
Port
 
PreferredAuthentications
 
ProxyCommand
 
ProxyJump
 
ProxyUseFdpass
 
PubkeyAcceptedAlgorithms
 
PubkeyAuthentication
 
RekeyLimit
 
RemoteCommand
 
RemoteForward
 
RequestTTY
 
RequiredRSASize
 
SendEnv
 
ServerAliveInterval
 
ServerAliveCountMax
 
SessionType
 
SetEnv
 
StdinNull
 
StreamLocalBindMask
 
StreamLocalBindUnlink
 
StrictHostKeyChecking
 
TCPKeepAlive
 
Tunnel
 
TunnelDevice
 
UpdateHostKeys
 
User
 
UserKnownHostsFile
 
VerifyHostKeyDNS
 
VisualHostKey
 
XAuthLocation
 

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.
port
Portul de conectare la gazda de la distanță. Acesta poate fi specificat pentru fiecare gazdă în parte în fișierul de configurare.

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.

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

[gazdă-asociere:]port:gazdă:port-gazdă
 
[adresă-asociere:]port:soclu-local
 
soclu-la-distanță:gazdă:port-gazdă
 
soclu-la-distanță:soclu-local
 
[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.

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.

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.

Dezactivează alocarea pseudo-terminalelor.

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.

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

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.

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.

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.

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).

Dezactivează redirecționarea X11.

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).

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 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.
Plasează în fundal ssh.
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.
Trimite un BREAK către sistemul de la distanță (util numai dacă mașina respectivă îl acceptă).
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.
Solicită resigilarea (reverificarea cheilor de securitate) conexiunii (util numai dacă mașina de la distanță o acceptă).
Reduce cantitatea de informații din mesaje (LogLevel) atunci când erorile sunt scrise la ieșirea de eroare standard.
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 . 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:

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).
Stabilește ruta către directorul personal al utilizatorului.
Sinonim pentru USER; configurată pentru compatibilitate cu sistemele care utilizează această variabilă.
Stabilește ruta către căsuța poștală a utilizatorului.
Stabilită la PATH implicit, așa cum a fost specificată la compilarea ssh.
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).
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.
Identifică ruta unui soclu UNIX-domain utilizat pentru a comunica cu agentul.
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.
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.
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ă.
Definită opțional de sshd(8) pentru a conține numele interfețelor atribuite dacă clientul a solicitat redirecționarea tunelului.
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.
Această variabilă este definită pentru a indica fusul orar actual dacă a fost definită la pornirea demonului (adică demonul transmite valoarea noilor conexiuni).
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 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

$Mdocdate: 18 iulie 2024 $ Debian