Linux ssh: разрешить аутентификацию с открытым ключом, не предоставляя пользователю права на чтение закрытого ключа
Пользователи, вошедшие в систему на моем Linux-сервере, должны иметь возможность подключаться по ssh к определенной удаленной машине с учетной записью по умолчанию. Аутентификация на удаленном компьютере использует открытый ключ, поэтому на сервере доступен соответствующий закрытый ключ.
Я не хочу, чтобы пользователи сервера могли читать закрытый ключ. По сути, тот факт, что у них есть доступ к серверу, дает им право ssh, и удаление их с сервера также должно запретить подключение к удаленной машине.
Как я могу разрешить пользователям открывать ssh-соединение, не предоставляя им доступ для чтения к закрытому ключу?
Мои мысли пока таковы: очевидно, что исполняемый файл ssh должен уметь читать закрытый ключ, поэтому он должен запускаться под другим пользователем на сервере, который имеет такие права. Как только соединение ssh установлено, я могу "переслать" его пользователю, чтобы он мог вводить команды и взаимодействовать с удаленным компьютером.
- Это хороший подход?
- Как мне реализовать форвард?
- Как пользователь может инициировать соединение (то есть выполнение ssh пользователем, имеющим права на чтение ключа)?
- Есть ли лазейка в безопасности? - если пользователи могут выполнять ssh как другой пользователь, могут ли они тогда делать все, что мог другой пользователь (включая чтение секретного ключа)?
2 ответа
Это одна из причин 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.)