Влизането с парола по SSH е най-голямата открита повърхност на обикновен сървър. Срещу него са безсилни и Fail2ban, и всякакви прагове: хиляда адреса по един опит на час никога няма да достигнат лимита, а ще опитват точно докато налучкването изобщо е възможно. Ключовете премахват самата възможност и това е единствената настройка от целия списък за втвърдяване, която променя положението качествено.

Плаши едно: да изключите паролата и да останете отвън. По-долу е редът, при който това е изключено.

Ключът

Генерира се на собствената машина, а не на сървъра:

ssh-keygen -t ed25519 -C "работен лаптоп"

ed25519 вместо RSA — по-къс, по-бърз и без въпроси за дължината. RSA е нужен само ако предстои свързване с нещо много старо; тогава -t rsa -b 4096.

Парола за ключа (passphrase) си струва да се сложи: файлът на ключа може да бъде откраднат от лаптопа и без парола работи веднага. Няма да се въвежда всеки път — с това се занимава ssh-agent, а в macOS и повечето настолни Linux дистрибуции той вече е стартиран.

Копиране на сървъра с една команда, докато паролата още работи:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

Ако ssh-copy-id го няма, съдържанието на .pub файла се добавя като ред в ~/.ssh/authorized_keys на сървъра. Правата са важни: директорията .ssh — 700, файлът — 600, собственик самият потребител. При други права sshd мълчаливо отказва да чете файла и това е най-честата причина „ключът не работи“.

Проверката, която решава всичко

Преди да изключите каквото и да било, отворете втора връзка, без да затваряте първата:

ssh -o PasswordAuthentication=no user@203.0.113.25

Опцията забранява на клиента да се върне към парола — тоест ако влизането е станало, станало е точно с ключ. Докато тази команда не мине, към следващата стъпка не се преминава. А първата връзка до самия край не затваряме: през нея се поправя всичко, което може да се счупи.

Изключването на паролата и един неочевиден капан

Настройките слагаме в отделен файл, за да не ги презапише обновяването на пакета. Но името на файла има значение:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

Работата е там, че OpenSSH използва първата срещната стойност на параметъра, а не последната, както е почти навсякъде другаде. Файловете от sshd_config.d се четат по азбучен ред, а облачните образи на Ubuntu слагат там 50-cloud-init.conf, в който нерядко стои PasswordAuthentication yes. Вашият файл с номер 90 тогава няма да направи нищо: настройката уж е записана, а паролата продължава да работи. Оттук номер 10 — той се чете по-рано.

Какво се е получило в крайна сметка, не се гадае:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

Тази команда отпечатва действащата конфигурация след всички включвания. На нея вярвайте, а не на съдържанието на файловете.

По-нататък — проверка на синтаксиса и меко презареждане на услугата:

sudo sshd -t && sudo systemctl reload ssh

sshd -t е задължителен: печатна грешка в конфигурацията при restart оставя услугата легнала, а вас — отвън. reload при това не къса отворените сесии.

Ubuntu 24.04: портът се сменя другаде

Отделен капан на новите Ubuntu: sshd там се стартира през systemd сокет. Редът Port в sshd_config в този режим не прави нищо — слуша сокетът, а не демонът. Ако сменяте порта, него трябва да редактирате:

sudo systemctl edit ssh.socket

и да укажете ListenStream= (празна стойност нулира предишната) с новия порт. Симптомът, по който това се разпознава: конфигурацията е променена, услугата е рестартирана, а сървърът продължава да отговаря на 22.

Между другото за смяната на порта: като защита тя не работи — скенерите намират услугата на всеки порт за минути. Единственият ѝ ефект е, че в журналите става по-тихо, защото масовото налучкване върви само по 22. Това е удобно, но не го бъркайте със сигурността.

Кой изобщо може да влиза

Полезно допълнение е изричен списък:

AllowUsers deploy admin

Всичко, което не е изброено, се отсича още преди проверката на ключа. Това заедно с това покрива случая, когато някой пакет създава системен потребител с обвивка и домашна директория.

Резервен вход

Един ключ на един лаптоп е единствена точка на отказ. Дискът умира, лаптопът се губи и сървърът става недостъпен завинаги. Разумен минимум:

  • втори ключ от друго устройство в authorized_keys;
  • копие на частния ключ в мениджър на пароли или на криптирана флашка;
  • проверен достъп до конзолата при доставчика — VNC или сериен. Проверен означава, че сте влизали там поне веднъж, а не че „някъде в панела има бутон“.

Заедно с това вижте какво вече лежи в authorized_keys — и при вашия потребител, и при root. Чужд ключ там преживява всяка смяна на паролата и остава работещ достъп.

След това

Налучкването на пароли няма да изчезне, просто вече е безполезно: в журналите ще останат хиляди Failed password, нито едно от които не може да завърши с успех. Затова пък сега си струва да гледате успешните влизания: от кой адрес, под кой потребител, по кое време. Успешно влизане с ключ от непознат адрес е далеч по-важно събитие от милион неуспешни опита и е много по-трудно да се забележи в общия поток. Точно тази картина показва демонстрационната страница по-долу.