A legújabb verzió az OpenSSH a centos7
Az adattárak CentOS meglehetősen régi változata OpenSSH, és nem siet frissíteni. Talán ebben, és van egy komoly igény, de miért nem, ha egyszer OpenSSH fejlesztése és frissítése? Minél több, hogy a polgárok azt kifogásolják, hogy a régi rendszer nem felel meg az ssh biztonsági audit. Így teszünk!
És most azt mondani, hogy lépésről lépésre, hogyan kell frissíteni OpenSSH, elkerülve a csapdákat és a töltés kúp. Az alábbi összes tesztelt Dev "out of the box" által SimpleCloud vagy vScale. és fut a tároló szerver honlapján.
Ez alapján HowTo meghatározott, itt. de dolgozni források - minél több aranyér, úgyhogy egyszerűsítse a feladat, összegyűjtése RPMy a Centos7 és tedd őket egy tárolóból. Abban az időben az írás ezt 7.5p1, és azt tervezi, hogy adjunk csomagokat az új verziók megjelenésével.
Tehát meg kell kezdeni egy biztonsági rendszer. Úgy vélem, hogy mindig erre, de sosem lehet tudni! Ezen kívül közvetlenül a szerelés előtt, azt javasoljuk, külön-külön tároljuk a munka könyvtárba két fájlt:
- Konfigurálása sshd - / etc / ssh / sshd_config
- PAM-konfiguráció a sshd - /etc/pam.d/sshd
Ezen kívül egy külön figyelmeztetés: valószínű, hogy a sshd telepítése után azonnal a „fej” nem működik megfelelően, legalábbis én még soha ilyen nem volt!
Ezért nem terjednek ki az ssh-konzol, amellyel megadhatók az manipuláció és ne terhelje a szervert, hogy a pillanat, győződjön meg arról, hogy az új verzió a sshd megfelelően működik, akkor soha nem adja meg a kiszolgáló konzol egyéb a szokásos módon, és nem kap a szokásos gyökér konzol ugyanúgy! Tekintet nélkül újraindul sshd aktuális munkamenet tárolják, és ha valami elromlott, valami újat, akkor nem lesz képes telepíteni és elkezd táncolni a tambura.
Minden csapat továbbra is root-ként fut keresztül vagy sudo.
Szóval, mi kell csatlakoztatni az adattár, másolja a fájlt a metaadatok:
wget -P /etc/yum.repos.d/ repo.pavlyuts.ru/pavlyuts.repo
Most én adattár csatlakozik a rendszerhez. És frissítési csomagokat:
yum frissíteni openssh *
Yum megmutatja nekünk három frissíthető csomagok és megerősítést kér. Lélegezz ki, és megerősítik. Úgy tűnik, hogy mindent, de nem minden ilyen egyszerű! Ezért, mielőtt csinál az újraindítás sshd (systemctl újraindítás sshd), van valami, hogy ellenőrizze, és helyes, kezdetnek ...
buktatók
konfigurációja sshd
Az a tény, hogy a frissítés felülírja az sshd_config, és nem lehet felülírni. Adjuk ez csak - ha a régi konfiguráció van mentve, a következő a katalógusban jelenik sshd_config.rpmnew fájlt. Ha nem, akkor valószínűleg konfiguráció felülírja, és válnak „alapértelmezett”. Mindkét esetben azt javaslom, amely az új alapértelmezett beállítás, akkor állítsa be a kívánt paramétereket, megbirkózni a régi, különösen azért, mert van egy régebbi megoldás.
Tegyük fel, hogy a konfiguráció már kész van, de túl korai az örömre.
Közvetlenül a kulcsokat
Szerver kulcsok igényel gyökér tulajdonos és a jogosultságok 0600. Ha mások jogait - a kulcs nincs betöltve! Az egyik a lefolyás képek én szembesülnek azzal a ténnyel, hogy a jogok voltak szélesebb három a négy előre beállított kulcsokat, ennek eredményeként a démon nem ad hibaüzenetet Az újraindítás során, valamint a „rossz” gombok nincsenek betöltve, és ír róla a naplóbejegyzések:
localhost sshd: Engedélyek 0640 az / etc / ssh / ssh_host_rsa_key "túl nyitott.
localhost sshd: Nem sikerült betölteni a fogadó gomb: / etc / ssh / ssh_host_rsa_key
Sessions nem emelkedik, mert az RSA saját kulcs nincs jelen! Annak érdekében, hogy ne befut a bánya - könnyebb, csak hogy végre egy parancsot:
chmod -v 0600 / etc / ssh / ssh_host _ * _ gombot
Ez sem oldják meg a helyzetet, vagy egyszerűen nem tesz semmit, és az eredmény világos lesz jelentését.
localhost sshd [4503]: A hitelesítés nem volt hajlandó: rossz tulajdonosi vagy üzemmódok fájl /home/%user%/.ssh/authorized_keys
Ebben az esetben nem számít, hogy az sshd olvasni a kulcsot. Módon kezeljük érthető: a tulajdonos /.ssh/authorized_keys kell pontosan a felhasználót, akinek otthon könyvtár, és a jogokat, akkor nem lehet több, mint 0644. Vannak a gyanú, hogy a korábban általa ellenőrzött, és semmi új ebben a verzióban, de szem előtt kell tartanunk, rábukkantam erre során a kísérletek.
Nehézségek PAM
PAM mechanizmus egyáltalán nehéz nekem, egy titokzatos, nos, ne helyezze magam, mint egy kemény profi. Úgy vélem, hogy ha bekapcsolja a használatát PAM sshd, akkor pontosan tudja, mit csinál.
Csak azt tudom mondani, hogy ha egy csomag telepítése eltávolítja /etc/pam.d/sshd és kiírja az újat a helyére, az alábbi tartalommal:
localhost sshd [2111]: PAM hozzáadásával hibás modult: /usr/lib64/security/pam_stack.so
localhost sshd [2115]: PAM képtelen dlopen (/usr/lib64/security/pam_stack.so): /usr/lib64/security/pam_stack.so: nem lehet megnyitni megosztott objektum fájlt: Nincs ilyen fájl vagy könyvtár
A Google mindent tud, és az oldatot talált, nagyon egyszerű. Ahol a /etc/pam.d/sshd voltak:
szükséges pam_stack.so service = system-auth
Meg kell:
közé tartozik a rendszer-auth
És minden kezdődik a munka! Ahhoz, hogy teljesen világos, /etc/pam.d/sshd kell kinéznie:
A felhasználók a jelszó megadása nélkül
localhost sshd [2073]: A felhasználói% user% nem engedélyezett, mert számlája zárolva
C azt is tudja, hogy megértsék. Kiderült, hogy amikor létrehoz egy felhasználói useradd parancsot a jelszó nélküli és / etc / shadow itt ilyen típusú vonalon, például a felhasználói teszt:
Azon a helyen, ahol kell egy hash a jelszó - két felkiáltójel. Azonban, ha a jelszó bevitele a konzol egy felkiáltójel azt jelenti, hogy a felhasználó jelszava blokkolva van, és a két -, hogy le van zárva, a felhasználó által. Kinyit felhasználó rendszeres eszközökkel nem kérve a jelszó - lehetetlen. A sshd nem engedélyezi a „blokkolt felhasználók távoli bejelentkezés.
Ezt a problémát kezelik a következő három módon:
És itt van a célig!
Így, minden, amit tudok pozvodnyh köveket próbáltam tartani, de ez nem jelenti azt, hogy nincs más! Azonban remélem, hogy nem tudta, hogy új kihívásokat, és foglalkozik a ismert.
A legfontosabb dolog - miután „befejező” újraindítás sshd, hogy gondosan vizsgálják megadhat egy másik terminálról szokásos módon, minden úgy működik, ahogy kellene, és ami a legfontosabb, van, hogy a gyökér.
Ui Az utolsó lehetőség, ha minden kötél szakad, és vissza a backup nem akar -, akkor visszaállíthatja változások:
yum leminősítés openssh *
A konfigurációs fájlok helyre kell állítani a hely, ahol megőrizték a háztartásban az elején. Az újraindítás után sshd visszatérünk a kiindulóponthoz. De még azután is, hogy - a költségek bezárása nélkül a konzol, ellenőrizze, hogy minden működik, ahogy kellene.
És ne felejtsük el, hogy távolítsa el a visszatérés esetén egy linket a tár, vagy a következő rendszer frissítése a legújabb verzióra ssh újra ki magát:
rm -f /etc/yum.repos.d/pavlyuts.repo