Остання версія openssh на centos7

У репозиторіях Centos знаходиться досить давня версія OpenSSH, і ніхто не поспішає її оновлювати. Може бути в цьому і немає суворої необхідності, але чому б і ні, раз сам OpenSSH розвивається і оновлюється? Тим більше, що громадяни скаржаться на те, що зі старим ssh система не проходить аудит безпеки. Отже, ставимо!

І зараз я покроково розповім як оновити OpenSSH, обходячи підводні камені і не набиваючи шишок. Все нижче описане тестувалося на віртуалкою «з коробки» від SimpleCloud або vScale. і працює на сервері де розміщений цей сайт.

За основу взято HowTo, викладене ось тут. проте працювати з вихідними кодами - той ще геморой, тому я спростив Вам завдання, зібравши RPMи для Centos7 і поклав їх в свій репозиторій. На момент написання це 7.5p1, і я планую додавати пакети в міру виходу нових версій.

Отже, почати треба з бекапа системи. Вірю, що Ви завжди так робите, але хіба мало! Крім цього безпосередньо перед установкою я настійно рекомендую окремо зберегти робочий каталог два файли:

  • Конфігурацію sshd - / etc / ssh / sshd_config
  • Конфігурацію pam для sshd - /etc/pam.d/sshd

Крім того, окреме попередження: велика ймовірність що sshd відразу після установки «в лоб» не запрацює нормально, у всякому разі у мене жодного разу такого не було!

Тому не закривайте ssh-консоль, з якою ви проводите всі маніпуляції і не перевантажуйте сервер до того моменту, як переконаєтеся що нова версія sshd працює нормально, не ввійдете на сервер інший консоллю звичайним чином і не отримаєте звичайним же чином консоль root! Незважаючи на будь-які рестарту sshd поточна сесія зберігається, і якщо щось пішло не так, то нову ви встановити не зможете і почнуться танці з бубном.

Всі команди далі виконуються з під root або через sudo.

Отже, нам треба підключити репозиторій, копіюємо файл з його метаданими:

wget -P /etc/yum.repos.d/ repo.pavlyuts.ru/pavlyuts.repo

Тепер мій репозиторій підключений до Вашої системи. І оновлюємо пакети:

yum upgrade openssh *

Yum покаже нам три оновлюваних пакета і попросить підтвердження. Видихніть, і підтверджуємо. Здавалося б все, але не все так просто! Тому перш ніж робити рестарт sshd (systemctl restart sshd), треба дещо перевірити і поправити, бо починаються ...

Підводні камені

конфігурація sshd

Справа в тому, що оновлення може перезаписати sshd_config, а може не перезаписати. Визначити це просто - якщо стара конфігурація збережена, то поруч в каталозі з'являється файл sshd_config.rpmnew. Якщо його немає, то швидше за все конфігурація переписана і стала «дефолтной». В обох випадках я пропоную, взявши за основу нову дефолтну конфігурацію, встановити потрібні Вам параметри, справляючись зі старою, тим більше, що там є застарілі опції.

Давайте вважати, що конфігурацію ми зробили як треба, але радіти рано.

Права на ключі

Для ключів сервера вона вимагає власника root і права 0600. Якщо права інші - ключ не завантажується! На одному з стічних образів я зіткнувся з тим, що права були ширше на трьох з чотирьох заданих ключів, в результаті демон не дає повідомлення про помилку при рестарт, а «погані» ключі не грузить, і пише про це в лог messages:

localhost sshd: Permissions 0640 for '/ etc / ssh / ssh_host_rsa_key' are too open.
localhost sshd: Could not load host key: / etc / ssh / ssh_host_rsa_key

Сесії не піднімаються, тому що ключа RSA немає! Щоб не нарватися на цю міну - простіше відразу виконати одну команду:

chmod -v 0600 / etc / ssh / ssh_host _ * _ key

Вона або виправить ситуацію, або просто нічого не зробить, а результат буде зрозумілий з її звіту.

localhost sshd [4503]: Authentication refused: bad ownership or modes for file /home/%user%/.ssh/authorized_keys

При цьому абсолютно не важливо чи може sshd прочитати ключ. Лікується це зрозумілим способом: власником /.ssh/authorized_keys повинен бути саме той користувач чий це домашній каталог, а права на нього повинні бути не більше 0644. Є підозри, що це і раніше перевірялося, і не новина в цій версії, але і це треба мати на увазі, я зіткнувся з цим в ході своїх експериментів.

Складнощі з PAM

PAM взагалі для мене механізм складний, загадковий, ну так я і не позиціонують себе як крутого фахівця. Вважаю, що якщо Ви включаєте в sshd використання PAM, то Ви точно знаєте, що робите.

Можу лише повідомити, що при установці пакет видаляє /etc/pam.d/sshd і записує на його місце новий, з наступним змістом:

localhost sshd [2111]: PAM adding faulty module: /usr/lib64/security/pam_stack.so
localhost sshd [2115]: PAM unable to dlopen (/usr/lib64/security/pam_stack.so): /usr/lib64/security/pam_stack.so: can not open shared object file: No such file or directory

Гугл знає все, і рішення знайшлося, воно дуже просте. Скрізь, де в /etc/pam.d/sshd було:
required pam_stack.so service = system-auth
повинно бути:
include system-auth

І все починає працювати! Для повної ясності, /etc/pam.d/sshd повинен виглядати так:

Користувачі без пароля

localhost sshd [2073]: User% user% not allowed because account is locked

C цим теж вдалося розібратися. Виявилося, що при створенні користувача командою useradd без пароля в / etc / shadow створюються ось такого виду рядка, наприклад для користувача test:

У тому місці, де повинен бути хеш пароля - два знаки оклику. Однак, при вході по паролю з консолі один знак оклику означає, що у користувача заблоковано пароль, а два - що заблокований сам користувач. Розблокувати користувача штатними засобами не ставлячи йому пароль - не можна. А sshd не дозволяє «заблокованим користувачам» віддалений вхід.

Лікується ця проблема одним з трьох способів:

А ось і фініш!

Отже, повз всіх відомих мені позводних каменів я Вас постарався провести, однак це не означає що не буває інших! Однак, я сподіваюся, що Вам вдалося не знайти нових проблем і впоратися з відомими.

Найголовніше - після «фінішного» рестарту sshd ретельно перевірити, що Ви можете з іншого терміналу увійти звичним чином, все працює як треба, і, що найголовніше, є доступ до root.

P.S. Останній варіант, якщо нічого не виходить, а відновлюватися з резервної копії не хочеться - зміни можна відкотити:

yum downgrade openssh *

Файли конфігурації треба відновити з того місця, куди ми їх господарсько зберегли на початку шляху. Після рестарту sshd ми повернемося в початкову точку. Але навіть після цього - варто, не закриваючи консоль, перевірити що все працює як треба.

І не забудьте в разі відкату видалити посилання на мій репозиторій, інакше при наступному оновленні системи остання версія ssh знову встановиться сама:

rm -f /etc/yum.repos.d/pavlyuts.repo

Схожі статті