În depozitele Centos există o versiune destul de veche a OpenSSH și nimeni nu se grăbește să o actualizeze. Poate că aceasta nu este o necesitate severă, dar de ce nu, din moment ce OpenSSH în sine se dezvoltă și este actualizat? Mai mult, cetățenii se plâng că sistemul vechi ssh nu trece auditul de securitate. Deci, am stabilit!
Și acum am pas cu pas să spun cum să actualizeze OpenSSH, ocolind capcanele și nu umplut conuri. Toate cele de mai jos au fost testate pe computerele virtuale "out of the box" de la SimpleCloud sau vScale. și funcționează pe serverul în care este localizat acest site.
Baza este luată de HowTo, prezentată aici. dar lucrul cu sursele este încă hemoroizi, așa că am simplificat sarcina prin colectarea RPM-urilor pentru Centos7 și punerea lor în depozitul meu. La momentul scrisului, acesta este de 7,5p1 și am de gând să adaug pachete pe măsură ce sunt lansate versiuni noi.
Deci, trebuie să începeți cu sistemul de backup. Cred că întotdeauna faceți, dar niciodată nu știți! În plus, chiar înainte de instalare, vă recomandăm să salvați două fișiere în directorul de lucru:
- Configurația sshd este / etc / ssh / sshd_config
- Configurația pam pentru sshd este /etc/pam.d/sshd
În plus, un avertisment separat: este probabil ca sshd imediat după instalarea „cap“ nu funcționează în mod corespunzător, cel puțin am niciodată un astfel nu a fost!
Prin urmare, nu acoperă ssh-consola, cu care face toate operațiile de manipulare și nu supraîncărcați server pentru moment, asigurați-vă că noua versiune a sshd funcționează corect, niciodată nu va intra pe serverul de altă consolă în mod obișnuit și nu primesc de obicei consola rădăcină în același mod! Prin derogare de la orice reporniri sshd sesiunea curentă este stocată, iar dacă ceva nu a mers bine, ceva nou, nu va fi capabil să instaleze și să înceapă dans cu o tamburină.
Toate comenzile sunt executate ulterior de la root sau prin sudo.
Deci, trebuie să conectăm repozitoriul, să copiem fișierul cu metadatele sale:
wget -P /etc/yum.repos.d/ repo.pavlyuts.ru/pavlyuts.repo
Acum depozitul meu este conectat la sistemul tău. Actualizați pachetele:
yum upgrade openssh *
Yum ne va arăta trei pachete actualizate și vom cere confirmarea. Expirați și confirmați. Ar părea totul, dar nu totul este atât de simplu! Prin urmare, înainte de a face o repornire sshd (systemctl restart sshd), trebuie să verificați ceva și să-l reparați, deoarece începe ...
capcane
Configurația Sshd
Ideea este că actualizarea poate suprascrie sshd_config sau este posibil să nu se suprascrie. Pentru ao defini, este simplu - dacă vechea configurație este salvată, fișierul sshd_config.rpmnew apare în directorul din apropiere. Dacă nu, atunci cel mai probabil configurația este suprascrisă și devine "implicită". În ambele cazuri, vă propun, ținând cont de noua configurație implicită, să stabiliți parametrii de care aveți nevoie, comparându-vă cu cel vechi, mai ales că există opțiuni învechite.
Să presupunem că am făcut configurația așa cum ar trebui, dar este prea devreme să ne bucurăm.
Drepturile la chei
chei server necesită dreptul de proprietate și permisiuni de root 0600. În cazul în care drepturile altora - cheia nu este încărcat! Pe una dintre imaginile de scurgere am fost confruntat cu faptul că drepturile au fost mai largi pe trei din cele patru taste presetate, ca urmare a demon nu dă un mesaj de eroare în timpul repornirii și cheile „rele“ nu sunt încărcate, și scrie despre ea în mesajele jurnal:
localhost sshd: Permisiunile 0640 pentru '/ etc / ssh / ssh_host_rsa_key' sunt prea deschise.
localhost sshd: Nu am putut încărca cheia gazdă: / etc / ssh / ssh_host_rsa_key
Sesiunile nu sunt ridicate, deoarece nu există nici o cheie RSA! Pentru a nu rula în această mină - este mai ușor să executați o singură comandă simultan:
chmod -v 0600 / etc / ssh / ssh_host _ * _ cheie
Ea fie corectează situația, fie nu face nimic, iar rezultatul va fi clar din raportul său.
localhost sshd [4503]: Autentificare refuzată: proprietate rea sau moduri de fișier pentru /home/%user%/.ssh/authorized_keys
Nu contează dacă sshd poate citi cheia. Tratate în acest fel de înțeles: /.ssh/authorized_keys proprietar trebuie să fie exact utilizatorul al cărui director este acasă, iar drepturile acestuia ar trebui să nu mai mult de 0644. Există suspiciuni că verificate anterior, și nimic nou în această versiune, dar Trebuie să-mi amintesc că am dat peste asta în cursul experimentelor mele.
Dificultăți cu PAM
PAM în general pentru mine mecanismul este complex, misterios, bine, așa că nu mă poziționez ca un specialist abrupt. Cred că dacă includeți PAM în sshd, atunci știi exact ce faci.
Vă pot spune doar că, la instalare, pachetul elimină /etc/pam.d/sshd și scrie unul nou în locul său, cu următorul conținut:
localhost sshd [2111]: adăugarea unui modul PAM defect: /usr/lib64/security/pam_stack.so
localhost sshd [2115]: PAM în imposibilitatea de a dlopen (/usr/lib64/security/pam_stack.so): /usr/lib64/security/pam_stack.so: nu se poate deschide partajate obiect fișier: Nu există un astfel de fișier sau director
Google știe totul, iar soluția a fost găsită, este foarte simplă. Acolo unde a fost în /etc/pam.d/sshd:
necesar pam_stack.so service = system-auth
ar trebui să fie:
include sistem-auth
Și totul începe să funcționeze! Pentru claritate completă, /etc/pam.d/sshd ar trebui să arate astfel:
Utilizatori fără parolă
localhost sshd [2073]: User% user% nu este permis deoarece contul este blocat
C, de asemenea, a reușit să-și dea seama. Sa dovedit că atunci când creați un utilizator cu comanda useradd fără o parolă în / etc / shadow, acest tip de șir este creat, de exemplu pentru testul utilizatorului:
În locul unde ar trebui să existe o parolă de hash - două semne de exclamare. Cu toate acestea, atunci când introduceți o parolă din consola, un semn de exclamare înseamnă că utilizatorul are o parolă blocată, iar două - că utilizatorul este blocat. Deblocați utilizatorul prin mijloace regulate fără a-i oferi parola - nu puteți. Și sshd nu permite "utilizatorilor blocați" de conectare la distanță.
Această problemă este tratată în trei moduri:
Și aici este finisajul!
Deci, prin toate pietrele pe care le-am cunoscut, am încercat să te țin, dar asta nu înseamnă că nu mai există alții! Cu toate acestea, sper că ați reușit să nu găsiți noi probleme și să faceți față cu cele cunoscute.
Cel mai important lucru - după „finisare“ sshd repornire pentru a verifica cu atenție pe care le puteți introduce de la un alt mod obișnuit terminale, totul funcționează așa cum ar trebui, și, cel mai important, să aibă acces la rădăcina.
P.S. Ultima opțiune, dacă nu funcționează nimic și nu doriți să vă recuperați din backup - puteți să schimbați modificările:
yum downgrade openssh *
Fișierele de configurare trebuie să fie restaurate din locul unde le-am salvat economic la începutul căii. După repornirea sshd, vom reveni la punctul de plecare. Dar chiar și după aceea - merită, fără a închide consola, să verificăm dacă totul funcționează așa cum ar trebui.
Și nu uitați să ștergeți link-ul la depozitul meu în cazul unei retrogradări, altfel viitoarea versiune a ssh va fi instalată din nou la următoarea actualizare a sistemului:
rm -f /etc/yum.repos.d/pavlyuts.repo
Articole similare
Trimiteți-le prietenilor: