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（Steve Buzonasが言及したとおり）PermitOpen
これらのオプションは_/etc/ssh/sshd_config_にあります。次のことを確認する必要があります。
AllowTCPForwardingが存在しない、コメント化されている、またはyesに設定されているPermitOpenが存在しない、コメント化されている、またはany[1]に設定されている
また、SSHキーを使用して接続している場合は、_~/.ssh/authorized_keys_のSSHキーに対応するエントリに_no-port-forwarding_またはpermitopenステートメントがないことを確認する必要があります[2]。
特定のコマンドには関係ありませんが、-wオプションを使用する場合、PermitTunnelオプションはこのトピックにもある程度関係します。
[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アドレスに置き換えて、問題が解決するかどうか確認してください...
（基本的にはNeilの回答と同じですが、私の側で問題であることが確かにわかりました）[~/.ssh/configファイルにマシン名のエイリアスがありましたが、リモートマシンはそのエイリアスを認識していませんでした。 ..
このエラーは、sshオプションControlPathとControlMasterを使用して1つのソケット接続を共有し、複数のクライアント接続間（1つのクライアントから同じuser @ serverへ）で再利用する場合に確実にポップアップします。開いている数が多すぎる（意味が何であれ、私の場合は最大20接続）と、このメッセージが表示されます。以前の接続を閉じると、上限まで、新しいものを開くことができます。
「管理上禁止」とは、具体的には「管理者がこの接続をブロックすることを明示的に望んでいる」という具体的なICMPメッセージフラグです。
Iptables設定を確認してください。
私の場合、localhostを127.0.0.1に置き換える必要がありました。
ssh -L 1234:localhost:3389 user@remote
それを動作させるために。
Amazonのrdesktop -L localhost:1234を試してみました SSHトンネリングを介してAWS EC2に接続する手順 。投票数の多い回答ごとに/etc/ssh/sshd_config（クライアントとサーバーの両方でUbuntu 16.04 LTSを実行）を変更しようとしました。 localhostが両側の/etc/hostsにあることも確認しました。
sshコマンド自体を次のように変更するまで、何も機能しませんでした。
ssh -L 1234:127.0.0.1:3389 user@remote
同様の問題
別の可能なリード
permitopenで~/.ssh/authorized_keysを使用すると同じ問題が発生しました。
autosshを使用してトンネルを作成するときは、2つのポートが必要です。
- 1つは接続用（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へのショートカットであることを理解していないようです。そのため、auth.logのメッセージと管理上禁止メッセージが表示されます。
ここで私が理解しているのは、管理上は「サーバー側の特定の構成による」という意味です。
これは、/etc/sshd_config持っている
AllowTcpForwarding no
セットする。これをyesに切り替えて、TCP転送を許可します。
-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構成でポート転送が有効になっていることを確認します。
- sshの冗長性を有効にする（-v）、
- ローカルホストのsshログとリモートホストの安全なログを確認します。
- 別のリモートポートをテストし、
- （Shadurが言ったように）iptables設定を確認してください。
これは、ローカル側のポートにバインドできないことが原因である場合もあります。
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)"
私の場合、問題は、サーバーが私のアカウントでパスワードの変更を強制することを目的としたときに、シェルアクセスなしでトンネルをリクエストしたことが原因でした。シェルがないため、それを見ることができず、エラーのみを受け取りました
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!
シェルアクセスでログインし、パスワードを変更することで問題を解決しました。その後、シェルにアクセスせずにトンネルを使用できます。
これがDNSの問題である可能性があると誰も言っていないことに私は非常に驚いています。
journalctl -f
channel 3: open failed: administratively prohibited: open failed
Mar 10 15:24:57 hostname sshd[30303]: error: connect_to [email protected]: unknown Host (Name or service not known)
これは、remoteが解決できない場合や、ここでuser@をポート転送ロジックに追加した（これはできない）のように、不明な構文を入力した場合に表示される可能性があります。作業）。
トンネルしようとしているときに同じメッセージが表示されました。リモート側のDNSサーバーに問題がありました。仕事に戻ったときに問題は解決しました。
SFTPを使用した接続のみが許可されているユーザーとSSH経由で接続しようとすると、この問題が発生しました。
たとえば、これはサーバーの/etc/ssh/sshd_config：
Match group sftponly
ForceCommand internal-sftp
ChrootDirectory /usr/chroot/%u
[...]
Match
したがって、この場合、SSHを使用するには、同等のsftponlyグループからユーザーを削除するか、SFTPに限定されていないユーザーを使用して接続する必要があります。
DebianへのSSHトンネリング中に同じメッセージが表示されました。リモートシステムに空き容量がないことが判明しました。一部のディスク領域を解放して再起動した後、トンネルは機能し始めました。
sshを使用するサーバーで/etc/resolv.confが空かどうかを確認します。数回、これが空の/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クライアントによってネームサーバーレコードが通常入力されます。
このエントリ を 私のブログ に書き込んでいるときにこのエラーが発生しました：
/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の case （大文字）の違いに注意してください。
ケースを修正した後は、問題を確認できなくなりました。
私は使っていました：
OpenSSHクライアントのバージョン：
- OpenSSH_7.2p2 Ubuntu-4ubuntu2.4、OpenSSL 1.0.2g 2016年3月1日
OpenSSHサーバーのバージョン：
- OpenSSH_7.6p1 Debian-4、OpenSSL 1.0.2n 2017年7月7日
私はcygwinでこのエラーを見ましたが、これはLinuxにも当てはまるはずで、私にとってはうまくいきました。私の場合、私はssh -ND *：1234 [email protected]を実行し、ブラウザをそのcomp-socksサーバーに接続するとブラウザしましたが、そのsshコマンドを実行したコンプでエラーが表示されましたリクエストごとのコンソール-少なくとも1つのサイトでは、ブラウザはプロキシを介してそれを取得したか、少なくとも私がメインの年齢で見た限りではそうでした。しかし、この変更を行うと、失敗したメッセージが取り除かれました
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つに少し追加：「DNS解決の失敗によりこのエラーが発生する可能性があります」-ホスト名のスペルが正しいことも確認してください。
1時間以上かけてすべてのssh設定をデバッグしようとしたところ、コマンドでamazonawsのスペルを間違えただけであることがわかりました。これは、上記のDNS解決失敗のメモと同等です。
Asus RT68Uルーターのファームウェア（Merlin Asus）には、SSHポート転送を許可する設定があり、これを有効にする必要があります。
動的ポート転送は、次のように設定されました： 動的トンネルのトラブルシューティング
私がそのメッセージを受け取った理由は、最も一般的なものではありませんが、言及する価値があります。スクリプトによってトンネルのリストを生成し、列の表示を確実にするために、最後の各バイトを2バイトで出力しました。 192.168.66.08へのトンネル転送を開こうとすると、「08」はgethostbyaddrによって無効な8進数として解釈されるため、常に失敗しました。
ルーターの DNS Rebinding 保護を確認します。私のルーター（pfsense）では、デフォルトでDNS再バインド保護が有効になっています。 SSHで「チャネルオープン：管理上禁止に失敗しました：オープンに失敗しました」エラーの原因でした
このメッセージには多くの考えられる根本原因があるようです。私の場合、 keyfile を正しく指定していなかったため、リモートにアクセスできませんでした。
-Lオプションは、暗黙のSSHジャンプを追加します（明示的なSSHホストを要塞/ジャンプサーバーとして効果的に使用します）。ジャンプを明示的に実行し、「proxycommand」を使用してターゲットマシンへのログインシェルを作成することで、これをデバッグする方が簡単な場合があります。
これが機能したら、ターゲットマシンのlocalhostに基づいてポートフォワードを実行できます（それ自体にログインできる場合）。
-N -L 1234:localhost:1234
私の場合：
$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/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 [email protected] -L 3456:127.0.0.1:5901
トンネルにlocalhostリテラルIPを使用していたときに、実際のIPがエラーを引き起こしたのは奇妙です。ディストリビューション：Ubuntu 16.04 LTS。
同じ問題があり、それがDNSであることに気付きました。トラフィックはトンネリングされますが、DNS要求はありません。 DNSホストファイルを手動で編集して、アクセスするサービスを追加してください。
他の1つのシナリオは、アクセスしようとしているサービスが実行されていないことです。先日この問題に遭遇したのは、接続しようとしていたhttpdインスタンスが停止していたことを思い出すためだけです。
問題を解決するための手順は、最も単純なものから開始することです。これは、他のマシンに行き、ローカルに接続できるかどうかを確認してから、クライアントコンピューターに向かって自分自身を操作します。少なくともこれにより、通信が発生していない時点で解決することができます。あなたは他のアプローチを取ることができますが、これは私のために働いたものです。