it-swarm-ja.com

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

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

210
Neil

チャネル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) マンページの完全な構文。

134
hyperair

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

ssh -L 1234:localhost:1234 [email protected]

問題は、リモートホストで/etc/hostsに「localhost」のエントリがなかったため、sshサーバーがトンネルの設定方法を認識していませんでした。この場合、非常に不親切なエラーメッセージ。私はついにそれを理解しました。

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

55
cobbzilla

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

27
Neil

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

(基本的にはNeilの回答と同じですが、私の側で問題であることが確かにわかりました)[~/.ssh/configファイルにマシン名のエイリアスがありましたが、リモートマシンはそのエイリアスを認識していませんでした。 ..

19
jacquesjtheron

このエラーは、sshオプションControlPathControlMasterを使用して1つのソケット接続を共有し、複数のクライアント接続間(1つのクライアントから同じuser @ serverへ)で再利用する場合に確実にポップアップします。開いている数が多すぎる(意味が何であれ、私の場合は最大20接続)と、このメッセージが表示されます。以前の接続を閉じると、上限まで、新しいものを開くことができます。

11
Matej Kovac

「管理上禁止」とは、具体的には「管理者がこの接続をブロックすることを明示的に望んでいる」という具体的なICMPメッセージフラグです。

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

8
Shadur

私の場合、localhost127.0.0.1に置き換える必要がありました。

ssh -L 1234:localhost:3389 [email protected]

それを動作させるために。

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 [email protected]
6
tinlyx

同様の問題

別の可能なリード

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 [email protected]

私はそのメッセージを受け取りました(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は、localhost127.0.0.1へのショートカットであることを理解していないようです。そのため、auth.logのメッセージと管理上禁止メッセージが表示されます。

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

5
lauhub

これは、/etc/sshd_config持っている

AllowTcpForwarding no 

セットする。これをyesに切り替えて、TCP転送を許可します。

4
user578125

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

これは私がトンネリングに使用する行です:ssh -L 8983:locahost:8984 [email protected] -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.
3
Marciano

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

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

これは、ローカル側のポートにバインドできないことが原因である場合もあります。

ssh -Nn -L 1234:remote:5678 [email protected]

このコマンドは、ローカルマシンのリスニングポート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)"
3
Mnebuerquo

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

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!

シェルアクセスでログインし、パスワードを変更することで問題を解決しました。その後、シェルにアクセスせずにトンネルを使用できます。

2
Pieter Van Gorp

これが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が解決できない場合や、ここで[email protected]をポート転送ロジックに追加した(これはできない)のように、不明な構文を入力した場合に表示される可能性があります。作業)。

2
Torxed

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

2

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

たとえば、これはサーバーの/etc/ssh/sshd_config

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

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

1
Mike

DebianへのSSHトンネリング中に同じメッセージが表示されました。リモートシステムに空き容量がないことが判明しました。一部のディスク領域を解放して再起動した後、トンネルは機能し始めました。

1
SlavaSt

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

Root以外の場合は、パブリックホスト名でpingまたはtelnet(80)を試すことでサーバーを確認できます。

[email protected] ~ # telnet www.google.com 80
telnet: could not resolve www.google.com/80: Name or service not known

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

[email protected] ~ # 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クライアントによってネームサーバーレコードが通常入力されます。

1
Ender

このエントリ私のブログ に書き込んでいるときにこのエラーが発生しました:

/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:22sshbeyondremote.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日
0
Zach Pfeffer

私はcygwinでこのエラーを見ましたが、これはLinuxにも当てはまるはずで、私にとってはうまくいきました。私の場合、私はssh -ND *:1234 [email protected]を実行し、ブラウザをそのcomp-socksサーバーに接続するとブラウザしましたが、そのsshコマンドを実行したコンプでエラーが表示されましたリクエストごとのコンソール-少なくとも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 :
[email protected]:~# echo “PermitTunnel yes” >> /etc/ssh/sshd_config
Then, restart your sshd server :
[email protected]:~# service ssh restart
or

[email protected]:~# /etc/init.d/ssh restart
0
barlop

上記のコメントの1つに少し追加:「DNS解決の失敗によりこのエラーが発生する可能性があります」-ホスト名のスペルが正しいことも確認してください。

1時間以上かけてすべてのssh設定をデバッグしようとしたところ、コマンドでamazonawsのスペルを間違えただけであることがわかりました。これは、上記のDNS解決失敗のメモと同等です。

0
Brad Dwyer

Asus RT68Uルーターのファームウェア(Merlin Asus)には、SSHポート転送を許可する設定があり、これを有効にする必要があります。

enter image description here

動的ポート転送は、次のように設定されました: 動的トンネルのトラブルシューティング

0
gatorback

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

0

ルーターの DNS Rebinding 保護を確認します。私のルーター(pfsense)では、デフォルトでDNS再バインド保護が有効になっています。 SSHで「チャネルオープン:管理上禁止に失敗しました:オープンに失敗しました」エラーの原因でした

0
meffect

このメッセージには多くの考えられる根本原因があるようです。私の場合、 keyfile を正しく指定していなかったため、リモートにアクセスできませんでした。

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

これが機能したら、ターゲットマシンのlocalhostに基づいてポートフォワードを実行できます(それ自体にログインできる場合)。

-N -L 1234:localhost:1234
0
nobar

私の場合:

$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)
0
diyism

その他の名前解決の原因:/ 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。

0
Fjor

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

0
Data

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

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

0
Andre M