ssh с ключом и паролем от сервера?
Jan. 29th, 2017 08:48 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netch80Хочется странного. При стандартной авторизации ssh по ключу есть кодовая фраза на стороне клиента. При этом он может менять её, отдавать ключ другому, контроль доступа слабоэффективен (по ip не годится, если ip может меняться)...
Вот если бы ключ принимался, но при этом сервер требовал дополнительный пароль. После успешного входа - попадает в полноправного пользователя (но, если не знает основной пароль пользователя, не может управлять доступом).
Для самого ssh можно к ключу добавить forced command (типа "ask-password foo"), но дальше пароль должен попросить кто-то другой. Причём желательно, чтобы управление доступом тут (какие есть дополнительные пароли (названия - ключи к словарю) и сами пароли) было доступно пользователю не по умолчанию, а через свой основной пароль.
Один вариант реализации понятен - вход в дополнительного системного пользователя, который имеет право sudo su в основного. Но это очень громоздко и требует странных подпорок. А более прямо?
Я бы накостылял что-то в духе:
1. /var/lib/add_pass/$user/$key - хэш пароля
2. /usr/lib/add_pass/check $key - forced command для ключа, проверяет пароль, для доступа к п.1 требует suid или лучше sgid.
3. /usr/lib/add_pass/control - средство управления - тоже шлюз привилегий.
Как защитить authorized_keys?
Или убедите, что это всё бесполезно, если вообще кого-то пускаем шеллом :)
Вот если бы ключ принимался, но при этом сервер требовал дополнительный пароль. После успешного входа - попадает в полноправного пользователя (но, если не знает основной пароль пользователя, не может управлять доступом).
Для самого ssh можно к ключу добавить forced command (типа "ask-password foo"), но дальше пароль должен попросить кто-то другой. Причём желательно, чтобы управление доступом тут (какие есть дополнительные пароли (названия - ключи к словарю) и сами пароли) было доступно пользователю не по умолчанию, а через свой основной пароль.
Один вариант реализации понятен - вход в дополнительного системного пользователя, который имеет право sudo su в основного. Но это очень громоздко и требует странных подпорок. А более прямо?
Я бы накостылял что-то в духе:
1. /var/lib/add_pass/$user/$key - хэш пароля
2. /usr/lib/add_pass/check $key - forced command для ключа, проверяет пароль, для доступа к п.1 требует suid или лучше sgid.
3. /usr/lib/add_pass/control - средство управления - тоже шлюз привилегий.
Как защитить authorized_keys?
Или убедите, что это всё бесполезно, если вообще кого-то пускаем шеллом :)
no subject
Date: 2017-01-29 10:20 am (UTC)no subject
Date: 2017-01-29 02:27 pm (UTC)no subject
Date: 2017-01-29 04:46 pm (UTC)no subject
Date: 2017-01-29 11:28 am (UTC)ну и chattr на эти файлы
no subject
Date: 2017-01-30 12:26 pm (UTC)no subject
Date: 2017-01-30 05:51 pm (UTC)no subject
Date: 2017-01-29 12:26 pm (UTC)А вообще это всё баловство. Надо представить себе модель угроз и отталкиваться от неё.
Upd.: может, OTPW?
no subject
Date: 2017-01-29 02:26 pm (UTC)Ну вот в том и вопрос. Нет ли тут чего-то такого, что вообще сведёт всю идею на нет.
> может, OTPW?
Честно - не нравится. Это уже немного другой случай.
no subject
Date: 2017-01-30 09:04 am (UTC)Так и пароль отдать другому может, в чём разница-то?
> контроль доступа слабоэффективен (по ip не годится, если ip может меняться)...
Что такое "контроль доступа"? От чего вообще защищаемся, непонятно.
no subject
Date: 2017-01-30 12:25 pm (UTC)Очевидно, от подделок под себя любимого.
> Так и пароль отдать другому может, в чём разница-то?
При захвате содержимого клиентской машины пароля там не будет.
no subject
Date: 2017-01-30 12:56 pm (UTC)