Lỗi đường hầm SSH: Kênh 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?

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, -Lhoặ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 đang được đề cập 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 có thể được tìm thấy trong /etc/ssh/sshd_config. Bạn nên đảm bảo rằng:

• AllowTCPForwarding là không có mặt, được nhận xét hoặc được đặt thành yes
• PermitOpenkhô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 ~/.ssh/authorized_keyskhông có no-port-forwardinghoặc có permitopencâu lệnh [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à PermitTunneltùy chọn nếu bạn đang cố sử dụng tùy chọn -w.

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

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

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 user@remote

Vấn đề là, trên máy chủ từ xa, /etc/hostskhô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.

Í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ý.

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 giống như của Neil - nhưng tôi chắc chắn thấy đó là vấn đề về phía mình) [Tôi có một bí danh cho tên máy trong ~/.ssh/configtệp của mình - và máy từ xa không biết gì về bí danh đó ...

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 ControlPathvà ControlMasterđể 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 người dùng @ máy chủ). 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.

"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.

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

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

Tôi đã có cùng một vấn đề sử dụng ~/.ssh/authorized_keysvới permitopen.

Khi tôi sử dụng autosshđể tạo một đườ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 user@remote

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

channel 2: open failed: administratively prohibited: open failed

Ở phía xa

Bao /var/log/auth.loggồm của tôi :

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

Trong ~/.ssh/authorized_keys(phía xa) tôi đã có điều 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 điều này bằng cách thay thế các localhosttrường hợp 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 đó localhostlà lối tắt đến 127.0.0.1, do đó tin nhắn trong auth.logvà tin nhắn bị cấm hành chính .

Đ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ủ".

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

AllowTcpForwarding no 

bộ. Chuyển nó để yescho phép chuyển tiếp TCP.

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

ssh -L 1234:localhost:3389 user@remote

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

Tôi đã cố gắng làm rdesktop -L localhost:1234theo hướng dẫn của Amazon về 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) theo câu trả lời được bình chọn cao nhất. Tôi cũng đã kiểm tra đó localhostlà ở /etc/hostscả hai bên.

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

ssh -L 1234:127.0.0.1:3389 user@remote

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 máy chủ cục bộ và nhật ký an toàn trên điều khiển từ xa,
• 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).

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 để đào hầm: 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.

Đ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 user@remote

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)"

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.

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 user@example.com: unknown host (Name or service not known)

Điều này có thể được trình bày nếu remotekhô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 một user@logic chuyển tiếp cổng (không hoạt động).

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 vỏ, 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 đường hầm mà không cần truy cập shell.

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ụ: đây là 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 sftponlynhóm tương đương hoặc kết nối bằng người dùng không giới hạn ở SFTP.

Kiểm tra xem /etc/resolv.confcó trống không trên máy chủ mà bạn đang sshtruy cập. Nhiều lần tôi thấy điều này có liên quan đến một /etc/resolv.conftập tin 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ố pinghoặc telnet(80) trên tên máy chủ công cộng, nghĩa là:

root@bananapi ~ # 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:

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

Tuy nhiên, bạn cũng nên kiểm tra lý do tại sao /etc/resolv.conftrống (điều này thường được tạo bở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ó.

Tôi đã nhận được thông báo tương tự trong khi SSH điều chỉnh 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.

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 user@127.0.0.1 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-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 :
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

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 đó quay lại 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.

Kiểm tra bộ định tuyến của bạn để bảo vệ DNS Rebinding . 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

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.

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)

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

/etc/ssh/sshd_config có 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 trường hợp (viết hoa) giữa SSHBeyondRemote.server.com:22 và 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

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 các lệnh máy chủ / đào) 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 user@server.domain.com -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.

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 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ệ :)

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 đó là một không có khả năng truy cập từ xa bởi vì tôi đã không được cung cấp các keyfile một cách chính xác.

Các -Ltùy chọn thêm một bước nhảy SSH ngầm (một cách hiệu quả bằng cách sử dụng máy chủ SSH rõ ràng như một máy chủ / nhảy pháo đài). 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 một vỏ đă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 máy đích localhost(giả sử nó có thể đăng nhập vào chính nó):

-N -L 1234:localhost:1234