.ssh/authorized_keys

Прочитал наискосок. Если ты запустил вредоносный код от своего юзера, то уже ничто не поможет.

Это понятно. Но если они добавят свое в authorized_keys то потом можно будет потихоньку юзать, а если пароль у юзера сменят то это уже быстрее всплывет.

Ничто не безопасно, если оно УЖЕ на твоей машине.

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

если они добавят свое в authorized_keys

А если оно доберётся до рута и подменит бинарь sshd, то тебя вообще ничего не спасёт. А если подменит systemd, то ты этого даже не заметишь никогда, потому что и журнал и всё остальное — под его контролем.

Раньше вобще считалось, что оставлять торчащий наружу ssh-порт небезопасно и всё. Не важно, ключ или пароль. Нестандартный порт + knockd или ещё что. И какой-нибудь анализатор логов, если на машину можно заходить со всех ip-адресов. Чтобы

потихоньку юзать

долго не получалось бы.

Стоп. Добирание до рута от юзера это уже дыра в системе, в статье же банальная работа юзера …

Да я все понимаю. По сути я просто задумался что password все таки безопаснее ключа, до сегодня я думал по другому.

У меня authorized_keys под опекой оркестратора, так что подмена идёт в /dev/null as soon as possible. Плюс я никогда не даю юзеру прав больше, чем ему требуется и никогда нигде не свечу свои пароли (они даже из буфера обмена стираются сразу после использования), даже сам их не знаю, чтобы уж наверняка.

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

Абсолютной безопасности не бывает.

Добирание до рута от юзера это уже дыра в системе

И systemd и sudo позволяют кэшировать пароль и не запрашивать его снова какое-то время. Я уверен что вредоносы умеют этим пользоваться, пусть и не все.

Удобство всегда было противоположностью безопасности.

а в том что админ это каким-либо образом допустил.

А что делать, если NPM помойки протроянены 24/7? Не пользоваться не вариант обычно - работать то надо.

Кому нужен рут вашего локалхоста, когда самое интересное - это ключи, куки и пароли из браузера?

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

Сам я на NodeJS не пишу (по крайней мере пока), а левые проекты запускаю в виртуалке, причём каждый от отдельного пользователя, которым su запрещён, а sudo в виртуалке не установлен. Ну и systemd во FreeBSD нет, так что в большинстве случаев вредоносы умрут от поноса. (%

Даже без виртуалки можно обойтись, создав пользователя с минимальными правами, от которого запускается только код на NodeJS, а reverse proxy и затыкание лишних портов — уже отдельно и этому пользователю недоступно.

А ботнеты из локалхостов не строят?

Для этого рут не нужен.

Нафейхоа нужно запускать NodeJS на локалхосте? И уж тем более для работы…

Обычно это какие-то веб-сервисы, которые supposed to be торчать наружу, и сервить их с десктопа/ноута — тупняк. Даже если нет сервера, можно использовать дноплатник, специально для этого заведённый, чтобы как минимум отделять мух от котлет.

ключи, куки и пароли из браузера

Хранить ключи без пассфразы и уж тем более пароли в браузере… штош, это целевая аудитория таких вредоносов, приятного им аппетита. (%

Мне например на работе надо ансиблем ходить. А там центось с древним питоном, с которым не работает ансибль из репозиториев. Приходится ставить из е******о pip. И че делать?

даже сам их не знаю

Талибану вас всех сдать - все пароли вспомните

Вообще, в теории поможет selinux, но им как правило никто не умеет пользоваться.

КОНТЕЙНЕРЫ
О
Н
Т
Е
Й
Н
Е
Р
Ы

Что контейнеры? Мне не за свой локалхост страшно.

Это всякие кубернетесы с докерами и подманами. Изолированная среда. Прям на хостах в производстве уже мало кто гоняет.

Ну а тут гоняют, наравне с кубодокерами. Меня не спрашивали, когда это строили, знаешь ли.

Вот за это я Ansible и не люблю, кстати.

Недавно кто-то жаловался, что Ansible с Bitrix подрались и пришлось руками что-то там разруливать в обход менеджера пакетов дистрибутива.

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

И че делать?

Жаловаться. Если не поможет — откатывать Ansible на тот, который совместим с Python из штатного репозитория дистрибутива. Зашевелятся — тыкать носом в жалобы и список уязвимостей.

Жаловаться

На свой же локалхост? Пока держу venv с уже опробованным кодом.

все пароли вспомните

Нельзя вспомнить то, чего не знаешь. 🤷‍♂️

Талибану вас всех сдать

Так и запишем: superuser работает на Талибан. (%

Пароль это образно, выдашь как влезть в ПК

Жаловаться

На свой же локалхост?

Так на работе, или на своём локалхосте? Это две принципиально разные вещи.

У меня на домашней инфре (полноценный сервер с кучей виртуалок и контейнеров) вообще самописный оркестратор без зависимостей (ну почти, ему нужен только git, а на linux — coreutils ещё).

Ансибль то по PUSH модели работает, на локалхосте то есть. И работу работаю я с локалхоста, очевидно.

password все таки безопаснее ключа

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

В теории, ключи можно не запрещать полностью, а прописать ″AuthorizedKeysCommandUser″. Правда, не знаю, не искал, что туда прописать, чтобы у каждого пользователя было локальное шифрованое хранилище ключей...

Ничто не безопасно, если оно УЖЕ на твоей машине.

FIDO2 ?

когда самое интересное - это ключи, куки и пароли из браузера?

И вообще в оперативной памяти, сканируемой из буткита/руткита?

Вообще, в теории поможет selinux,

От руткита?

однако пароль подобрать проще чем ключ :) и подбирателей пароля ssh по интернету бегают кучами, постоянно вижу в логах. а вот побирателей ключей ssh чет ни одного не видел (хотя и не искал)
если есть подозрения в дырявости машины, то сделай ключ с паролем. выдернуть пароль для ключа очень и очень сложно.
абсолютным средством конечно же будет аппаратный токен с аппаратным набором пароля или хотя бы кнопкой разрешения.

Шёл 2025-ый год, по прежнему не пользовались ни FIDO2, ни PKCS11.

Трояны очень любят пароли из головы. Голова ведь их вводит в конечном итоге внутрь системного блока, а FIDO2 и токены PKCS11 со своими ключами так никогда не поступают (в системный блок они никогда не попадают - ни в RAM, ни в CPU).

аппаратный токен с аппаратным набором пароля или хотя бы кнопкой разрешения.

Лучшее решение. Миниклавиатура или кнопка ессно должна быть на борту самого токена.

То есть код, пишущий что-то в authorized_keys есть, а бота, который стучит нету?

подбирать/перебирать? Подобрать ключ просто, если он на флешке, которая выпала из кармана.

сделай ключ с паролем.

Я понимаю, что «Ъ» по ссылкам не ходят, но можно было понять, что тут исходный контекст топика — это код, который сам пишет в .ssh/authorized_keys Куда там прописывать пароль для ключей, заносимых в этот файл?

токен с аппаратным набором пароля или хотя бы кнопкой разрешения.

То есть, на каждый локал-хост, куда я хочу подключится, нужно прилепить токен, да ещё звонить по телефону, чтобы обслуга в нужный момент кнопку разрешения нажимала? Не дороговато будет?

У меня есть удалённая виртуалка, там я запускаю скрипт, который должен подключиться к моему домашнем компу и что-то сделать. Куда PKCS11 прикручивать?

Зачем такие сложности, если всё плейнтекстом на диске лежит?

ни PKCS11.

Криво, косо, через страдания.

Да, в том числе. Selinux может порезать доступ ко всему. Т.е. допустим, у тебя есть файл. Он доступен для user:group. Например, vasya:vasya. Получается что, если vasya запустит вирусню, всё что доступно Васе, становится доступным руткиту? А вот и нет. А вот если есть selinux, то приложения запускаются в контексе. А если файл в другом контексте, то ничего не выйдет. Отака ерунда.

У меня есть удалённая виртуалка, там я запускаю скрипт, который должен подключиться к моему домашнем компу и что-то сделать.

А зачем так делать?

Зачем такие сложности, если всё плейнтекстом на диске лежит?

1. Диски некоторые шифруют.

2. Некоторые пользуются современными хранилками паролей даже с привязкой к аппаратным токенам для открытия ключницы, и с автоматическим вытиранием нешифрованного пароля из RAM-ы.

Криво, косо, через страдания.

Почему?

Автоматизация, чтобы работу выполнял скипт.

получается сабж менее безопасен чем вход по паролю и заперт по ключу.

нет

Автоматизация, чтобы работу выполнял скипт.

Почему он на удалённой машине, а не на паблик гитхабе (гитопс и смузи)?

Что-то я забыл, а пользователь (не root) может указать в каком контексте запускать скаченый npm?

Если добирешся до рута то уже можно и не прятатся, клавиатуру юзеру просто отключи чтобы он чего не нажал, и хер на мониторе нарисуй чтобы чего не увидел -)

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