ssh trả về tin nhắn Yêu cầu chuyển tiếp X11 không thành công trên kênh 1


33

Khi tôi ssh vào một máy chủ từ xa không chạy bất kỳ loại môi trường máy tính để bàn X11 nào, tôi nhận được thông báo sau.

$ ssh user@server
X11 forwarding request failed

$ ssh user@server ls
X11 forwarding request failed on channel 1
file1
file2
...

Làm thế nào tôi có thể thoát khỏi những tin nhắn này?

Câu trả lời:


38

Các tin nhắn này có thể được loại bỏ thông qua 1 trong 3 phương thức, chỉ sử dụng các tùy chọn SSH. Bạn luôn có thể gửi tin nhắn đến /dev/nullnhưng các phương thức này cố gắng xử lý tin nhắn thông qua cấu hình, thay vì chỉ bẫy và bỏ chúng.

Phương pháp # 1 - cài đặt xauth

Máy chủ mà bạn đang truy cập từ xa phàn nàn rằng nó không thể tạo một mục trong .Xauthoritytệp của người dùng , vì xauthkhông được cài đặt. Vì vậy, bạn có thể cài đặt nó trên mỗi máy chủ để thoát khỏi thông báo gây phiền nhiễu này.

Trên Fedora 19, bạn cài đặt xauthnhư vậy:

$ sudo yum install xorg-x11-xauth

Nếu sau đó bạn cố gắng sshvào máy chủ, bạn sẽ thấy một thông báo rằng một mục nhập đang được tạo trong .Xauthoritytệp của người dùng .

$ ssh root@server
/usr/bin/xauth:  creating new authority file /root/.Xauthority
$

Đăng nhập sau đó sẽ không còn hiển thị thông báo này.

Phương pháp # 2 - vô hiệu hóa nó qua ForwardX11

Bạn có thể hướng dẫn sshkhách hàng không cố gắng kích hoạt chuyển tiếp X11 bằng cách đưa vào tham số SSH ForwardX11.

$ ssh -o ForwardX11=no root@server

Bạn có thể làm điều tương tự với công -xtắc:

$ ssh -x root@server

Điều này sẽ chỉ tạm thời vô hiệu hóa thông báo này, nhưng là một lựa chọn tốt nếu bạn không thể hoặc không muốn cài đặt xauthtrên máy chủ từ xa.

Phương pháp # 3 - vô hiệu hóa nó thông qua sshd_config

Đây thường là mặc định nhưng trong trường hợp không phải, bạn có thể thiết lập sshdmáy chủ của mình để tắt X11Forwarding /etc/ssh/sshd_config.

X11Forwarding no

Trong số 3 phương pháp tôi thường sử dụng # 2, vì tôi thường muốn X11Forwardingsử dụng cho hầu hết các máy chủ của mình, nhưng sau đó không muốn xem X11....cảnh báo

$ HOME / .ssh / config

Phần lớn thời gian những tin nhắn này thậm chí sẽ không xuất hiện. Chúng thường chỉ xuất hiện khi bạn có các mục sau trong $HOME/.ssh/configtệp của mình , ở trên cùng.

ServerAliveInterval 15
ForwardX11 yes
ForwardAgent yes
ForwardX11Trusted yes

GatewayPorts yes

Vì vậy, đây là thiết lập này, điều cuối cùng thúc đẩy việc tạo ra các X11..tin nhắn đó, vì vậy, một lần nữa, phương thức # 2 có vẻ phù hợp nhất nếu bạn muốn hoạt động ForwardX11 yestheo mặc định, nhưng sau đó vô hiệu hóa nó cho các kết nối nhất định từ sshphối cảnh của máy khách .

Bảo vệ

Nói chung là không nên chạy với ForwardX11 yesmọi lúc. Vì vậy, nếu bạn muốn vận hành các kết nối SSH của mình theo cách an toàn nhất có thể, tốt nhất bạn nên làm như sau:

  1. Không bao gồm ForwardX11 yestrong $HOME/.ssh/configtập tin của bạn
  2. Chỉ sử dụng ForwardingX11 khi bạn cần thông qua ssh -X user@server
  3. Nếu bạn có thể, hãy tắt X11Forwardinghoàn toàn trên máy chủ để nó không được phép

Tài liệu tham khảo


Bạn có thể giúp tôi với unix.stackexchange.com/questions/470331/ không?
trao đổi quá mức vào

Đối với bản ghi, tôi nhận được thông báo đó khi tôi đang cố chạy máy khách X trên máy chủ từ xa. Họ sẽ không khởi chạy vì $ HIỂN THỊ không được đặt. Tôi quản lý để sửa nó với đề nghị đầu tiên của bạn: cài đặt xauth.
Tom Ellis

13

Trong trường hợp của tôi, thêm chuỗi này để /etc/ssh/sshd_configgiải quyết vấn đề:

X11UseLocalhost no

Điều này làm việc cho tôi (máy chủ đã cài đặt xauth). Cảm ơn.
Paul Higgins

Điều này xuất hiện để giải quyết vấn đề của tôi, nhưng tôi không hiểu tại sao, điều đó có liên quan. Tôi có ba máy Debian 7 giống hệt nhau, một trong số đó đột nhiên ngừng chấp nhận locahostchuyển tiếp X11. Chuyển tiếp X11 trên hai cái còn lại vẫn hoạt động. Bất cứ ý tưởng những gì có thể đã thay đổi?
Kyle Strand

12

Chạy ngang qua hôm nay và đập đầu tôi một lúc cho đến khi tôi tình cờ thấy một thiết lập ssh:

Nếu đó là RHEL 7 (centOS, OEL, v.v.) và nó bị vô hiệu hóa ipv6, thì nó cần:

AddressFamily inet

đặt trong / etc / ssh / sshd_config.


nếu chỉ có thông báo lỗi liên quan đến điều này ...
Jack Wasey

bạn biết điều gì buồn cười không? Tôi đã chạy vào đây hôm nay và googled nó, tìm thấy bài viết này, và tìm thấy nhận xét của riêng tôi từ bốn năm trước và nói "OH YEAH ĐÓ LÀ VẤN ĐỀ."
Hệ thống

2

Một biến thể nhỏ khác sẽ là nếu bạn muốn dừng xem thông báo này (tức là ngừng cố gắng chuyển tiếp X11) cho một số máy chủ nhất định nhưng vẫn giữ mặc định là ForwardX11 có cho tất cả các kết nối khác.

Đối với kịch bản này, bạn có thể tắt chuyển tiếp X11 cho một máy chủ (hoặc phạm vi) cụ thể trong ~ / .ssh / config. Một cái gì đó như thế này:

host 10.1.1.*
ForwardX11 no 

Lời cảm ơn: Đây là một sự tô điểm nhẹ cho câu trả lời hiện có (và rất đầy đủ) - vì tôi không thể bình luận!


2

Nếu chạy ứng dụng khách trong chế độ dài dòng ( ssh -v user@host) sẽ cung cấp cho bạn

debug1: Remote: No xauth program; cannot forward with spoofing.

nhưng xauththực sự được cài đặt trên máy chủ, thì có lẽ là do sshd tìm kiếm xauth thực thi ở vị trí sai (thường là / usr / X11R6 / bin / xauth ). Người ta có thể khắc phục điều đó bằng cách thiết lập

XAuthLocation /usr/bin/xauth

trong / etc / sshd / sshd_config (hoặc bất cứ thứ gì máy chủ của bạn được cấu hình).


Điều này làm việc cho tôi trên CentOS 7. Đó là thông báo lỗi chính xác mà tôi đang thấy.
Brian Minton

Đây là vấn đề của tôi, cố gắng đăng nhập từ xa vào máy Mac. Có câu thần chú chính xác là XAuthLocation / opt / X11 / bin / xauth
Leon Avery

1

Định cấu hình chuyển tiếp X11 trên cơ sở máy chủ

Ngoài tất cả các câu trả lời xuất sắc đã có ở đây, bạn có thể định cấu hình ForwardX11trên cơ sở từng máy chủ, vì vậy nếu chỉ serverthất bại như thế này, bạn có thể thêm một mục vào ~/.ssh/configtệp của mình theo mẫu sau:

Host server server.domain.dom
    ForwardX11 no

Bạn thậm chí có thể sử dụng các mục như thế này làm đồng minh cho toàn bộ các cấu hình

Host my.server
    HostName server.domain.dom
    User user
    Port 1234
    ForwardX11 no

Điều này đặc biệt hữu ích nếu bạn đã thiết lập tên máy chủ Tự động hoàn thành cho SSH và SCP .


1

Tôi bắt gặp câu hỏi này sau khi gặp phải một sshd-xauthlỗi gần một thập kỷ. Hai giải pháp được báo cáo, bỏ qua đầu tiên xauth, thứ hai giải quyết lỗi.


Giải pháp 1 - bỏ qua xauth

  • local - máy cục bộ phục vụ Xserver.
  • từ xa - máy từ xa phục vụ ứng dụng điều khiển dữ liệu đến Xserver

từ xa /etc/ssh/sshd_config:

X11Forwarding no
X11DisplayOffset 10
X11UseLocalhost yes

Remote ~/.Xauthoritytrống hoặc không tồn tại

Về địa phương:

Xephyr -ac -screen 1280x800 -br -reset   :2 &
DISPLAY=:2 ssh  -fR 6010:/tmp/.X11-unix/X2  user@remote "DISPLAY=:10 xeyes"

Trong thử nghiệm, cục bộ đã chạy Ubuntu 18.05, remote đang chạy Debian Jesse.

Tôi cũng đăng giải pháp này như một câu trả lời khác.


Giải pháp 2 - giải quyết lỗi sshd / xauth

Giải pháp này gần với giải pháp của @systempoet ở trên , mặc dù điều đó không đủ.

Ngoài sửa đổi /etc/ssh/sshd_configtrên remote:

AddressFamily inet

/etc/hosts trên điều khiển từ xa cũng được sửa đổi:

::1     localhost ip6-localhost ip6-loopback

Nếu một trong hai đã được nhận xét, thông báo lỗi

X11 forwarding request failed on channel 0

xuất hiện sau ssh -X ...cuộc gọi. Ngoài /var/log/auth.logra, lỗi hiển thị:

sshd[...]: error: Failed to allocate internet-domain X11 display socket

Kiểm tra để tạo ra lỗi (trước khi sửa):

Máy địa phương:

$ Xephyr -ac -screen 1280x800 -br -reset -terminate  :2 &
$ DISPLAY=:2 ssh -X  user@remote
X11 forwarding request failed on channel 0

0

Một điểm quan trọng cần lưu ý sau khi thực hiện thay đổi cấu hình là bạn sẽ phải giết sshd để nó nhận các thay đổi:

cat /var/run/sshd.pid | xargs kill -1

là người dùng root.


-2
  1. Đặt 2 tùy chọn sau trong /etc/ssh/sshd_configmáy chủ RHEL của bạn

    X11Forwarding yes X11UseLocalhost no

  2. sudo /etc/init.d/sshd reload

  3. sudo yum install xauth
  4. ssh trở lại máy chủ RHEL của bạn với công tắc -X: ssh -X yourname@rhelbox
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.