Serge Bobrovsky 

Книга 1. Гарри Поттер и Неорганический Интеллект.

...

1.5. Защитите удалённый компьютер.

Есть также децентрализованный Syncthing - совсем другая модель безопасности, чем SSH,

главный плюс -- очень надёжное шифрование трафика, TLS на уровне соединений, Device ID как ключ...

но как правило вы видны (на порту 22000) в т.ч. и Discovery-серверами, Web GUI Syncthing надо защищать (по дефолту без пароля!), ну и в целом, тот, кто получил доступ к вашим TLS-ключам Syncthing, как и в случае с SSH, сможет подключиться ко всем вашим устройствам.

Поэтому ориентируемся прежде всего на схему "SSH с ключами по IP".

Прекрасное: сверхкомпактная реализация лямбда-исчисления на Си, бинарник получился 29 байтов.

Ещё подобные красивые микро-штуки (интерпретатор брэйнфака, ...)

Она дала начало эпистемической логике (логике знания) с самореферентностью, мультимодальной логике и т.д.

И почему 126 гномов -- единственное решение.

Для плюсистов, кто активно юзает нейронки, самое оно.

1.3. Защитите удалённый компьютер.

...Однако оставляя консольный доступ, вы создаёте обходной путь мимо вашей строгой SSH-политики (ключи + IP). Если этот путь защищён слабо, все ваши усилия по SSH теряет смысл.

Слабый пароль на IPMI / iDRAC, устаревшая прошивка с известными уязвимостями, отсутствие двухфакторной аутентификации, консоль доступна без VPN, логирование не настроено...

Консольный доступ -- это просто страховка на случай катастрофы. Вы случайно заблокировали сами себя через sshd_config (опечатка, не те права :), потеряли приватный ключ, SSH-сервер висит или упал, атака вывела SSH из строя...

Без консоли в таких случаях сервер скорее всего придётся переустанавливать, и в целом всё на милость техподдержки (возможно, только через личное присутствие).

Правильные подходы:

Консоль только через VPN / выделенную сеть

Отдельные учётные данные, не совпадающие с SSH

Длинный пароль

Никакого root / admin / password

IPMI/iDRAC не должен смотреть в интернет

Двухфакторная аутентификация (если поддерживается)

Аудит и логирование всех входов в консоль

Мониторинг: оповещение при входе в консоль

1.3. Защитите удалённый компьютер.

Желательно разрешить вход только с определённых устройств (т.е. с конкретных приватных ключей).

Прямое ограничение по открытым ключам проще всего, но это не защищает от ситуации, когда кто-то получил доступ к вашему ноутбуку и скопировал приватный ключ + добавил свой публичный ключ на сервер.

Ограничение по IP + ключ - рекомендуемо.

Можно также ограничить ключ только выполнением определённой команды.

Самый надёжный (но сложный) путь -- централизованное использование сертификатов SSH. Сервер пускает только подписанные вами ключи, а при компрометации устройства вы отзываете его сертификат (без изменения authorized_keys) на всех серверах.

Всегда добавляем конечно логирование и мониторинг (обнаружение чужих ключей).

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

Что делать с украденным устройством? Удалите его открытый ключ из authorized_keys на сервере, а если используете сертификаты, добавьте серийный номер в RevokedKeys.

Резюме: юзаем только нужные устройства + только с разрешённых мест + только с конкретными ключами.

1.2. Защитите удалённый компьютер.

...Да, но если SSH-сервер перестанет отвечать или ключ будет утерян, вам капец :)

Оставьте консольный доступ (например, через IPMI / iDRAC / VPS-консоль) на такой случай.

НО! только если вы можете обеспечить для него уровень безопасности, не уступающий SSH. В идеале - консоль не имеет публичного IP, доступна только через КВН, защищена длинным паролем с 2FA, и каждый вход логируется.

(вы также можете использовать что-то вроде syncthing, чтобы гарантировать автоматическое отклонение любого трафика с устройств за пределами вашей сети синхронизации).

При настройке VPS безопасность - первоочередная задача. Поскольку на нём будет сосредоточена вся ваша профессиональная деятельность, вам не следует полагаться только на пароль. В идеале следует полностью отключить аутентификацию по паролю и полагаться только на SSH-ключи.

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

По хорошему, ограничение по ключу лучше расширить и ограничением по IP (если они динамические, хорошо бы добавить КВН:),

ещё сильнее подписывать клиентские ключи своим CA-сертификатом,

ну и ведём логирование и мониторинг чужих ключей.