Сегодня будем запирать врата ада.
ㅤ
Ситуация: Есть физический сервер, на нём торчит само собой Linux, к нему подключен монитор и кнопки. Короче можно физически подойти к этой машине и ввести логин/пароль.

Ну или при желании понажимать ALT+F1, F2, F3 (чтобы переключать tty).

Надеюсь ты понял о чем я тебе говорю. Ну дак вот!

Задача: Нужно запретить физический вход по логину/паролю, но оставить вход по ssh с ключами.

Как настраивать все эти ключи можешь почитать в серии постов по тэгу: #linuxfactory

Давай теперь отключим физический доступ к tty.

Заходим на сервер и смотрим юниты

systemctl list-units | grep getty

В ответ получаем список активных tty

getty@tty1.service
getty@tty2.service
getty@tty3.service
getty@tty4.service

getty (сокращение от get tty) — это программа в Linux и Unix-подобных системах, которая отвечает за управление терминалами и логин-процессом для пользователей, подключающихся к системе через консоль.

Теперь запускаем команды:

systemctl disable getty@tty{1..10}.service
systemctl stop getty@tty{1..10}.service

Всё! Песда! Терминал становится черным, интерактивность потеряна.

Пробуем понажимать ALT+F1, F2, F3 — хуй там плавал!

Перезагружаем сервер и НИЧЕГО! Черная дыра! Пробуем подключиться к серверу по ssh — ХА! Работает сучка!

При отключении getty для терминалов tty1–tty10, это не повлияет на SSH-доступ, так как SSH-сервер работает независимо от getty.

Теперь даже имея физический доступ к серверу, ты нихуя с ним сделать не сможешь. Максимум загрузиться в Recovery mode и починить:

sudo mount /dev/sdXn /mnt
sudo chroot /mnt
sudo systemctl enable getty@tty{1..10}.service
sudo systemctl start getty@tty{1..10}.service

Вот такие приколюхи! Как и где это применять решай сам. Развлекайся.

Про Magic SysRq в Linux писал тут.

Чем терминал отличается от консоли писал тут

tags: #linux #devops
—
🔔 @bashdays➡️ @gitgate

Использовать ssh ключи очень удобно, при условии если у тебя в наличии 2-5-10 серверов

А как жить в ситуации когда у тебя 100500 серверов и еще 100500 пользователей?
ㅤ
Этож нужно за всем этим следить, обновлять и отзывать неактуальны (проёбанные) ключи. Всё скатывается в ужасную рутину.

Да, можно поднять какой-нибудь бастион и через него всем этим рулить, либо упороться с ансиблом и т.п.

Но чтобы не морочиться со всей этой хуйней, у тебя всё это есть и установлено из коробки. Вариант не совсем простой, легко запутаться, но если разобраться то качнешь свой скилл.

Центр сертификации (CA).

Работает он так:

1. Ты настраиваешь CA которому доверяют все твои 100500 серверов.
2. Сертификат подписывает ключи пользователей с указанием сроков действия и ограничений.
3. Если сотрудник покидает команду, ты просто отзываешь сертификат, а не удаляешь ключи с каждого сервера.

Давай замутим:

Берем какуюнить линукс машину и делаем из него CA.

ssh-keygen -t rsa -b 4096 -f ~/.ssh/ssh_ca -C "SSH Certificate Authority"

Описывать за что отвечают параметры не буду, всё это уже разжевали, читай посты по тегу #linuxfactory

По итогу получаем 2 ключа, ssh_ca (приватный) и ssh_ca.pub (публичный).

Дальше чтобы сервера могли доверять сертификатам, подписанным нашим CA, добавляем публичный ключ CA (ssh_ca.pub) на все 100500 серверов.

Тут уже сам автоматику организуй, либо баш скриптом, либо ансибл ролью либо еще как-то. Попробуй ради интереса изобрести своё решение.

Покажу в рамках одного сервера:

scp ~/.ssh/ssh_ca.pub user@bashdays:/etc/ssh/

Теперь заходим на этот самый сервер куда ты скопировал публичную часть ключа.

Открываем конфиг /etc/ssh/sshd_config

И пишем в него:

TrustedUserCAKeys /etc/ssh/ssh_ca.pub

Не забываем хуйнуть:

sudo systemctl restart ssh

Теперь сервер будет доверять сертификатам подписанным CA.

Ну а чтобы пользователь мог подключаться по сертификату, подписываем его публичный ключ с помощью CA.

Для этого копируем на CA машину свой локальный публичный ключ. Тот что у тебя на машине лежит и который ты прописывал ранее в authorized_keys на удаленных серверах.

Подписываем публичный ключ и превращаем его в сертификат.

ssh-keygen -s ~/.ssh/ssh_ca -I "user_cert" -n user -V +1w /tmp/user_key.pub

В ответ получаем нечто такое:

Signed user key /tmp/user_key-cert.pub: id "user_cert" serial 0 for username valid from 2025-02-16T12:02:00 to 2025-02-23T12:02:59

И в папке /tmp появляется файл user_key-cert.pub

➡️ Важно. При подписании ключа, указывай валидного юзера под которым будешь подключаться, иначе нарвешься на ошибку:

 error: Certificate invalid: name is not a listed principal

Забираем себе на локальную машину подписанный ключ и пробуем подключиться:

ssh -i ~/.ssh/id_rsa -o CertificateFile=~/.ssh/user_key-cert.pub root@bashdays.com

Вуаля, я залетаю на сервер с подписанным ssh ключом, а на удаленном сервере вижу в логах:

2025-02-16  sshd[958704]: Accepted publickey for root from 11.11.11.11 port 35528 ssh2: RSA-CERT SHA256:Q4SKZ5cRycm79w0SyvRhAQR8 ID user_cert (serial 0) CA RSA SHA256:PtNBUw/+4/gGz4rc/ybu/uNHngcI

Если что-то не получается или не даёт зайти, пиздуешь на сервер к которому подключается и смотришь логи var/logs/auth.log. В этом файле тебе очень информативно подскажут что погуглить.

И да, на удаленном сервере можно снести файл ~/.ssh/authorized_keys от тебе больше не пригодится. Потому что сервак начинает доверять всем ключам, которые подписаны через CA.

Ну а теперь давай отзовем сертификат с ключа

На сервере к которому ты настраивал подключение:

touch /etc/ssh/revoked_certs

В файле /etc/ssh/sshd_config добавляем:

RevokedKeys /etc/ssh/revoked_certs

Добавляем серт в этот файл с отзывами:

ssh-keygen -k -f /etc/ssh/revoked_certs -z 1 user_key-cert.pub

Всё, теперь если попробуем подключиться к серверу, нас пошлют нахуй.

Выглядит все это конечно пиздец крипово, но при правильной автоматизации этого процесса у тебя получится достаточно гибкий инструмент.

Завтра про Vault Hashicorp расскажу, в нем все проще делается

tags: #linux #devops #linuxfactory
—
🔔 @bashdays➡️ @gitgate