Как решить проблему “open failed: administratively prohibited: open failed” при использовании SSH-туннеля прокси.

Я использую SSH-туннель на Windows (с использованием Putty) уже какое-то время.

На Windows с Putty всё всегда нормально, но на Mac или Cygwin иногда появляется сообщение об ошибке:

open failed: administratively prohibited: open failed

Я полагаю, что вы отключили TCP-перенаправление на сервере. В файле конфигурации вашего сервера /etc/ssh/sshd_config убедитесь, что следующая строка отсутствует или закомментирована; если нет, закомментируйте её.

AllowTcpForwarding no

Существует более широкое обсуждение этой ошибки с SSH-туннелями на Unix StackExchange. В двух словах, это не специфическая ошибка; существует множество возможностей, которые следует исследовать.

Если в конфигурации sshd уже есть все параметры для включения перенаправления портов, но вы все равно получаете эту проблему, проверьте /var/log/secure на наличие чего-то вроде этого – sshd: error: connect_to XXX: unknown host (Name or service not known)

Если SSH-хост не может разрешить хост, к которому вы хотите туннелировать, он вернёт общую ошибку о том, что невозможно открыть канал.

Дважды проверьте имя хоста туннеля или разрешение DNS на SSH-сервере.

open failed: administratively prohibited: open failed

Это означает, что служба SSH (на удалённом сервере) не позволяет перенаправление SSH-агента (AllowAgentForwarding no).

Если вы не можете изменить конфигурацию на удалённом сервере, вы всё равно можете выполнить SSH на один сервер, а затем на другой.

Обычно вы могли бы использовать опцию ProxyJump в вашем .ssh/config, но в этом случае вы не можете.

Вы можете попробовать принудительно отключить перенаправление агента на вашем клиенте (ForwardAgent no), что, вероятно, не сработает.

Если вы хотите выполнить SSH на сервер Y через сервер X, то как обходное решение вы можете определить следующий раздел в файле конфигурации SSH:

Host remotehost
  ForwardAgent no
  HostName 192.168.X.IP
  RemoteCommand ssh 192.168.Y.IP
  RequestTTY yes

После загрузки вы можете просто выполнить: ssh remotehost.

_{Просто для истории, даже если это не полезно вам конкретно}

Ошибки выводятся в вашу консоль через stderr, так что если вы просто хотите игнорировать их, добавление 2>/dev/null в конец вашего вызова ssh будет работать идеально. Например:

ssh -C -D 3210 example@connexion 2>/dev/null

Это полезно, если прокси-туннель фактически работает нормально, но вы просто не хотите видеть ошибки.

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

У меня была проблема с аналогичными симптомами. Однако в конечном итоге моя проблема была связана с хранилищем и tcpforwarding с учётными данными, предоставленными хранилищем.

Когда вы создавали файл signed-cert.pub, как указано в документации, вы можете столкнуться с проблемами, потому что существует параметр permit-port-forwarding, который должен быть включён.

Проверьте сертификат, который вы создали с помощью хранилища, следующим образом:

ssh-keygen -Lf signed-cert.pub

Вы должны увидеть следующий результат:

signed-cert.pub:
        Type: [email protected] user certificate
        Public key: RSA-CERT SHA256:somehash
        Signing CA: RSA SHA256:somehash (using rsa-sha2-256)
        Key ID: "vault-token-somehash"
        Serial: somehash
        Valid: from 2024-01-01T14:44:04 to 2024-01-01T14:46:34
        Principals: 
                ubuntu
        Critical Options: (none)
        Extensions: 
                permit-port-forwarding
                permit-pty

В моём случае у меня не было включено permit-port-forwarding. Вы должны иметь что-то аналогичное следующему коду:

vault write ssh-client-signer/roles/my-role -<<"EOH"
{
  "algorithm_signer": "rsa-sha2-256",
  "allow_user_certificates": true,
  "allowed_users": "*",
  "allowed_extensions": "permit-pty,permit-port-forwarding",
  "default_extensions": {
    "permit-pty": "",
    "permit-port-forwarding": ""
  },
  "key_type": "ca",
  "default_user": "ubuntu",
  "ttl": "30m0s"
}
EOH

Вы можете подумать, что это то же самое, что и в документации, но в разделе default_extensions отсутствует свойство permit-port-forwarding (не знаю почему, так как они указали его в allowed_extensions).

Таким образом, в случае хранилища это не AllowTcpForwarding, что я продолжал видеть снова и снова при отладке.

Немного подробнее

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

Я использовал команду для подключения к ssh-хосту следующим образом:

ssh -v -i signed-cert.pub -i ~/.ssh/id_rsa -L 5432:localhost:5432 -N $SERVER_USER@$SERVER_ADDR

Команда работала правильно (я включил -v, чтобы дать больше информации), однако, когда я хотел подключиться (в моем случае с postgres) с помощью команды psql -h localhost -p 5432 -U username -W, я получал следующий ответ:

psql: error: connection to server at "localhost" (127.0.0.1), port 5432 failed: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

И когда я перехожу в терминал с командой ssh, я получал следующее:

debug1: channel 1: new [direct-tcpip]
channel 1: open failed: administratively prohibited: open failed
debug1: channel 1: free: direct-tcpip: listening port 5432 for localhost port 5432, connect from 127.0.0.1 port 32924 to 127.0.0.1 port 5432, nchannels 2

Это сообщение привело меня сюда, сюда, сюда и на множество других сайтов снова и снова.
После долгой отладки, обновления ОС, кучи изменений в конфигурации и около 4 дней, я осознал, что мог делать туннелирование с моего компьютера, даже с параметрами. После множества дополнительных тестов (играясь с /etc/hosts, ip4 и .ssh/authorized_keys модификациями) я понял, что мой компьютер переопределял -i signed-cert.pub -i ~/.ssh/id_rsa, когда у меня есть мой ssh ключ в .ssh/authorized_keys. Это был момент «Эврика», который привёл меня к следующей странице и этой части документации хранилища, в которой я задумался, почему в мире они не включают эту часть с самого начала? Они активируют расширение, но не включают его.

Другим важным аспектом были логи из /var/log/auth.log, упомянутые время от времени в моих поисках (этот лог принадлежит серверу).

Jan  1 14:10:15 ip-172-26-3-55 sshd[496555]: refused local port forward: originator 127.0.0.1 port 32924, target localhost port 5432

В любом случае, я пишу этот ответ с несколькими логами в надежде, что, если у кого-то будет та же проблема, они обратятся сюда, получив информацию из логов. Удачи!

Для меня проблема заключалась в том, что я указал -L 9999:[email protected]:8443 вместо -L 9999:192.168.0.111:8443