SSHトンネリングエラー：「チャネル1：オープンに失敗しました：管理上禁止：オープンに失敗しました」

このsshトンネルを開くと：

ssh -nXNT -p 22 localhost -L 0.0.0.0:8984:remote:8983

localhost：8984で実行されているHTTPサーバーにアクセスしようとすると、次のエラーが表示されます。

channel 1: open failed: administratively prohibited: open failed

このエラーは何を意味し、どのマシンで問題を修正できますか？

チャネル1：オープンに失敗しました：管理上禁止：オープンに失敗しました

上記のメッセージは、SSHサーバーがサイドチャネルを開くというSSHクライアントのリクエストを拒否していることを示しています。これは通常、転送されたデータをフェリーするためにSSHストリームの個別のチャネルが必要なため-D、-Lまたはから発生-wします。

を使用しているため-L（にも適用可能-D）、SSHサーバーがこの要求を拒否する原因となっている問題の2つのオプションがあります。

• AllowTcpForwarding （スティーブブゾナスが述べたように）
• PermitOpen

これらのオプションはにあります/etc/ssh/sshd_config。以下を確認する必要があります。

• AllowTCPForwarding 存在しないか、コメント化されているか、または yes
• PermitOpen存在しない、コメント化されている、またはany[1]に設定されている

さらに、SSHキーを使用して接続している場合、SSHキーに対応するエントリにor ステートメント~/.ssh/authorized_keysがないことを確認する必要があります[2]。no-port-forwardingpermitopen

特定のコマンドには関係ありませんがPermitTunnel、-wオプションを使用しようとしている場合は、このトピックにも多少関連があります。

[1] sshd_config(5)マンページの完全な構文。

[2] authorized_keys(5)マンページの完全な構文。

非常に奇妙なケースでは、ローカルトンネルを作成しようとしたときにこのエラーも発生しました。私のコマンドは次のようなものでした：

ssh -L 1234:localhost:1234 user@remote

問題は、リモートホストに/etc/hosts「localhost」のエントリがないため、sshサーバーがトンネルの設定方法を認識しなかったことです。この場合、非常にわかりにくいエラーメッセージ。やっと理解できてよかった。

レッスン：トンネルのターゲットホスト名が、DNSまたはを介してリモートホストによって解決可能であることを確認します/etc/hosts。

少なくとも1つの答えは、マシンの「リモート」が何らかの理由でsshに到達できないことです。エラーメッセージはばかげています。

サーバーで「リモート」を解決できない場合、そのエラーが発生します。IPアドレスに置き換えて、問題が解決するかどうかを確認してください...

（基本的にニールの答えと同じ答え-しかし、それが私の側の問題であることは確かにわかりました）[ ~/.ssh/configファイルにマシン名のエイリアスがありました-そして、リモートマシンはそのエイリアスを何も知りませんでした...

このエラーは、sshオプションControlPathをControlMaster使用し、複数のクライアント接続間（1つのクライアントから同じuser @ serverへ）で再利用される1つのソケット接続を共有する場合に明確にポップアップします。開きすぎると（つまり、私の場合は〜20接続）、このメッセージが生成されます。以前の接続を閉じると、上限まで再度新しいものを開くことができます。

「管理上禁止」は、特定のICMPメッセージフラグであり、「管理者はこの接続を明示的にブロックする」ことを意味します。

iptablesの設定を確認してください。

同様の問題

別の可能なリード

で同じ問題が発生し~/.ssh/authorized_keysましたpermitopen。

autosshトンネルの作成に使用するとき、2つのポートが必要です。

• 接続用（10000）、
• 1つは監視用（10001）。

クライアント側

これにより、モニタリングポートで同様の問題が発生しました。

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa user@remote

そのメッセージがありました（10分後）：

channel 2: open failed: administratively prohibited: open failed

リモート側

私が/var/log/auth.log含まれています：

Received request to connect to host 127.0.0.1 port 10001, but the request was denied.

私の~/.ssh/authorized_keys（リモート側）でこれがありました：

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="localhost:10000",permitopen="localhost:10001" ssh-rsa AAAA...

解決方法

localhostインスタンスを127.0.0.1次のものに置き換えることでこれを解決しました：

command="/home/user/tunnel",no-X11-forwarding,no-pty,permitopen="127.0.0.1:10000",permitopen="127.0.0.1:10001" ssh-rsa AAAA...

SSHはのlocalhostショートカットであるため127.0.0.1、SSHは理解していないようです。したがって、メッセージauth.logと管理上禁止されているメッセージです。

ここで私が理解しているのは、管理上「サーバー側の特定の構成による」という意味です。

また、これ/etc/sshd_configは

AllowTcpForwarding no 

セットする。yesTCP転送を許可するように切り替えます。

私の場合、次のものに置き換える必要localhostがあり127.0.0.1ました。

ssh -L 1234:localhost:3389 user@remote

それを機能させるために。

SSHトンネリング経由でAWS EC2に接続する際のrdesktop -L localhost:1234 Amazonの指示に従うことを試みていました。私は/etc/ssh/sshd_config、クライアントとサーバーの両方がUbuntu 16.04 LTSを実行するように、最高の投票による回答ごとに変更しようとしました。両側にあることも確認しlocalhostまし/etc/hostsた。

sshコマンド自体を次のように変更するまで、何も機能しませんでした。

ssh -L 1234:127.0.0.1:3389 user@remote

明確な答えを見つけるには、いくつかのトラブルシューティングアクティビティが必要です。

• ユーザーのssh構成でポート転送が有効になっていることを確認し、
• sshの冗長性を有効にする（-v）、
• ローカルホスト上のsshログとリモートホスト上の安全なログを確認し、
• 別のリモートポートをテストします。
• iptablesの設定を確認してください（Shadurが言ったように）。

リモートを-Lパラメーターに入れることでこのエラーが発生しました。また、0.0.0.0は冗長であり、同じ結果で省略することができます。-gを追加して動作させる必要があると思います。

これは私がトンネリングに使用するラインです： ssh -L 8983:locahost:8984 user@remote -4 -g -N

-4 tells to use only ipv4
-g Allows remote hosts to connect to local forwarded ports.
-N Do not execute a remote command.  This is useful for just forwarding ports (protocol version 2 only). I use this to clog the terminal so I don't forget to close it since generally I need the tunnels temporarily.

これは、ローカル側のポートにバインドできないことによっても発生する可能性があります。

ssh -Nn -L 1234:remote:5678 user@remote

このコマンドは、ローカルマシンのリスニングポート1234をバインドしようとしています。このポートは、リモートマシンのポート5678のサービスにマップします。

ローカルマシンのポート1234が別のプロセス（バックグラウンドssh -fセッションなど）で既に使用されている場合、sshはそのポートでリッスンできず、トンネルは失敗します。

問題は、このエラーメッセージがいくつかのことのいずれかを意味し、「管理上禁止」が間違った考えを与える場合があることです。そのため、DNS、ローカルとリモート間のファイアウォール、およびsshd_configのチェックに加えて、ローカルポートが既に使用されているかどうかを確認してください。つかいます

lsof -ti:1234

1234で実行されているプロセスを把握するために、他のユーザーが所有するプロセスをリストするにはlsofにsudoが必要になる場合があります。その後、使用することができます

ps aux | grep <pid>

そのプロセスが何かを知るために。

これをすべて1つのコマンドで取得するには：

ps aux | grep "$(sudo lsof -ti:1234)"

トンネルを作成しようとしたときに同じメッセージが表示されました。リモート側のDNSサーバーに問題がありました。仕事に戻ったときに問題は解決しました。

これがDNSの問題であると誰も言及していないことに非常に驚いています。

journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to user@example.com: unknown host (Name or service not known)

remote解決できない場合、またはuser@ポートフォワードロジックに追加した（ここでは機能しない）ここでやったように、未知の構文を入力した場合に表示されることがあります。

私の場合、この問題は、サーバーがアカウントのパスワード変更を強制することを目的としているときに、シェルアクセスなしでトンネルを要求したことが原因でした。シェルがないため、それを見ることができず、エラーのみを受け取りました

channel 2: open failed: administratively prohibited: open failed  

私のトンネル構成は次のとおりでした。

ssh -p [ssh-port] -N -f -L [local-port]:127.0.0.1:[remote-port]
[server-address]

サーバーに直接ログインするときにエラーが表示されました（-N -fなし）：

WARNING: Your password has expired. You must change your password now
and login again!

シェルアクセスでログインし、パスワードを変更して、問題を解決しました。その後、シェルアクセスなしでトンネルを再び使用できます。

SFTPを使用した接続のみが許可されているユーザーとSSH経由で接続しようとすると、この問題が発生しました。

たとえば、これはサーバーにありました/etc/ssh/sshd_config：

Match group sftponly
    ForceCommand internal-sftp
    ChrootDirectory /usr/chroot/%u
    [...]
Match

したがって、この場合、SSHを使用するには、同等のsftponlyグループからユーザーを削除するか、SFTPに限定されないユーザーを使用して接続する必要があります。

移行先の/etc/resolv.confサーバーで空になっているかどうかを確認しますssh。何回か、これが空の/etc/resolv.confファイルに関連していることがわかりました

root以外の場合は、パブリックホスト名で一部pingまたはtelnet（80）を試してサーバーを確認できます。

root@bananapi ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

ネームサーバーレコードを追加した後/etc/resolv.conf：

root@bananapi ~ # telnet www.google.com 80
Trying 74.125.195.104...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.0

HTTP/1.0 302 Found
Location: http://www.google.ro/?gws_rd=cr&ei=8fStVZ-hMIv6UvX6iuAK

ただし、/etc/resolv.conf空になった理由も確認する必要があります（これには、通常、サーバー上のdhcpクライアントによってネームサーバーレコードが入力されます（該当する場合）。

DebianにSSHを調整しているときに同じメッセージが表示されていました。リモートシステムに空き領域がないことが判明しました。ディスク領域を解放して再起動すると、トンネルが機能し始めました。

私はcygwinでこのエラーを見ましたが、これはLinuxにも当てはまるはずで、私にとってはうまくいきました。私の場合、私はssh -ND *：1234 user@127.0.0.1を実行し、ブラウザをそのcomp-socksサーバーに接続したときに閲覧しましたが、そのsshコマンドを実行したcompでエラーが表示されました各リクエストのコンソール-少なくとも1つのサイトについては、ブラウザはプロキシを介してそれを取得したか、または少なくとも私が見た限りではそうでした。ただし、この変更を行うと、失敗したメッセージは削除されます

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-failed-administratively-prohibited-open-failed/

While trying to do some SSH tunneling, here is the error I got :
channel 3: open failed: administratively prohibited: open failed
To avoid this kind of error, have a look at the SSH daemon configuration file :
/etc/ssh/sshd_config
Add possibly the following line :
root@remote-server:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
root@remote-server:~# service ssh restart
or

root@remote-server:~# /etc/init.d/ssh restart

もう1つのシナリオは、アクセスしようとしているサービスが実行されていないことです。先日、この問題に遭遇しましたが、接続しようとしていたhttpdインスタンスが停止していたことを覚えているだけです。

問題を解決するための手順は、最も簡単なものから始めて、他のマシンに移動し、ローカルに接続できるかどうかを確認してから、クライアントコンピューターに戻ります。少なくともこれにより、通信が行われていない時点で解決することができます。他のアプローチを取ることもできますが、これは私のために働いたものです。

ルーターのDNS Rebinding保護を確認してください。私のルーター（pfsense）では、デフォルトでDNS Rebinding Protectionが有効になっています。SSHで「チャンネルを開く：管理上失敗する：開くことができない」エラーが発生していました

私は同じ問題を抱えていて、それがDNSであることに気付きました。トラフィックはトンネルされますが、DNS要求番号はありません。DNSホストファイルを手動で編集し、アクセスするサービスを追加してみてください。

私の場合：

$ssh -D 8081 localhost >>log1.txt 2>&1 &

----wait for 3 days

$tail -f log1.txt
channel 963: open failed: connect failed: Connection refused
channel 963: open failed: connect failed: Connection refused
channel 971: open failed: connect failed: Connection reset by peer
channel 982: open failed: connect failed: Connection timed out
channel 979: open failed: connect failed: Connection timed out
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed
accept: Too many open files
channel 1019: open failed: administratively prohibited: open failed

$ps  axu | grep 8081
root       404  0.0  0.0   4244   592 pts/1    S+   05:44   0:00 grep --color=auto 8081
root       807  0.3  0.6   8596  6192 ?        S    Mar17  76:44 ssh -D 8081 localhost

$lsof -p 807 | grep TCP
ssh     807 root 1013u  sock     0,8      0t0 2076902 protocol: TCP
ssh     807 root 1014u  sock     0,8      0t0 2078751 protocol: TCP
ssh     807 root 1015u  sock     0,8      0t0 2076894 protocol: TCP
.....

$lsof -p 807 | wc -l
1047

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   malcolm-desktop

$ssh localhost
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-53-generic i686)

----after restart ssh -D 8081 localhost
$ lsof -p 1184 | grep TCP
ssh     1184 root    3u  IPv4 2332193      0t0   TCP localhost:37742->localhost:ssh (ESTABLISHED)
ssh     1184 root    4u  IPv6 2332197      0t0   TCP ip6-localhost:tproxy (LISTEN)
ssh     1184 root    5u  IPv4 2332198      0t0   TCP localhost:tproxy (LISTEN)
ssh     1184 root    6u  IPv4 2332215      0t0   TCP localhost:tproxy->localhost:60136 (ESTABLISHED)
ssh     1184 root    7u  IPv4 2336142      0t0   TCP localhost:tproxy->localhost:32928 (CLOSE_WAIT)
ssh     1184 root    8u  IPv4 2336062      0t0   TCP localhost:tproxy->localhost:32880 (CLOSE_WAIT)

書きながら、私はこのエラーを得た。このエントリで私のブログを：

/etc/ssh/sshd_config 次のようなものがありました：

Match Group SSHTunnel_RemoteAccessGroup
    AllowTcpForwarding yes
    PermitOpen=sshbeyondremote.server.com:22

しかし、~/.ssh/config持っていた：

Host remote.server.com
  HostName remote.server.com
  Port 10022
  User useronremote
  IdentityFile ~/.ssh/keys/key1/openssh.keyforremote.priv
  LocalForward 2222 SSHBeyondRemote.server.com:22

SSHBeyondRemote.server.com:22とsshbeyondremote.server.com:22の大文字と小文字の違いに注意してください。

ケースを修正すると、この問題は見られなくなりました。

私が使用していた：

OpenSSHクライアントのバージョン：

• OpenSSH_7.2p2 Ubuntu-4ubuntu2.4、OpenSSL 1.0.2g 2016年3月1日

OpenSSHサーバーのバージョン：

• OpenSSH_7.6p1 Debian-4、OpenSSL 1.0.2n 7 Dec 2017

他の名前解決の原因：次のように、/ etc / hostsにサーバー名（localhostではなく）の誤ったIPアドレスがありました。

127.0.0.1     localhost
192.168.2.45  server.domain.com server

ただし、構成されたサーバーIP（およびhost / digコマンドで解決されたDNS名）は192.168.2.47でした。以前のIP再構成によって引き起こされた単純なタイプミス。/ etc / hostsを修正した後、トンネル接続は問題なく機能しました。

ssh user@server.domain.com -L 3456:127.0.0.1:5901

トンネルにlocalhostリテラルIPを使用しているときに、実際のIPが障害を引き起こしたのは奇妙です。ディストリビューション：Ubuntu 16.04 LTS。

私がそのメッセージを受け取った理由は最も一般的なものではありませんが、言及する価値があります。スクリプトによってトンネルのリストを生成し、列の表示を確保するために、最後の各バイトを2バイトで印刷しました。192.168.66.08へのトンネル転送を開こうとすると、常に失敗しました。「08」はgethostbyaddrによって無効な8進数として解釈されるためです:)

このメッセージには多くの根本原因が考えられます。私の場合、キーファイルを正しく提供していなかったため、リモートにアクセスできませんでした。

この-Lオプションは、暗黙的なSSHジャンプを追加します（効果的に、明示的なSSHホストを要塞/ジャンプサーバーとして使用します）。ジャンプを明示的に実行し、「proxycommand」を使用してターゲットマシンへのログインシェルを作成することにより、これをデバッグする方が簡単な場合があります。

これが機能したら、ターゲットマシンのポートに基づいてポート転送を実行localhostできます（それ自体にログインできると仮定）：

-N -L 1234:localhost:1234