компьютер (назовем его A) […] другой компьютер (назовем его B). […] Мне нужно было добавить открытый ключ A в файл authorized_keys ключей B.
Распространенной ситуацией является добавление открытого ключа конкретного пользователя A в файл auhorized_keys конкретного пользователя B. Это не ключ, представляющий весь компьютер A; Аналогично файл authorized_keys не принадлежит к целому B.
Вы , наверное , добавил открытый ключ некоторого пользователя alpha А в файле authorized_keys некоторого пользователя beta - B (два пользователя могут использовать один и тот же логин, они все еще находятся на разных машинах, так что давайте поддерживать различные имена alpha и beta
Мое решение: установите для beta оболочки входа в систему B значение /bin/false . Вы можете сделать это (на B) с помощью sudo usermod -s /bin/false beta .
Это приведет к следующим ограничениям:
beta не может вообще войти в B вообще; в частности, ssh beta@B от A никому не даст оболочки, несмотря на успех аутентификации SSH;- такие команды, как
ssh beta@B whatever что не получится;
- ни SCP, ни SFTP, пытающиеся получить доступ к учетной записи
beta - версии , не будут работать (см. этот комментарий).
Похоже, что у alpha нет возможности увидеть или изменить файлы в B. Однако в то же время:
любой, кто может авторизоваться как beta может использовать ssh -N для установки SSH-соединения с B без выполнения каких-либо команд; это пример команды alpha должна вызываться на A:
ssh -N -R 1234:127.0.0.1:22 beta@B
вам не нужно быть beta чтобы использовать туннель (хотя -R без указания адреса привязки будет связываться только с интерфейсом обратной связи B, поэтому вы должны быть на B, чтобы использовать туннель; см. также man 5 sshd_config, GatewayPorts опция).
Дополнительно проверьте параметры MaxSessions и PermitOpen в man 5 sshd_config. Я думаю, что если вы используете их правильно, то возможный злоумышленник, использующий секретный ключ alpha , не сможет "перехватить" слишком много портов на B.
