Назад | Перейти на главную страницу

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

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

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

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

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

Это одна из причин 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 довольно разборчив в использовании правильных аргументов.

Это похоже на хороший вариант использования аутентификации на основе хоста. Это метод аутентификации, при котором 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 или что-то.)

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

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