it-swarm.dev

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 서버가이 요청을 거부하게하는 두 가지 옵션이 있습니다.

  • AllowTcpForwarding (스티브 부 조나스가 언급했듯이)
  • 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

적어도 하나의 대답은 어떤 이유로 ssh를 사용하여 기계 "원격"에 도달 할 수 없다는 것입니다. 오류 메시지가 잘못되었습니다.

27
Neil

서버에서 '원격'을 확인할 수 없으면 해당 오류가 발생합니다. IP 주소로 교체하고 문제가 해결되는지 확인하십시오 ...

(기본적으로 Neil의 답변과 동일하지만 확실히 내 측면에서 문제가되는 것을 알았습니다.) [내 ~/.ssh/config 파일에 컴퓨터 이름의 별칭이 있었고 원격 컴퓨터는 해당 별칭에 대해 아무것도 알지 못했습니다. ...

19
jacquesjtheron

하나의 소켓 연결을 공유하기 위해 ssh 옵션 ControlPathControlMaster을 사용하면 (한 클라이언트에서 동일한 user @ server로) 여러 클라이언트 연결간에 재사용 할 수 있습니다. 너무 많이 열면 (내 경우에는 ~ 20 개의 연결이 무엇이든)이 메시지가 생성됩니다. 이전 연결을 닫으면 다시 한도까지 새로 열 수 있습니다.

11
Matej Kovac

"관리 상 금지됨"은 "관리자가이 연결을 명시 적으로 차단하려고합니다"로 표시되는 특정 ICMP 메시지 플래그입니다.

Iptables 설정을 확인하십시오.

8
Shadur

제 경우에는 localhost127.0.0.1 에:

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

작동하도록.

나는 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를 사용하여 터널을 만들 때 두 개의 포트가 필요합니다.

  • 연결 용 (10000),
  • 모니터링을위한 것 (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의 메시지와 관리적으로 금지됨 메시지입니다.

여기서 이해하는 것은 administratively는 "서버 측의 특정 구성으로 인해"라는 의미입니다.

5
lauhub

/etc/sshd_config

AllowTcpForwarding no 

세트. TCP 전달을 허용하려면 yes로 전환하십시오.

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 로그를 확인하고 원격 호스트의 보안 로그
  • 다른 원격 포트를 테스트하고
  • iptables 설정을 확인하십시오 (Shadur가 말했듯이).
3
Marco Solieri

로컬 쪽의 포트에 바인딩 할 수 없어서 발생할 수도 있습니다.

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

이 명령은 로컬 시스템의 청취 포트 1234를 바인딩하려고 시도하며 원격 시스템의 포트 5678에있는 서비스에 맵핑됩니다.

로컬 시스템의 포트 1234가 다른 프로세스 (백그라운드 ssh -f 세션 일 수 있음)에서 이미 사용중인 경우 ssh는 해당 포트에서 청취 할 수 없으며 터널이 실패합니다.

문제는이 오류 메시지가 여러 가지를 의미 할 수 있으며 "관리 상 금지됨"은 때때로 잘못된 아이디어를 제공한다는 것입니다. 따라서 DNS, 로컬과 원격 사이의 방화벽 및 sshd_config를 확인하는 것 외에도 로컬 포트가 이미 사용 중인지 확인하십시오. 사용하다

lsof -ti:1234

다른 사용자가 소유 한 프로세스를 나열하려면 lsof에 대해 Sudo가 필요할 수 있습니다. 그런 다음 사용할 수 있습니다

ps aux | grep <pid>

그 과정이 무엇인지 알아낼 수 있습니다.

하나의 명령으로이 모든 것을 얻으려면 :

ps aux | grep "$(Sudo lsof -ti:1234)"
3
Mnebuerquo

제 경우에는 서버가 내 계정에서 암호를 강제로 변경하는 것을 목표로하는 동안 셸 액세스가없는 터널을 요청했기 때문에 문제가 발생했습니다. Shell이 ​​없기 때문에 볼 수 없었고 오류 만 받았습니다.

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
Leonardo Brunnet

SFTP를 사용하여 연결할 수있는 권한이있는 사용자와 SSH를 통해 연결하려고 할 때이 문제가 발생했습니다.

예를 들어, 이것은 서버의 /etc/ssh/sshd_config :

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

따라서이 경우 SSH를 사용하려면 동등한 sftponly 그룹에서 사용자를 제거하거나 SFTP로 제한되지 않은 사용자를 사용하여 연결해야합니다.

1
Mike

SSH를 데비안에 터널링하는 동안 같은 메시지가 나타납니다. 원격 시스템에 여유 공간이 없었습니다. 디스크 공간을 확보하고 재부팅 한 후 터널이 작동하기 시작했습니다.

1
SlavaSt

ssh- ing하려는 서버에서 /etc/resolv.conf가 비어 있는지 확인하십시오. 여러 번이 파일이 빈 /etc/resolv.conf 파일과 관련이 있음을 발견했습니다.

루트가 아닌 경우 공개 호스트 이름에서 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:22case (대문자)의 차이점에 유의하십시오.

사례를 수정 한 후에는 더 이상 문제를 보지 못했습니다.

나는 사용하고 있었다 :

OpenSSH 클라이언트 버전 :

  • OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 2016 년 3 월 1 일

OpenSSH 서버 버전 :

  • OpenSSH_7.6p1 데비안 -4, OpenSSL 1.0.2n 2017 년 12 월 7 일
0
Zach Pfeffer

Cygwin 에서이 오류를 보았으며 Linux에서도 마찬가지이며 나를 위해 일했습니다. 내 경우에는 ssh -ND * : 1234 [email protected]을 수행하고 브라우저를 해당 comp-socks server에 연결하면 브라우저가 탐색되었지만 ssh 명령을 실행 한 comp에서 해당 오류가 표시됩니다. 브라우저는 프록시를 통해 검색하거나 적어도 주요 연령을 보인 것처럼 보이지만 각 요청이있는 콘솔-적어도 하나의 사이트에 대해. 그러나이 변경으로 실패한 메시지를 제거했습니다.

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

위의 설명 중 하나에 약간의 추가 : "DNS 확인 실패로 인해이 오류가 발생할 수 있습니다"-호스트 이름의 철자를 정확하게 입력하십시오.

방금 모든 ssh 설정을 디버깅하는 데 한 시간이 걸렸으며 위의 DNS 확인 실패 참고 사항과 동일한 명령에서 amazonaws의 철자를 잘못 입력 한 것으로 나타났습니다.

0
Brad Dwyer

Asus RT68U 라우터의 펌웨어 (Merlin Asus)에는 SSH 포트 포워딩을 허용하는 설정이 있습니다.

enter image description here

다음에 설명 된대로 동적 포트 전달이 설정되었습니다 : 동적 터널 문제 해결

0
gatorback

내가 그 메시지를받은 이유는 가장 일반적인 것이 아니지만 언급 할 가치가 있습니다. 스크립트로 터널 목록을 생성했으며 열 표시를 보장하기 위해 각 마지막 바이트를 2 바이트로 인쇄했습니다. 192.168.66.08로 터널 전달을 열려고 할 때 gethostbyaddr에 의해 '08'이 잘못된 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에 다음과 같이 서버 이름에 대한 잘못된 IP 주소 (localhost가 아닌)가 있습니다.

127.0.0.1     localhost
192.168.2.45  server.domain.com server

그러나 구성된 서버 IP (및 호스트/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

다른 시나리오는 액세스하려는 서비스가 실행되고 있지 않은 것입니다. 다른 날에 연결하려고하는 httpd 인스턴스가 중지되었음을 기억하기 위해이 문제에 부딪 쳤습니다.

문제를 해결하기위한 단계는 가장 간단한 것부터 시작하는 것입니다. 가장 간단한 방법은 다른 컴퓨터로 이동하여 로컬로 연결 한 다음 클라이언트 컴퓨터를 향해 다시 작업 할 수 있는지 확인하는 것입니다. 적어도 이것은 의사 소통이 일어나지 않는 시점에서 운동 할 수있게 해줍니다. 다른 접근법을 취할 수 있지만 이것은 나를 위해 일한 것입니다.

0
Andre M