Безопасна настройка на SSH сървъра

Модул 2: SSH и ключове · Време за четене: 12 минути

Цел на урока: След този урок ще можете да изключите влизането с парола и влизането като root с парола, да проверите коя настройка реално важи и да направите това, без да заключите сами себе си отвън.

Основни понятия: sshd, sshd_config, sshd_config.d, важи първата стойност, PasswordAuthentication, KbdInteractiveAuthentication, PermitRootLogin, AuthenticationMethods, AllowUsers, sshd -t, sshd -T, втора сесия, cloud-init, ssh.socket

Първо предпазната мрежа

В този урок затваряте вход, през който самите Вие трябва да минавате. Една печатна грешка може да означава, че вече не можете да влезете. Затова винаги, преди да започнете:

1. Два ключа работят (урок 2.1) и сте проверили в нов прозорец, че влизането с ключ е успешно.
2. Snapshot на Вашия VPS. При WebOké го създавате в екрана на VPS, при други доставчици също се нарича snapshot или image. Ако нещо се обърка, го възстановявате.
3. Конзолата на Вашия доставчик Ви е позната: през нея влизате без SSH.
4. Текущата Ви SSH сесия остава отворена до края. Активната сесия продължава да работи, когато промените настройките или презаредите услугата. Всяка промяна тествате във втори прозорец.

Къде се намират настройките

SSH сървърът се казва sshd. Настройките му са в /etc/ssh/sshd_config. В Debian и Ubuntu в началото на този файл стои следният ред:

Include /etc/ssh/sshd_config.d/*.conf

Следователно всички файлове с .conf в папката sshd_config.d се четат преди останалата част от основния файл, по азбучен ред. Това е удобно: поставяте собствените си настройки в отделен файл и оставяте основния файл непокътнат, така че актуализация на пакета не засяга Вашите промени.

Това обаче има последствие, което изненадва много хора. В sshd_config важи следното: за всяка настройка важи първата стойност, която sshd срещне. По-късни редове със същата настройка се игнорират. Ако напишете PasswordAuthentication no в края на sshd_config, това не надделява над файл в sshd_config.d, в който пише yes.

Капанът на cloud-init

Много VPS images се настройват при първото стартиране от cloud-init. В зависимост от това как са настроени image и инсталацията, cloud-init записва файл като /etc/ssh/sshd_config.d/50-cloud-init.conf, който съдържа например:

PasswordAuthentication yes

Тъй като този файл се чете преди основния, влизането с парола остава включено, каквото и да напишете в sshd_config. Затова не предполагайте, а проверете:

root@web1:~# grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
/etc/ssh/sshd_config:#PasswordAuthentication yes
/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes

Има две чисти решения: променете този файл на no или поставете собствените си настройки във файл, който е по-рано по азбучен ред, например 00-beveiliging.conf. Файл 99-mijn.conf точно няма да сработи, защото тогава cloud-init вече е надделял.

Настройките, които имат значение

Създайте собствен файл:

root@web1:~# nano /etc/ssh/sshd_config.d/00-beveiliging.conf

със следното съдържание:

# Вход само с ключ
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Какво означава всеки ред?

• PasswordAuthentication no: сървърът вече не приема парола. Стойността по подразбиране в OpenSSH е yes.
• KbdInteractiveAuthentication no: "keyboard-interactive" е втори начин за искане на парола, чрез PAM. Ако го оставите включен, някой все пак може да опита с парола, дори когато PasswordAuthentication е на no. В по-стари ръководства тази настройка се нарича ChallengeResponseAuthentication; от OpenSSH 8.7 това е остаряло друго име за същото. Debian по подразбиране вече я задава на no, но все пак я напишете: така е ясно и е вярно и на други системи.
• PermitRootLogin prohibit-password: root може да влиза, но само с ключ. От OpenSSH 7.0 това е стойността по подразбиране. По-строго е PermitRootLogin no: root изобщо не може да влиза през SSH, влизате като обикновен потребител и използвате sudo (урок 3.2). Задайте no едва когато сте сигурни, че влизането като този потребител и sudo работят.

По избор, за тези, които искат повече:

AllowUsers anna
AuthenticationMethods publickey

AllowUsers пуска само изброените потребители; всяко друго име се отказва, дори ако има валиден ключ. Удобно е, но не забравяйте себе си и не пропускайте да допълните списъка, когато добавите втори администратор. AuthenticationMethods publickey казва с един ред, че важат само ключове.

Тестване, прилагане, проверка

Първо оставете sshd да провери файла. Това не стартира и не променя нищо:

root@web1:~# sshd -t
root@web1:~#

Липсата на изход означава: няма грешки. При печатна грешка ще видите реда и файла. Едва тогава презаредете услугата:

root@web1:~# systemctl reload ssh

В Debian и Ubuntu услугата се казва ssh, в AlmaLinux и Rocky Linux sshd.

След това проверете коя стойност реално важи. sshd -T показва пълната, изчислена конфигурация, с обработени всички Include файлове:

root@web1:~# sshd -T | grep -Ei 'passwordauth|kbdinteractive|permitrootlogin'
permitrootlogin without-password
passwordauthentication no
kbdinteractiveauthentication no

(without-password е старото име на prohibit-password. Версиите на OpenSSH преди 10.1, като тези в Debian 13 и Ubuntu 24.04, още показват старото име; по-новите показват prohibit-password. Означава едно и също.)

А сега най-важното: тествайте във втори прозорец, докато първият остава отворен.

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$

Ако това работи, опитайте съзнателно да влезете с парола. Това трябва да се провали:

anna@laptop:~$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@192.0.2.10
anna@192.0.2.10: Permission denied (publickey).

След Permission denied в скоби е посочено кои методи за влизане сървърът все още предлага. Ако там стои само publickey, всичко е наред. Ако има и password или keyboard-interactive, някъде все още важи друга стойност: проверете отново с sshd -T.

Точно този списък проверява и задачата от курса, отвън. При всяка връзка Вашият SSH клиент първо пита кои методи са разрешени, със заявка от типа "none". Сървърът отговаря със списъка, без да се опитва парола или ключ.

Ubuntu 24.04 и по-нови: ssh.socket

В Ubuntu от версия 22.10 на порт 22 не слуша самият sshd, а systemd, чрез ssh.socket. Едва когато постъпи връзка, systemd стартира SSH услугата. За настройките в този урок това няма значение: systemctl reload ssh или restart ssh е достатъчно.

Има значение обаче, ако промените порта или адреса за слушане (Port, ListenAddress). От Ubuntu 24.04 systemd чете тези стойности от sshd_config, но само след:

root@web1:~# systemctl daemon-reload
root@web1:~# systemctl restart ssh.socket

Ако забравите това, сървърът просто продължава да слуша на стария порт. По-лошо: ако първо настроите защитната стена за нов порт, а SSH остане на стария, ще заключите сами себе си отвън. Винаги проверявайте с ss -tlnp | grep ssh на какво реално се слуша (урок 5.1) и отворете новия порт в защитната стена, преди да затворите стария. Дали друг порт има смисъл, ще прочетете в урок 2.3.

Ако все пак нещо се обърка

Ако вече не можете да влезете, отворете конзолата на Вашия доставчик, влезте като root (с паролата, защото конзолата е "клавиатура, свързана към сървъра", а не SSH) и върнете файла си:

root@web1:~# mv /etc/ssh/sshd_config.d/00-beveiliging.conf /root/
root@web1:~# systemctl reload ssh

Ако и това не помогне, възстановете snapshot. При WebOké в екрана на VPS можете също да зададете нова root парола; други доставчици често имат подобен бутон или режим за спасяване (rescue).

В AlmaLinux и Rocky Linux

Услугата се казва sshd (systemctl reload sshd). И там в началото има Include /etc/ssh/sshd_config.d/*.conf и системата доставя собствени файлове в тази папка; важи същото правило "важи първата стойност". Ако промените порта, SELinux също трябва да разреши този порт (semanage port -a -t ssh_port_t -p tcp 2222), а firewalld трябва да го отвори.

Обобщение

• В sshd_config важи първата стойност; файловете в sshd_config.d се четат първи. Поставете собствените си настройки във файл като 00-beveiliging.conf.
• Задайте PasswordAuthentication no и KbdInteractiveAuthentication no; root само с ключ (prohibit-password) или изобщо не (no).
• Проверявайте с sshd -t преди презареждане и с sshd -T коя стойност реално важи; внимавайте за 50-cloud-init.conf.
• Тествайте във втори прозорец и дръжте първата сесия отворена. Познавайте конзолата и направете предварително snapshot.
• В Ubuntu 24.04+ друг порт изисква systemctl daemon-reload и systemctl restart ssh.socket.

Тест (quiz)

Задача

Задача Z2.2: Влизането с парола е изключено. Изключете влизането с парола и keyboard-interactive, както в този урок, и след това оставете програмата да провери отвън. Въведете IP адреса или hostname на Вашия сървър, SSH порта (по подразбиране 22) и потребителското име, с което самите Вие влизате (например anna, не root или измислено име). Програмата не влиза: тя само пита, както всеки SSH клиент преди влизане, кои методи за влизане Вашият сървър предлага за този потребител. Правилно е: само publickey.

Още за четене

Стъпките в тези статии се отнасят за екрана на VPS при WebOké; при други доставчици работи по подобен начин.

• Защита на VPS: първите пет минути
• Нямате достъп до VPS: какво да направите?
• Снапшоти и резервни копия на VPS
• Ръководство за sshd_config: https://man.openbsd.org/sshd_config
• Ubuntu: SSHd now uses socket-based activation: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189