Неделя только началась, а я уже заебался.

Как и обещал, публикую полезнейший пост от нашего коллеги Tagd Tagd 👇

Сегодня мы рассмотрим пару фишек настройки ssh среднего уровня.

БЕЗДУМНАЯ НАСТРОЙКА SSH по SSH МОЖЕТ ПРИВЕСТИ К ПОТЕРЕ КОНТРОЛЯ НАД СЕРВЕРОМ.

Чтобы минимизировать риски, я подключаюсь по ssh двумя сессиями.

В одной правлю sshd_config, другую оставляю для возможного отката при косяках, поскольку при перезапуске sshd с измененным конфигом текущие сессии сохраняются.
ㅤ
Наличие физического доступа к консоли - приветствуется.

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.1

Вы уже знаете, как настроить ключи. Они прописаны и работают!!!

Допустим в файле /etc/ssh/sshd_config

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

Там же есть опция AuthorizedKeysFile и обычно она закомментирована. Она указывает, где находится файл аuthorized_кeys.

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

Обычно это ~/.ssh/authorized_keys

делаем так:

sudo cp ~/.ssh/authorized_keys /etc/ssh/authorized_keys
sudo chown root:root /etc/ssh/authorized_keys
sudo chmod 644 /etc/ssh/authorized_keys

а в файле /etc/ssh/sshd_config

AuthorizedKeysFile %h/.ssh/authorized_keys /etc/ssh/authorized_keys

перезапускаем sshd:

systemctl restart sshd

Всё. С ключом, прописанным в /etc/ssh/authorized_keys можно заходить под любым пользователем, у которого прописан вменяемый shell, включая root!!!

Наличие ключей в домашней папке пользователя теперь необязательно.

Может быть удобно, если рулить сотней пользователей. Ну, или как дырочка.

Лучше, конечно задать:

PermitRootLogin no

Кстати, при данной опции попытки перебора по root попадают в log, но не отмечаются в lastb. Это так, к сведению.

Продолжение следует...

tags: #linux
—
🔔 @bashdays