netch80: (Default)
[personal profile] 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?

Или убедите, что это всё бесполезно, если вообще кого-то пускаем шеллом :)

Date: 2017-01-29 10:20 am (UTC)
From: [personal profile] dsfhjkl
а как потом застраховаться от дерти ков? Ридонли если только.

Date: 2017-01-29 04:46 pm (UTC)
From: [personal profile] dsfhjkl
иногда патчи опаздывают.

Date: 2017-01-29 11:28 am (UTC)
dmarck: (Default)
From: [personal profile] dmarck
AuthorizedKeysFile /etc/ssh-keys/%u


ну и chattr на эти файлы

Date: 2017-01-30 05:51 pm (UTC)
dmarck: (Default)
From: [personal profile] dmarck
это немножко ортогонально: при успешной атаке на remote login по крайней мере невозможно будет расширить списки доступа

Date: 2017-01-29 12:26 pm (UTC)
kastaneda: (Default)
From: [personal profile] kastaneda
У меня были похожие тараканы в голове. Вместо sudo su, выполняемого от «промежуточного» пользователя, можно выполнять на сервере ssh конечный_пользователь@localhost + ещё одна passphrase (для ключа промежуточного пользователя).

А вообще это всё баловство. Надо представить себе модель угроз и отталкиваться от неё.

Upd.: может, OTPW?
Edited Date: 2017-01-29 12:29 pm (UTC)

Date: 2017-01-30 09:04 am (UTC)
dadv: (Default)
From: [personal profile] dadv
> При этом он может менять её, отдавать ключ другому,

Так и пароль отдать другому может, в чём разница-то?

> контроль доступа слабоэффективен (по ip не годится, если ip может меняться)...

Что такое "контроль доступа"? От чего вообще защищаемся, непонятно.

Date: 2017-01-30 12:56 pm (UTC)
dadv: (Default)
From: [personal profile] dadv
Так и пассфразы, которой клиентский приватный ключ зашифрован, там не будет.

Profile

netch80: (Default)
netch80

August 2017

S M T W T F S
  12345
67 89101112
13141516171819
20212223242526
2728293031  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 20th, 2017 09:15 pm
Powered by Dreamwidth Studios