| SSHD(8) | System Manager's Manual | SSHD(8) |
sshd — Demonul
OpenSSH
sshd
[-46DdeGiqTtV]
[-C specificare-conectare]
[-c fișier-certificat-gazdă]
[-E fișier-jurnal]
[-f fișier-configurare]
[-g timp-de-grație-autentificare]
[-h fișier-cheie-gazdă]
[-o opțiune]
[-p port]
[-u lungime]
sshd (Demonul OpenSSH) este programul
demon pentru ssh(1). Acesta oferă
comunicații criptate sigure între două gazde
„neîncrezătoare” printr-o rețea
nesigură.
sshd ascultă conexiunile de la
clienți. În mod normal, este inițiat la pornire din
/etc/init.d/ssh. Acesta creează un nou demon
pentru fiecare conexiune primită. Demonii bifurcați
gestionează schimbul de chei, criptarea, autentificarea, executarea
comenzilor și schimbul de date.
sshd poate fi configurat folosind
opțiuni din linia de comandă sau un fișier de
configurare (implicit sshd_config(5)); opțiunile
din linia de comandă prevalează asupra valorilor specificate
în fișierul de configurare. sshd
își recitește fișierul de configurare atunci
când primește un semnal de întrerupere,
SIGHUP, executându-se cu numele și
opțiunile cu care a fost pornit, de exemplu
/usr/sbin/sshd.
Opțiunile sunt următoarele:
-4sshd să utilizeze
numai adrese IPv4.-6sshd să utilizeze
numai adrese IPv6.-C
specificare-conectare-T. Dacă sunt furnizate, orice directive
Match din fișierul de configurare care s-ar
aplica sunt aplicate înainte ca configurația să fie
scrisă la ieșirea standard. Parametrii conexiunii sunt
furnizați ca perechi cuvânt cheie=valoare și pot fi
furnizați în orice ordine, fie cu mai multe opțiuni
-C, fie ca o listă separată prin
virgule. Cuvintele-cheie sunt “addr”, “user”,
“host”, “laddr”, “lport”
și “rdomain” și corespund adresei
sursă, utilizatorului, numelui gazdei sursă rezolvate,
adresei locale, numărului portului local și, respectiv,
domeniului de rutare. În plus, fanionul
“invalid-user” (care nu are un argument de valoare) poate fi
specificat pentru a simula o conexiune de la un nume de utilizator
nerecunoscut.-c
fișier-certificat-gazdăsshd în timpul
schimbului de chei. Fișierul de certificat trebuie să
corespundă unui fișier de cheie gazdă specificat cu
ajutorul opțiunii -h sau al directivei de
configurare HostKey.-Dsshd nu se va detașa și nu va deveni
un demon. Acest lucru permite monitorizarea ușoară a
sshd.-d-d
măresc nivelul de depanare. Maximul este 3.-E
fișier-jurnal-e-f
fișier-configuraresshd refuză să pornească
dacă nu există niciun fișier de configurare.-GMatch pot fi
aplicate prin specificarea parametrilor de conexiune folosind una sau mai
multe opțiuni -C.-g
timp-de-grație-autentificare-h
fișier-cheie-gazdăsshd nu este rulat ca root (deoarece
fișierele de chei de gazdă normale nu pot fi citite
decât de root). Valoarea implicită este
/etc/ssh/ssh_host_ecdsa_key,
/etc/ssh/ssh_host_ed25519_key și
/etc/ssh/ssh_host_rsa_key. Este posibil să
aveți mai multe fișiere de chei de gazdă pentru
diferiți algoritmi de chei de gazdă.-isshd este rulat
din inetd(8).-o
opțiune-p
portPort sunt ignorate atunci când este
specificat un port în linia de comandă. Porturile
specificate cu ajutorul opțiunii
ListenAddress prevalează asupra porturilor
din linia de comandă.-q-TMatch pot fi aplicate
prin specificarea parametrilor conexiunii folosind una sau mai multe
opțiuni -C. Aceasta este similară cu
opțiunea -G, dar include testarea
suplimentară efectuată de opțiunea
-t.-tsshd, deoarece
opțiunile de configurare se pot schimba.-u
lungime-u0 indică faptul
că în fișierul utmp ar trebui
introduse numai adrese zecimale punctate. -u0
poate fi utilizat și pentru a împiedica
sshd să efectueze cereri DNS, cu
excepția cazului în care mecanismul de autentificare sau
configurația o solicită. Mecanismele de autentificare care
pot necesita DNS includ HostbasedAuthentication
și utilizarea unei opțiuni
from="listă-modele"
într-un fișier cheie. Opțiunile de configurare care
necesită DNS includ utilizarea unui model UTILIZATOR@GAZDĂ
în AllowUsers sau
DenyUsers.-VDemonul SSH OpenSSH acceptă numai protocolul SSH 2. Fiecare gazdă are o cheie specifică gazdei, utilizată pentru identificarea gazdei. Ori de câte ori un client se conectează, demonul răspunde cu cheia sa publică de gazdă. Clientul compară cheia gazdei cu propria sa bază de date pentru a verifica dacă aceasta nu s-a modificat. Secretul de transmitere este asigurat prin intermediul unui acord de chei Diffie-Hellman. Acest acord de chei are ca rezultat o cheie de sesiune partajată. Restul sesiunii este criptat utilizând un cifru simetric. Clientul selectează algoritmul de criptare de utilizat dintre cele oferite de server. În plus, integritatea sesiunii este asigurată printr-un cod criptografic de autentificare a mesajului („Message Authentication Code”: MAC).
În final, serverul și clientul intră într-un dialog de autentificare. Clientul încearcă să se autentifice folosind autentificarea bazată pe gazdă, autentificarea prin cheie publică, autentificarea prin provocare-răspuns sau autentificarea prin parolă.
Indiferent de tipul de autentificare, contul este verificat pentru
a se asigura că este accesibil. Un cont nu este accesibil dacă
este blocat, listat în DenyUsers sau grupul
său este listat în DenyGroups .
Definiția unui cont blocat depinde de sistem. Unele platforme au
propria bază de date a conturilor (de exemplu AIX), iar altele
modifică câmpul passwd (
‘*LK*’ pe Solaris și UnixWare,
‘*’ pe HP-UX, conținând
‘Nologin’ pe Tru64, un
‘*LOCKED*’ pe FreeBSD și un
‘!’ pe majoritatea Linux-urilor).
Dacă există o cerință de a dezactiva
autentificarea prin parolă pentru cont, permițând
în același timp utilizarea cheii publice, atunci câmpul
passwd trebuie să fie definit la altceva decât aceste valori
(de exemplu ‘NP’ sau
‘*NP*’).
Dacă clientul se autentifică cu succes, se deschide un dialog pentru pregătirea sesiunii. În acest moment, clientul poate solicita lucruri precum alocarea unui pseudo-tty, redirecționarea conexiunilor X11, redirecționarea conexiunilor TCP sau redirecționarea conexiunii agentului de autentificare pe canalul securizat.
După aceasta, clientul solicită fie un shell
interactiv, fie executarea unei comenzi non-interactive, pe care
sshd o va executa prin intermediul shell-ului
utilizatorului folosind opțiunea -c. Cele
două părți intră apoi în modul sesiune.
În acest mod, fiecare parte poate trimite date în orice
moment, iar aceste date sunt transmise către/de la shell sau
comandă pe partea serverului și de la terminalul
utilizatorului pe partea clientului.
Atunci când programul utilizatorului se încheie și toate conexiunile X11 transmise și alte conexiuni au fost închise, serverul trimite starea de ieșire a comenzii către client și ambele părți ies.
Atunci când un utilizator se autentifică cu succes,
sshd face următoarele:
PermitUserEnvironment din
sshd_config(5).PermitUserRC este definită, îl
execută; altfel, dacă /etc/ssh/sshrc
există, îl execută; altfel, execută
xauth(1). Fișierele “rc” primesc
protocolul de autentificare X11 și cookie-ul în intrarea
standard. A se vedea SSHRC, mai jos.Dacă fișierul ~/.ssh/rc
există, sh(1) îl execută după
citirea fișierelor de mediu, dar înainte de a porni shell-ul
sau comanda utilizatorului. Acesta nu trebuie să producă
niciun rezultat la ieșirea standard (stdout); în schimb,
trebuie utilizată ieșirea de erori standard (stderr).
Dacă este utilizată redirecționarea X11, acesta va
primi perechea „proto cookie” în intrarea sa standard
(și DISPLAY în mediul său).
Scriptul trebuie să apeleze xauth(1) deoarece
sshd nu va rula xauth automat pentru a adăuga
cookie-uri X11.
Scopul principal al acestui fișier este de a rula orice rutine de inițializare care pot fi necesare înainte ca directorul personal al utilizatorului să devină accesibil; AFS este un exemplu particular al unui astfel de mediu.
Acest fișier va conține probabil un cod de inițializare urmat de ceva similar cu:
if read proto cookie && [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | xauth -q - fi
Dacă acest fișier nu există, se execută /etc/ssh/sshrc, iar dacă nici acesta nu există, se utilizează xauth pentru a adăuga cookie-ul.
AuthorizedKeysFile specifică
fișierele care conțin cheile publice pentru autentificarea cu
cheie publică; dacă această opțiune nu este
specificată, valoarea implicită este
~/.ssh/authorized_keys și
~/.ssh/authorized_keys2. Fiecare linie a
fișierului conține o cheie (liniile goale și liniile
care încep cu un ‘#’ sunt
ignorate ca comentarii). Cheile publice sunt formate din următoarele
câmpuri separate prin spații: opțiuni, tipul cheii,
cheia codificată în baza64, comentariu. Câmpul
opțiuni este opțional. Tipurile de chei acceptate sunt:
Câmpul de comentarii nu este utilizat pentru nimic (dar poate fi convenabil pentru utilizator să identifice cheia).
Rețineți că liniile din acest fișier pot fi lungi de câteva sute de octeți (din cauza dimensiunii codificării cheii publice) până la o limită de 8 kiloocteți, ceea ce permite chei RSA de până la 16 kilobiți. Nu doriți să le introduceți; în schimb, copiați fișierul id_ecdsa.pub, id_ecdsa_sk.pub, id_ed25519.pub, id_ed25519_sk.pub sau id_rsa.pub și editați-l.
sshd impune o dimensiune minimă a
modulului cheii RSA de 1024 biți.
Opțiunile (dacă sunt prezente) constau în specificații de opțiuni separate prin virgule. Nu sunt permise spațiile, cu excepția celor între ghilimele duble. Sunt acceptate următoarele specificații ale opțiunilor (a se observa că cuvintele cheie ale opțiunilor nu țin cont de majuscule și minuscule):
agent-forwardingrestrict.Certificatele pot codifica restricții de acces similare cu aceste opțiuni ale cheii. În cazul în care sunt prezente atât restricții ale certificatului, cât și opțiuni ale cheii, se aplică cea mai restrictivă combinație dintre cele două.
command="comanda"no-pty. Un citat poate fi inclus
în comandă prin citarea sa cu o bară inversă.
Această opțiune poate fi utilă pentru a
restricționa anumite chei publice pentru a efectua doar o
anumită operație. Un exemplu ar putea fi o cheie care
permite salvări de la distanță, dar nimic altceva.
Rețineți că clientul poate specifica
redirecționarea TCP și/sau X11, cu excepția cazului
în care acestea sunt interzise în mod explicit, de exemplu
folosind opțiunea de cheie restrict.
Comanda furnizată inițial de client este
disponibilă în variabila de mediu
SSH_ORIGINAL_COMMAND. Rețineți
că această opțiune se aplică
executării shell-ului, comenzii sau subsistemului. De asemenea,
rețineți că această comandă poate fi
înlocuită de o directivă
sshd_config(5)
ForceCommand.
Dacă este specificată o comandă și o comandă forțată este încorporată într-un certificat utilizat pentru autentificare, atunci certificatul va fi acceptat numai dacă cele două comenzi sunt identice.
environment="NUME=valoare"PermitUserEnvironment.expiry-time="specificare-timp"from="listă-modele"În plus față de potrivirea de tip
caracter joker care poate fi aplicată numelor de gazdă sau
adreselor, o secțiune from poate potrivi
adresele IP utilizând notația CIDR
adresă/masklen.
Scopul acestei opțiuni este de a spori opțional securitatea: autentificarea cu cheie publică în sine nu are încredere în rețea sau în serverele de nume sau în nimic altceva (în afară de cheie); cu toate acestea, dacă cineva fură cumva cheia, cheia permite unui intrus să se conecteze de oriunde din lume. Această opțiune suplimentară face ca utilizarea unei chei furate să fie mai dificilă (serverele de nume și/sau router-ele ar trebui să fie compromise în plus față de cheie).
no-agent-forwardingno-port-forwardingcommand.no-ptyno-user-rcno-X11-forwardingpermitlisten="[gazdă:]port"-R astfel încât să
poată asculta numai pe gazda (opțional) și portul
specificate. Adresele IPv6 pot fi specificate prin includerea adresei
între paranteze drepte. Pot fi aplicate mai multe opțiuni
permitlisten separate prin virgule. Numele de
gazdă pot include caractere joker, astfel cum sunt descrise
în secțiunea MODELE din ssh_config(5). O
specificație de port * se potrivește
oricărui port. Rețineți că opțiunea
GatewayPorts poate restricționa și
mai mult adresele de ascultare. Rețineți că
ssh(1) va trimite un nume de gazdă
“localhost” dacă nu a fost specificată o
gazdă de ascultare atunci când a fost solicitată
redirecționarea și că acest nume este tratat diferit
față de adresele explicite de gazdă locală
“127.0.0.1” și “::1”.permitopen="gazdă:port"-L astfel
încât să se poată conecta numai la gazda
și portul specificate. Adresele IPv6 pot fi specificate prin
includerea adresei între paranteze drepte. Pot fi aplicate mai
multe opțiuni permitopen separate prin
virgule. Nu se efectuează nicio potrivire de model sau
căutare de nume pe numele de gazdă specificate, acestea
trebuie să fie nume de gazdă și/sau adrese literale.
O specificație de port * se
potrivește oricărui port.port-forwardingrestrict.principals="principale"cert-authority, specifică
principalii „principals” permise pentru autentificarea
certificatului sub forma unei liste separate prin virgule. Cel
puțin un nume din listă trebuie să apară
în lista de principali a certificatului pentru ca certificatul
să fie acceptat. Această opțiune este ignorată
pentru cheile care nu sunt marcate ca semnatari de certificate de
încredere utilizând opțiunea
cert-authority.ptyrestrict.no-touch-requiredecdsa-sk și
ed25519-sk.verify-requiredecdsa-sk și
ed25519-sk.restricttunnel="n"user-rcrestrict.X11-forwardingrestrict.Un exemplu de fișier authorized_keys:
# Comentariile sunt permise la începutul liniei. Sunt permise liniile goale. # Cheie simplă, fără restricții ssh-rsa ... # Comandă forțată, dezactivează PTY și toate redirecționările restrict,command="dump /home" ssh-rsa ... # Restricționarea destinațiilor de redirecționare ssh -L permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa ... # Restricționarea ascultătorilor ssh -R forwarding permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa ... # Configurație pentru redirecționarea prin tunel tunnel="0",command="sh /etc/netstart tun0" ssh-rsa ... # Anularea restricției pentru a permite alocarea PTY restrict,pty,command="nethack" ssh-rsa ... # Permite utilizarea cheii FIDO fără a fi necesară interacționarea cu utilizatorul no-touch-required sk-ecdsa-sha2-nistp256@openssh.com ... # Solicită verificarea utilizatorului (de exemplu, PIN sau biometric) # pentru cheia FIDO verify-required sk-ecdsa-sha2-nistp256@openssh.com ... # Cheie CA de încredere, permite FIDO fără interacționarea cu utilizatorul dacă # este solicitat în certificat cert-authority,no-touch-required,principals="user_a" ssh-rsa ...
Fișierele /etc/ssh/ssh_known_hosts și ~/.ssh/known_hosts conțin cheile publice ale gazdelor pentru toate gazdele cunoscute. Fișierul global trebuie pregătit de administrator (opțional), iar fișierul per utilizator este menținut automat: ori de câte ori utilizatorul se conectează la o gazdă necunoscută, cheia acesteia este adăugată la fișierul per utilizator.
Fiecare linie din aceste fișiere conține următoarele câmpuri: marcaj (opțional), nume de gazdă, tip de cheie, cheie codificată în baza 64, comentariu. Câmpurile sunt separate prin spații.
Marcajul este opțional, dar dacă este prezent, atunci trebuie să fie unul dintre “@cert-authority”, pentru a indica faptul că linia conține o cheie de autoritate de certificare (CA), sau “@revoked”, pentru a indica faptul că cheia conținută pe linie este revocată și nu trebuie acceptată niciodată. Pe o linie de cheie trebuie utilizat un singur marcaj.
Numele de gazde este o listă de modele separate prin
virgule (‘*’ și
‘?’ acționează ca
jokeri); fiecare model în parte este comparat cu numele de
gazdă. Atunci când sshd
autentifică un client, cum ar fi atunci când utilizează
HostbasedAuthentication, acesta va fi numele canonic
al gazdei clientului. Atunci când ssh(1)
autentifică un server, acesta va fi numele de gazdă dat de
utilizator, valoarea ssh(1)
HostkeyAlias dacă a fost specificată,
sau numele de gazdă canonic al serverului dacă a fost
utilizată opțiunea ssh(1)
CanonicalizeHostname.
Un model poate fi, de asemenea, precedat de
‘!’ pentru a indica negarea:
dacă numele de gazdă se potrivește cu un model negat,
acesta nu este acceptat (de linia respectivă) chiar dacă se
potrivește cu un alt model de pe linie. Un nume de gazdă sau o
adresă poate fi inclusă opțional între
parantezele ‘[’ și
‘]’, urmate apoi de
‘:’ și un număr de port
nestandard.
Alternativ, numele de gazde pot fi stocate într-o format de
sumă de control care ascunde numele de gazde și adresele
în cazul în care conținutul fișierului ar fi
divulgat. Numele de gazde în format de sumă de control
încep cu un caracter ‘|’. Un
singur nume de gazdă în format de sumă de control poate
apărea pe o singură linie și nu poate fi aplicat
niciunul dintre operatorii de negare sau de caractere joker de mai sus.
Tipul de cheie și cheia codificată în baza64 sunt preluate direct din cheia gazdei; acestea pot fi obținute, de exemplu, din /etc/ssh/ssh_host_rsa_key.pub. Câmpul de comentariu opțional continuă până la sfârșitul liniei și nu este utilizat.
Liniile care încep cu
‘#’ și liniile goale sunt
ignorate ca comentarii.
Atunci când se efectuează autentificarea gazdei, autentificarea este acceptată dacă orice linie corespunzătoare are cheia corespunzătoare; fie una care corespunde exact, fie, dacă serverul a prezentat un certificat pentru autentificare, cheia autorității de certificare care a semnat certificatul. Pentru ca o cheie să fie de încredere ca autoritate de certificare, aceasta trebuie să utilizeze marcajul “@cert-authority” descris mai sus.
Fișierul de gazde cunoscute oferă, de asemenea, posibilitatea de a marca cheile ca fiind revocate, de exemplu atunci când se știe că cheia privată asociată a fost furată. Cheile revocate sunt specificate prin includerea marcajului “@revoked” la începutul liniei cheii și nu sunt niciodată acceptate pentru autentificare sau ca autorități de certificare, ci vor produce un avertisment din partea ssh(1) atunci când sunt întâlnite.
Este permis (dar nu recomandat) să existe mai multe linii sau chei de gazdă diferite pentru aceleași nume. Acest lucru se va întâmpla în mod inevitabil atunci când formele scurte ale numelor de gazdă din domenii diferite sunt introduse în fișier. Este posibil ca fișierele să conțină informații contradictorii; autentificarea este acceptată dacă pot fi găsite informații valide în oricare dintre fișiere.
Rețineți că liniile din aceste fișiere sunt de obicei lungi de sute de caractere și cu siguranță nu doriți să introduceți cheile de gazdă de mână. Mai degrabă, generați-le printr-un script, ssh-keyscan(1) sau luând, de exemplu, /etc/ssh/ssh_host_rsa_key.pub și adăugând numele de gazdă în față. ssh-keygen(1) oferă, de asemenea, o editare automată de bază pentru ~/.ssh/known_hosts, inclusiv eliminarea gazdelor care corespund unui nume de gazdă și convertirea tuturor numelor de gazdă în reprezentările lor de sumă de control.
Un exemplu de fișier ssh_known_hosts:
# Comentarii permise la începutul liniei cvs.example.net,192.0.2.10 ssh-rsa AAAA1234.....= # Un nume de gazdă în format sumă de control |1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa AAAA1234.....= # O cheie revocată @revoked * ssh-rsa AAAAB5W... # O cheie CA, acceptată pentru orice gazdă din *.mydomain.com sau *.mydomain.org @cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W...
PrintLastLog și,
respectiv, PrintMotd. Aceasta nu suprimă
afișarea anunțului specificat de
Banner.
sshd
î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ă altor
persoane.
Dacă acest fișier, directorul
~/.ssh sau directorul personal al utilizatorului
pot fi scrise de alți utilizatori, fișierul poate fi
modificat sau înlocuit de utilizatori neautorizați.
În acest caz, sshd nu va permite
utilizarea acestuia decât dacă opțiunea
StrictModes a fost stabilită la
“no”.
#’) și linii de atribuire de
forma nume=valoare. Fișierul trebuie să poată fi
scris numai de către utilizator; nu trebuie să poată
fi citit de nimeni altcineva. Procesarea mediului este dezactivată
implicit și este controlată prin intermediul opțiunii
PermitUserEnvironment.
sshd refuză să permită
oricărei persoane, cu excepția utilizatorului root,
să se conecteze. Conținutul fișierului este
afișat oricărei persoane care încearcă
să se conecteze, iar conexiunile non-root sunt refuzate.
Fișierul trebuie să poată fi citit de toată
lumea.
sshd nu
pornește dacă aceste fișiere sunt accesibile
grupului/ lumii.
sshd.
Formatul fișierului și opțiunile de configurare sunt
descrise în sshd_config(5).
sshd în timpul separării
privilegiilor în faza de pre-autentificare. Directorul nu trebuie
să conțină niciun fișier și trebuie
să fie deținut de root și să nu poată
fi scris de grup sau de alții.
sshd care
ascultă conexiunile (în cazul în care există
mai mulți demoni care rulează concomitent pentru porturi
diferite, acesta conține ID-ul procesului celui pornit ultima
dată). Conținutul acestui fișier nu este sensibil; el
poate fi citit de toată lumea.scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh-keygen(1), ssh-keyscan(1), chroot(2), hosts_access(5), moduli(5), sshd_config(5), inetd(8), sftp-server(8)
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 caracteristici noi și au creat OpenSSH. Markus Friedl a contribuit la suportul pentru versiunile 1.5 și 2.0 ale protocolului SSH. Niels Provos și Markus Friedl au contribuit la suportul pentru separarea privilegiilor.
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: 15 septembrie 2024 $ | Debian |