Неправильное использование параметра экрана -X с двумя значениями

В качестве альтернативы вы можете добавить префикс «from=ip.address.of.gateway.org» к ключу в авторизованном файле ключей _по адресу topsecret@remote.org, чтобы ключ работал только в том случае, если соединение происходит из системы шлюза.

Подробнее см. "man sshd".

Другой возможностью может быть использование закрытого ключа в отдельной учетной записи gateway.org, для которой отключен вход в систему. Назовем, например, эту учетную запись secretkeeper. Затем вы можете предоставить системным администраторам ограниченный доступ sudo к этой учетной записи, как этот(sudoersсинтаксис файла):

User_Alias ADMINUSERS=sysadmin1, sysadmin2, sysadmin3 #...etc.

ADMINUSERS ALL=(secretkeeper) /usr/bin/ssh secretremote

Попросите ~secretkeeper/.ssh/configуказать как можно больше параметров соединения для удобства пользователя -:

Host secretremote
    User topsecret
    HostName remote.org
    EscapeChar none
    IdentityFile /some/where/ts_key.priv

Теперь ваш sysadmin1и другие смогут запускать sudo -u secretkeeper ssh secretremote, но никакие другие команды через sudo(, если нет других sudoersопределений ).secretremote— это просто ключевое слово, которое может быть любым, если оно одинаково в файлах sudoersи ~secretkeeper/.ssh/config.

Поскольку команда, указанная в файле sudoers, включает параметры, будет принята только эта конкретная команда. Затем sudoзапустит команду (и только эту команду )от имени пользователя secretkeeper, который может прочитать файл конфигурации SSH и закрытый ключ, а затем установить соединение. А поскольку в сеансе sudoвыполняется только одна команда ssh, после отключения SSH сеанс sudoзавершится; не будет интерактивной оболочки, работающей от имени пользователя secretkeeper.

Конечно, все это требует, чтобы ваши системные администраторы не имели root-доступа к gateway.orgсистеме.