it-swarm-vi.com

Lỗi đường hầm SSH: "kênh 1: mở thất bại: bị cấm về mặt hành chính: mở thất bại"

Khi tôi mở đường hầm ssh này:

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

Tôi gặp lỗi này khi cố gắng truy cập máy chủ HTTP đang chạy trên localhost: 8984:

channel 1: open failed: administratively prohibited: open failed

Lỗi này có nghĩa là gì, và bạn có thể khắc phục sự cố trên máy nào?

210
Neil

kênh 1: mở thất bại: bị cấm hành chính: mở thất bại

Thông báo trên đề cập đến máy chủ SSH của bạn từ chối yêu cầu của khách hàng SSH của bạn để mở kênh bên. Điều này thường xuất phát từ -D, -L Hoặc -w, Vì các kênh riêng biệt trong luồng SSH được yêu cầu để chuyển dữ liệu được chuyển tiếp qua.

Vì bạn đang sử dụng -L (Cũng có thể áp dụng cho -D), Có hai tùy chọn trong câu hỏi khiến máy chủ SSH của bạn từ chối yêu cầu này:

  • AllowTcpForwarding (như Steve Buzonas đã đề cập)
  • PermitOpen

Các tùy chọn này có thể được tìm thấy trong /etc/ssh/sshd_config. Bạn nên đảm bảo rằng:

  • AllowTCPForwarding không có mặt, được nhận xét hoặc được đặt thành yes
  • PermitOpen không có mặt, được nhận xét hoặc được đặt thành any [1]

Ngoài ra, nếu bạn đang sử dụng khóa SSH để kết nối, bạn nên kiểm tra xem mục nhập tương ứng với khóa SSH của bạn trong ~/.ssh/authorized_keys Không có no-port-forwarding Hoặc permitopen statement [2] .

Không liên quan đến lệnh cụ thể của bạn, nhưng phần nào cũng liên quan đến chủ đề này, là tùy chọn PermitTunnel nếu bạn đang cố sử dụng tùy chọn -w.

[1] Cú pháp đầy đủ trong sshd_config(5) manpage.

[2] Cú pháp đầy đủ trong authorized_keys(5) manpage.

134
hyperair

Trong một trường hợp rất kỳ lạ, tôi cũng gặp phải lỗi này trong khi cố gắng tạo một đường hầm cục bộ. Lệnh của tôi là một cái gì đó như thế này:

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

Vấn đề là, trên Máy chủ từ xa, /etc/hosts không có mục nào cho "localhost" nên máy chủ ssh không biết cách thiết lập đường hầm. Một thông báo lỗi rất không thân thiện cho trường hợp này; rất vui vì cuối cùng tôi đã tìm ra nó.

Bài học: đảm bảo tên máy chủ đích của đường hầm của bạn có thể được phân giải bởi Máy chủ từ xa, thông qua DNS hoặc /etc/hosts.

55
cobbzilla

Ít nhất một câu trả lời là máy "từ xa" không thể truy cập được với ssh vì một số lý do. Thông báo lỗi chỉ là vô lý.

27
Neil

Nếu không thể giải quyết 'từ xa' trên máy chủ, bạn sẽ gặp lỗi đó. Thay thế bằng một địa chỉ IP và xem nếu điều đó giải quyết vấn đề của bạn ...

(Về cơ bản câu trả lời tương tự như của Neil - nhưng tôi chắc chắn thấy rằng đó là vấn đề về phía tôi) [Tôi có một bí danh cho tên máy trong tệp ~/.ssh/config ...

19
jacquesjtheron

Lỗi này chắc chắn bật lên khi bạn sử dụng các tùy chọn ssh ControlPathControlMaster để chia sẻ một kết nối ổ cắm được sử dụng lại giữa một số kết nối máy khách (từ một máy khách đến cùng một máy chủ @ user). Mở quá nhiều (bất kể nó có nghĩa là gì, trong trường hợp của tôi ~ 20 kết nối) mang lại thông báo này. Đóng mọi kết nối trước đó cho phép tôi mở mới hơn, một lần nữa đến giới hạn.

11
Matej Kovac

"Cấm hành chính" là cờ thông báo ICMP cụ thể có nghĩa là "Quản trị viên rõ ràng muốn kết nối này bị chặn".

Kiểm tra cài đặt iptables của bạn.

8
Shadur

Trong trường hợp của tôi, tôi đã phải thay thế localhost bằng 127.0.0.1 trong:

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

để làm cho nó hoạt động.

Tôi đã cố gắng để rdesktop -L localhost:1234 theo Amazon hướng dẫn kết nối với AWS EC2 thông qua đường hầm SSH . Tôi đã cố gắng thay đổi /etc/ssh/sshd_config (cả máy khách và máy chủ đều chạy Ubuntu 16.04 LTS) cho mỗi câu trả lời được bình chọn cao nhất. Tôi cũng đã kiểm tra rằng localhost có trong /etc/hosts cả từ hai phía.

Không có gì hoạt động cho đến khi tôi thay đổi lệnh ssh thành:

ssh -L 1234:127.0.0.1:3389 [email protected]
6
tinlyx

Một vấn đề tương tự

Một dẫn khác có thể

Tôi gặp vấn đề tương tự khi sử dụng ~/.ssh/authorized_keys Với permitopen.

Khi tôi sử dụng autossh để tạo đường hầm, tôi cần hai cổng:

  • một cho kết nối (10000),
  • một để theo dõi (10001).

Về phía khách hàng

Điều này cho tôi một vấn đề tương tự với cổng giám sát:

autossh -M 10001 -o GatewayPorts=yes -o ServerAliveInterval=60  -o TCPKeepAlive=yes -T -N -R :10000:localhost:22 -i ~/.ssh/id_rsa [email protected]

Tôi đã có tin nhắn đó (sau 10 phút):

channel 2: open failed: administratively prohibited: open failed

Ở phía xa

/var/log/auth.log Của tôi chứa:

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

Trong ~/.ssh/authorized_keys (Phía xa) của tôi, tôi đã có cái này:

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

Làm thế nào để giải quyết nó

Tôi đã giải quyết vấn đề này bằng cách thay thế localhost dụ bằng 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...

Có vẻ như SSH không hiểu rằng localhost là lối tắt đến 127.0.0.1, Do đó tin nhắn trong auth.logbị cấm hành chính tin nhắn.

Điều tôi hiểu ở đây là về mặt hành chính có nghĩa là "do một cấu hình cụ thể ở phía máy chủ".

5
lauhub

Điều này cũng xảy ra khi /etc/sshd_config

AllowTcpForwarding no 

bộ. Chuyển nó thành yes để cho phép TCP chuyển tiếp.

4
user578125

Tôi đã gặp lỗi này một lần khi đặt điều khiển từ xa vào tham số -L, và 0.0.0.0 là dự phòng, bạn có thể bỏ qua nó với cùng kết quả và tôi nghĩ bạn nên thêm -g để nó hoạt động.

Đây là dòng tôi sử dụng để tạo đường hầm: 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

Một số hoạt động khắc phục sự cố là cần thiết để tìm câu trả lời dứt khoát:

  • kiểm tra xem cổng chuyển tiếp có được bật trong cấu hình ssh của người dùng không
  • cho phép tính dài dòng của ssh (-v),
  • kiểm tra nhật ký ssh trên Host cục bộ và nhật ký an toàn trên remote,
  • kiểm tra cổng từ xa khác nhau,
  • kiểm tra cài đặt iptables của bạn (như Shadur đã nói).
3
Marco Solieri

Điều này cũng có thể được gây ra bởi không thể liên kết với cổng ở phía địa phương.

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

Lệnh này đang cố gắng liên kết một cổng nghe 1234 trên máy cục bộ, ánh xạ tới một dịch vụ trên cổng 5678 trên một máy từ xa.

Nếu cổng 1234 trên máy cục bộ đã được sử dụng bởi một quy trình khác, (có thể là phiên ssh -f nền), thì ssh sẽ không thể nghe trên cổng đó và đường hầm sẽ thất bại.

Vấn đề là thông báo lỗi này có thể có nghĩa là bất kỳ điều gì trong số đó và đôi khi "bị cấm về mặt hành chính" đưa ra ý tưởng sai. Vì vậy, ngoài việc kiểm tra DNS, tường lửa giữa cục bộ và từ xa và sshd_config, hãy kiểm tra xem cổng cục bộ đã được sử dụng chưa. Sử dụng

lsof -ti:1234

để tìm ra quy trình nào đang chạy trên 1234. Bạn có thể cần Sudo cho lsof để liệt kê các quy trình do người dùng khác sở hữu. Sau đó, bạn có thể sử dụng

ps aux | grep <pid>

để tìm hiểu quá trình đó là gì.

Để có được tất cả trong một lệnh:

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

Trong trường hợp của tôi, vấn đề là do yêu cầu một đường hầm không có quyền truy cập Shell trong khi máy chủ nhằm buộc thay đổi mật khẩu trên tài khoản của tôi. Do thiếu Shell, tôi không thể thấy điều đó và chỉ nhận được lỗi

channel 2: open failed: administratively prohibited: open failed  

Cấu hình đường hầm của tôi như sau:

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

Lỗi hiển thị khi đăng nhập trực tiếp vào máy chủ (không có -N -f):

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

Tôi đã giải quyết vấn đề bằng cách đăng nhập bằng quyền truy cập Shell và thay đổi mật khẩu. Sau đó, tôi chỉ có thể sử dụng các đường hầm mà không cần truy cập Shell một lần nữa.

2
Pieter Van Gorp

Tôi vô cùng ngạc nhiên khi không ai đề cập rằng đây có thể là sự cố 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)

Điều này có thể được trình bày nếu remote không thể giải quyết được hoặc bạn đã nhập một cú pháp không xác định như tôi đã thực hiện ở đây nơi tôi đã thêm [email protected] với logic chuyển tiếp cổng (sẽ không hoạt động).

2
Torxed

Tôi đã có cùng một thông điệp trong khi cố gắng để đường hầm. Có một vấn đề với máy chủ dns ở phía xa. Vấn đề đã được giải quyết khi nó trở lại làm việc.

2
Leonardo Brunnet

Tôi gặp vấn đề này khi cố gắng kết nối qua SSH với người dùng chỉ được phép kết nối bằng SFTP.

Ví dụ: cái này ở trong máy chủ /etc/ssh/sshd_config:

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

Vì vậy, trong trường hợp này, để sử dụng SSH, bạn sẽ phải xóa người dùng khỏi nhóm sftponly tương đương hoặc kết nối bằng người dùng không giới hạn ở SFTP.

1
Mike

Tôi đã nhận được thông báo tương tự trong khi SSH chuyển sang Debian. Hóa ra hệ thống từ xa không có không gian trống. Sau khi giải phóng một số dung lượng đĩa và khởi động lại, đường hầm bắt đầu hoạt động.

1
SlavaSt

Kiểm tra xem /etc/resolv.conf Có trống trên máy chủ không ssh- ing. Nhiều lần tôi thấy điều này có liên quan đến một tệp /etc/resolv.conf Trống

Nếu không root, bạn chỉ có thể kiểm tra trên máy chủ bằng cách thử một số ping hoặc telnet (80) trên tên máy chủ công cộng, tức là:

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

Sau khi thêm bản ghi máy chủ tên vào /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

Tuy nhiên, bạn cũng nên kiểm tra tại sao /etc/resolv.conf Để trống (điều này thường được ghi với các bản ghi máy chủ tên của máy khách dhcp trên máy chủ, nếu có.

1
Ender

Tôi đã gặp lỗi này khi viết mục này in blog của tôi :

/etc/ssh/sshd_config có một cái gì đó như:

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

Nhưng ~/.ssh/config đã có:

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

Lưu ý sự khác biệt trong case (viết hoa) giữa SSHBeyondRemote.server.com:22 sshbeyondremote.server.com:22.

Khi tôi sửa trường hợp, tôi không còn thấy vấn đề nữa.

Tôi đang sử dụng:

Phiên bản của ứng dụng khách OpenSSH:

  • OpenSSH_7.2p2 Ubuntu-4ubfox2.4, OpenSSL 1.0.2g ngày 1 tháng 3 năm 2016

Phiên bản của máy chủ OpenSSH:

  • OpenSSH_7.6p1 Debian-4, OpenSSL 1.0.2n ngày 7 tháng 12 năm 2017
0
Zach Pfeffer

Tôi đã thấy lỗi này trên cygwin và điều này cũng đúng với linux và cũng hoạt động với tôi. Trong trường hợp của tôi, tôi đã thực hiện ssh -ND *: 1234 [email protected] và khi tôi kết nối một trình duyệt với máy chủ comp-vớ đó, nó đã duyệt, nhưng trên comp mà tôi chạy lệnh ssh đó, tôi đã gặp lỗi đó bảng điều khiển với mỗi yêu cầu - ít nhất là cho một trang web, mặc dù trình duyệt đã truy xuất nó thông qua proxy hoặc dường như, ít nhất là đến mức tôi thấy thời đại chính. Nhưng thực hiện thay đổi này đã loại bỏ thông điệp thất bại

http://linuxindetails.wordpress.com/2010/02/18/channel-3-open-fails-ad hành chính-pro cấm-open-fails/

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

Một bổ sung nhỏ cho một trong những ý kiến ​​trên: "Lỗi độ phân giải DNS có thể gây ra lỗi này" - cũng đảm bảo bạn đánh vần đúng tên máy chủ của mình.

Tôi chỉ mất hơn một giờ để cố gắng gỡ lỗi tất cả các cài đặt ssh và hóa ra tôi vừa viết sai chính tả amazonaws trong lệnh tương đương với ghi chú lỗi phân giải DNS ở trên.

0
Brad Dwyer

Chương trình cơ sở của bộ định tuyến Asus RT68U (Merlin Asus) có cài đặt cho phép chuyển tiếp cổng SSH, phải được bật:

enter image description here

Chuyển tiếp cổng động đã được thiết lập như mô tả tại: Xử lý sự cố đường hầm Dyamic

0
gatorback

Lý do tại sao tôi có tin nhắn đó không phải là phổ biến nhất, nhưng nó đáng để đề cập. Tôi đã tạo ra bởi kịch bản một danh sách các đường hầm và để đảm bảo trình bày cột, tôi đã in từng byte cuối cùng trên hai byte. Khi tôi cố mở chuyển tiếp đường hầm tới 192.168.66.08, nó luôn thất bại, vì '08' được gethostbyaddr hiểu là số bát phân không hợp lệ :)

0
Philippe De Muyter

Kiểm tra bộ định tuyến của bạn xem DNS Rebinding bảo vệ. Bộ định tuyến của tôi (pfsense) có DNS Rebinding Protection được bật theo mặc định. Nó đã gây ra lỗi 'kênh mở: thất bại về mặt hành chính bị cấm: lỗi không mở' với SSH

0
meffect

Có vẻ như có rất nhiều nguyên nhân gốc có thể cho thông điệp này. Trong trường hợp của tôi, nó không có khả năng truy cập từ xa vì tôi đã không cung cấp keyfile một cách chính xác.

Các -L tùy chọn thêm một bước nhảy SSH ẩn (sử dụng hiệu quả Máy chủ SSH rõ ràng làm máy chủ pháo đài/nhảy). Có thể dễ dàng hơn để gỡ lỗi này bằng cách thực hiện bước nhảy một cách rõ ràng và tạo Shell đăng nhập vào máy đích bằng cách sử dụng "proxycommand".

Khi điều này hoạt động, bạn có thể thực hiện chuyển tiếp cổng dựa trên localhost của máy đích (giả sử nó có thể đăng nhập vào chính nó):

-N -L 1234:localhost:1234
0
nobar

Trường hợp của tôi

$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

Nguyên nhân phân giải tên khác: My/etc/hosts có địa chỉ IP sai cho tên máy chủ (không dành cho localhost), như sau:

127.0.0.1     localhost
192.168.2.45  server.domain.com server

Nhưng IP máy chủ được cấu hình (và tên DNS được giải quyết bằng lệnh Host/Dig) là 192.168.2.47. Một lỗi đánh máy đơn giản gây ra bởi cấu hình lại IP trước đó. Sau khi sửa/etc/hosts, kết nối đường hầm hoạt động hoàn hảo:

ssh [email protected] -L 3456:127.0.0.1:5901

Thật kỳ lạ khi IP thực sự gây ra lỗi khi tôi đang sử dụng IP theo nghĩa đen localhost cho đường hầm. Phân phối: Ubuntu 16.04 LTS.

0
Fjor

Tôi đã có cùng một vấn đề và tôi nhận ra rằng đó là DNS. Lưu lượng được tạo đường hầm nhưng yêu cầu DNS không có. Cố gắng chỉnh sửa tệp lưu trữ DNS theo cách thủ công và thêm dịch vụ bạn muốn truy cập.

0
Data

Một kịch bản khác là dịch vụ bạn đang cố truy cập không chạy. Tôi đã gặp vấn đề này vào một ngày khác chỉ để nhớ ví dụ httpd mà tôi đang cố gắng kết nối đã bị dừng lại.

Các bước của bạn để giải quyết vấn đề sẽ là bắt đầu với cách đơn giản nhất, đó là chuyển sang máy khác và xem liệu bạn có thể kết nối cục bộ và sau đó tự quay về máy tính của mình không. Ít nhất điều này sẽ cho phép bạn giải quyết tại thời điểm giao tiếp không xảy ra. Bạn có thể thực hiện các phương pháp khác, nhưng đây là một cách làm việc cho tôi.

0
Andre M