Linux ssh: разрешить аутентификацию с открытым ключом, не предоставляя пользователю права на чтение закрытого ключа

Пользователи, вошедшие в систему на моем Linux-сервере, должны иметь возможность подключаться по ssh к определенной удаленной машине с учетной записью по умолчанию. Аутентификация на удаленном компьютере использует открытый ключ, поэтому на сервере доступен соответствующий закрытый ключ.

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

Как я могу разрешить пользователям открывать ssh-соединение, не предоставляя им доступ для чтения к закрытому ключу?

Мои мысли пока таковы: очевидно, что исполняемый файл ssh должен уметь читать закрытый ключ, поэтому он должен запускаться под другим пользователем на сервере, который имеет такие права. Как только соединение ssh установлено, я могу «переслать» его пользователю, чтобы он мог вводить команды и взаимодействовать с удаленным компьютером.

Это хороший подход?
Как мне реализовать форвард?
Как пользователь может инициировать соединение (то есть выполнение ssh пользователем, имеющим права на чтение ключа)?
Есть ли лазейка в безопасности? - если пользователи могут выполнять ssh как другой пользователь, могут ли они тогда делать все, что мог другой пользователь (включая чтение секретного ключа)?

— Philipp
источник

Похоже, это дубликат stackoverflow.com/questions/9286622/protecting-ssh-keys

— wenzul

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

@ AndréDaniel, возможно, они могли бы войти на другой, совершенно не связанный компьютер, который также настроен на прием без пароля входа на сервер. Это единственная причина, по которой я могу придумать такую установку; если это не так, мне довольно любопытно, что это такое. (Не то чтобы это имело значение, правда.)

— David Z

@ DavidZ Я не совсем понимаю ... ключу нельзя доверять нигде, кроме как на целевом сервере, если IP-адрес совпадает с IP-адресом первого сервера (к которому подключаются пользователи).

Если вам нужно заблокировать его таким образом, я предполагаю, что вы приняли меры, чтобы запретить пользователям добавлять новые открытые ключи в ~/.ssh/authorized_keysфайл?

— mpontillo

Ответы:

Это одна из причин sudoсуществует. Просто позвольте вашим пользователям запускать одну единственную команду только с предварительно авторизованными параметрами командной строки, и наиболее очевидные обходные пути решены. например

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

устанавливает, sudoчтобы все члены группы usersмогли запускать команду ssh от имени пользователя some_uid, не вводя свой собственный пароль (или пароль учетной записи some_uid) при запуске:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Удалите NOPASSWD:опцию, чтобы пользователи вводили свои собственные пароли перед входом на удаленный хост.
Возможно, для удобства пользователей настройте псевдоним или скрипт-обертку, потому что sudoон довольно привередлив в использовании правильных аргументов.

— HBruijn
источник

Работает как шарм. Это также должно быть рекомендуемым ответом для дубликата, упомянутого wenzul.

— Филипп

Это похоже на хороший пример использования аутентификации на основе хоста. Это метод аутентификации , где SSH не использует отдельный пользователь «ы ключ на локальном компьютере (в этом случае, ваш сервер) для проверки подлинности; вместо этого он использует закрытый ключ хоста , который хранится в нем /etc/ssh/и который доступен только для чтения root.

Чтобы настроить это, вам нужно создать файл с именем .shostsна удаленной машине, в домашнем каталоге пользователя, в который вы хотите, чтобы люди входили в систему (не в ~/.ssh). Файл должен иметь содержимое

server-hostname +

где server-hostname- имя вашего сервера и +буквальный знак плюс, который служит подстановочным знаком, означающим «любой пользователь».

Кроме того, вы должны убедиться , что удаленный компьютер может проверить ключ хоста сервера, что означает ключ хоста сервера должен быть перечислены в любом /etc/ssh/ssh_known_hostsили ~/.ssh/known_hostsна удаленном компьютере. Если это не так, вы можете настроить его, войдя на удаленный компьютер и запустив

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

После настройки этих шагов вы можете полностью удалить закрытый ключ на сервере, если он вам больше не нужен. (И если вы это сделаете, вы всегда можете установить его на чтение rootили что-то еще.)

Вы также можете легко разрешить или запретить доступ определенных пользователей к удаленной машине. Смотрите man-страницы sshи hosts.equivдля деталей.

Одна из проблем этой настройки заключается в том, что пользователи, которые входят в систему на удаленном компьютере, могут вносить изменения .shosts. Они ничего не могут сделать, чтобы позволить им войти в систему на удаленном компьютере от имени другого пользователя, но они могли бы отключить собственный или чужой доступ к удаленному компьютеру. Если это проблема, вы можете сделать .shostsзапись доступной только для чего- rootлибо или чего-то еще - я не уверен, что это работает, но вы можете попробовать и посмотреть. (Другие методы, такие как метод с sudo, подвержены такому же риску, так как пользователь всегда может удалить ~/.ssh/authorized_keys.)

— Дэвид З
источник

+1; Я думаю, что эта опция обеспечивает хорошую гибкость, в случае, если пользователю необходимо использовать функции SSH, отличные от терминала, такие как переадресация портов, безопасное копирование и т. Д. Даже альтернативный клиент SSH должен работать. sudoВариант может быть лучше для заблокированной среды, хотя ...

— mpontillo