SSH X11 không hoạt động


15

Tôi có một máy tính ở nhà và làm việc, máy tính ở nhà có một địa chỉ IP tĩnh.

Nếu tôi ssh từ máy tính làm việc đến máy tính ở nhà, kết nối ssh hoạt động nhưng các ứng dụng X11 không được hiển thị.

Ở nhà tôi /etc/ssh/sshd_config:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Trong công việc tôi đã thử các lệnh sau:

xhost + home HOME_IP
ssh -X home
ssh -X HOME_IP
ssh -Y home
ssh -Y HOME_IP

Tôi /etc/ssh/ssh_configở chỗ làm

Host *
ForwardX11 yes 
ForwardX11Trusted yes

Tôi ~/.ssh/configở chỗ làm

Host home
HostName HOME_IP
User azat
PreferredAuthentications password
ForwardX11 yes

Tôi ~/.Xauthorityở chỗ làm

-rw------- 1 azat azat 269 Jun  7 11:25 .Xauthority

Tôi ~/.Xauthorityở nhà:

-rw------- 1 azat azat 246 Jun  7 19:03 .Xauthority

Nhưng nó không hoạt động

Sau khi tôi thực hiện kết nối ssh đến nhà:

$ echo $DISPLAY
localhost:10.0

$ kate
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
kate: cannot connect to X server localhost:10.0

Tôi sử dụng iptablesở nhà, nhưng tôi đã cho phép cổng 22. Theo những gì tôi đã đọc đó là tất cả những gì tôi cần.

CẬP NHẬT. Với-vvv

...
debug2: bắt đầu gọi lại
debug2: x11_get_proto: / usr / bin / xauth danh sách: 0 2> / dev / null
debug1: Yêu cầu chuyển tiếp X11 với giả mạo xác thực.
debug2: kênh 1: yêu cầu x11-req xác nhận 1
debug2: client_session2_setup: id 1
debug2: fd 3 cài đặt TCP_NODELAY
debug2: kênh 1: yêu cầu pty-req xác nhận 1
...

Khi thử khởi chạy kate:

debug1: client_input_channel_open: ctype x11 rchan 2 thắng 65536 tối đa 16384
debug1: client_Vquest_x11: yêu cầu từ 127.0.0.1 55486
debug2: fd 8 cài đặt O_NONBLOCK
debug3: fd 8 là O_NONBLOCK
debug1: kênh 2: mới [x11]
gỡ lỗi1: xác nhận x11
debug2: Kết nối X11 sử dụng giao thức xác thực khác nhau.
Kết nối X11 bị từ chối vì xác thực sai.
debug2: X11 bị từ chối 2 i0 / o0
debug2: kênh 2: đọc thất bại
debug2: kênh 2: close_read
debug2: kênh 2: mở đầu vào -> cống
debug2: kênh 2: ibuf trống
debug2: kênh 2: gửi eof
debug2: kênh 2: cống đầu vào -> đã đóng
debug2: kênh 2: viết không thành công
debug2: kênh 2: close_write
debug2: kênh 2: đầu ra mở -> đã đóng
debug2: X11 đã đóng 2 i3 / o3
debug2: kênh 2: gửi gần
debug2: kênh 2: RCvd đóng
debug2: kênh 2: đã chết
debug2: kênh 2: thu gom rác
gỡ lỗi1: kênh 2: miễn phí: x11, nchannels 3
debug3: channel 2: status: Các kết nối sau đang mở:
  Phiên khách số 1 (t4 r0 i0 / 0 o0 / 0 fd 5/6 cc -1)
  # 2 x11 (t7 r2 i3 / 0 o3 / 0 fd 8/8 cc -1)

# Giống như trên lặp lại khoảng 7 lần

kate: không thể kết nối với máy chủ X localhost: 10.0

UPD2 Vui lòng cung cấp số phiên bản và số phân phối Linux của bạn.
Bạn có đang sử dụng môi trường Gnome hoặc KDE mặc định cho X hoặc thứ gì khác mà bạn tự tùy chỉnh không?

azat: ~ $ kded4 -version
Qt: 4.7.4
Nền tảng phát triển KDE: 4.6.5 (4.6.5)
Daemon KDE: $ Id $

Bạn đang gọi ssh trực tiếp trên một dòng lệnh từ cửa sổ terminal?
Bạn đang sử dụng thiết bị đầu cuối nào? xterm, gnome-terminal, hay?
Làm thế nào bạn bắt đầu thiết bị đầu cuối chạy trong môi trường X? Từ thực đơn? Hotkey? hoặc là ?

Từ trình giả lập thiết bị đầu cuối `yakuake`
Nhấn thủ công `Ctrl + N` và viết lệnh

Bạn có thể chạy xeyes từ cùng một cửa sổ terminal trong đó ssh -X không thành công?

`xeyes` - chưa được cài đặt
Nhưng `kate` hoặc một ứng dụng kde khác đang chạy

Bạn có đang gọi lệnh ssh với cùng một người dùng mà bạn đã đăng nhập vào phiên X không?
From the same user

CẬP NHẬT

Tôi cũng tải xuống sshcác nguồn và sử dụng debug2()viết tại sao nó báo cáo phiên bản đó khác.
Nó thấy một số cookie và một trong số đó trống, một cái khác làMIT-MAGIC-COOKIE-1

Câu trả lời:


21

Lý do chuyển tiếp ssh X không hoạt động là vì tôi có /etc/ssh/sshrctệp cấu hình.

Phần cuối của sshd(8)trang man ghi:

Nếu ~/.ssh/rctồn tại, chạy nó; khác nếu /etc/ssh/sshrctồn tại, chạy nó; nếu không thì chạy xauth

Vì vậy, tôi thêm các lệnh sau vào /etc/ssh/sshrc(cũng từ trang sshd man) ở phía máy chủ:

if read proto cookie && [ -n "$DISPLAY" ]; then
        if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
                # X11UseLocalhost=yes
                echo add unix:`echo $DISPLAY |
                    cut -c11-` $proto $cookie
        else
                # X11UseLocalhost=no
                echo add $DISPLAY $proto $cookie
        fi | xauth -q -
fi

Và nó hoạt động!


Bạn làm điều đó trên máy khách hay phía máy chủ?
alfonx 16/12/13

Về phía máy chủ. (/ etc / ssh / sshrc được thực thi khi máy khách được kết nối)
azat 16/12/13

2

Bất cứ khi nào bạn gặp sự cố với ssh, điều đầu tiên bạn nên làm là chạy ứng dụng khách với -vtùy chọn cung cấp đầu ra đó cho người khác kiểm tra:

ssh -v user@somewhere

Tôi sẽ đoán rằng vấn đề là trên hệ thống địa phương của bạn. Làm thế nào bạn đang gọi lệnh ssh? Bạn đang chạy nó bằng tay trong một vỏ? Hoặc nó đang được thực hiện như là một phần của một kịch bản? Trong cả hai trường hợp, bạn sẽ muốn đảm bảo rằng hệ thống cục bộ của bạn có DISPLAYmôi trường được đặt chính xác. Nó cũng cần phải được đặt chính xác ở phía xa, nhưng giá trị đó sẽ khác ở phía xa so với phía cục bộ.

Từ những gì bạn đã viết, có vẻ như nó đang được đặt chính xác trên máy chủ từ xa (và bằng cách mở rộng, chuyển tiếp X11 đang được thiết lập chính xác bởi ssh). Trên hệ thống từ xa, bạn có:

$ echo $DISPLAY
localhost:10.0

Điều đó thể hiện ở phía địa phương là gì? Điều đó sẽ dễ dàng kiểm tra xem bạn có đang ở trong vỏ không bằng cách lặp lại giá trị, cũng như bắt đầu một ứng dụng X từ vỏ đó ... tất nhiên, bạn luôn có thể sử dụng mức độ đáng kính xeyescho loại thử nghiệm đó! :)

Mặt khác, nếu bạn đang gọi lệnh ssh từ một tập lệnh hoặc được gắn vào một phím nóng, nó có thể không kế thừa môi trường mà bạn mong đợi, do đó, DISPLAYbiến môi trường ở phía cục bộ hoàn toàn không thể được đặt.

Ngoài ra, vì có vẻ như bạn đang loay hoay với .Xauthoritytệp của mình, bạn có thể muốn xóa hoàn toàn tệp đó, sau đó đăng xuất khỏi phiên X của bạn và đăng nhập lại để nó sẽ tự động tạo lại. Rất hiếm khi cần phải làm quen với bạn .Xauthority, vì vậy cố gắng có thể chỉ là một biện pháp tuyệt vọng sẽ không giúp được gì.

Những gì bạn nên thấy ở phía địa phương là:

$ echo $DISPLAY
:0.0

Trên một hệ thống cấu hình đúng nếu bạn mở một shell, bạn không cần phải thiết lập nó bằng tay, nó sẽ được kế thừa từ môi trường bắt đầu shell của bạn. Tuy nhiên tôi đã thấy các trình quản lý cửa sổ / cấu hình phím nóng không xử lý đúng cách kế thừa biến môi trường. Nếu bạn có hệ thống linux đang chạy gnome-sessionhoặc kde-sessionbạn sử dụng để khởi chạy shell hoặc script từ đó, thì các biến môi trường phiên X của bạn sẽ được đặt chính xác như được mô tả trong tài liệu Ubuntu về kế thừa các biến môi trường :

Khi một tiến trình cha tạo ra một tiến trình con, ví dụ khi chúng ta chạy lệnh "gedit" từ thiết bị đầu cuối và "bash" (tiến trình cha mẹ) tạo ra "gedit" (tiến trình con), tiến trình con kế thừa tất cả các biến môi trường và giá trị quá trình cha mẹ đã có.

...

Lưu ý: trong môi trường máy tính để bàn đồ họa Gnome, phiên gnome là quy trình mẹ của tất cả các quy trình đang chạy trên máy tính để bàn. Thực tế này (cùng với nguyên tắc Kế thừa) là chìa khóa cho khả năng ảnh hưởng mạnh mẽ đến hoạt động của máy tính để bàn của chúng tôi với các biến môi trường. Quá trình tương đương trong KDE là phiên kde.

CẬP NHẬT

Cảm ơn đã gửi đầu ra từ ssh -vvv. Trong trường hợp này, độ dài thêm từ -vvvso với chỉ -vlà hữu ích. Đầu ra gỡ lỗi cho tôi biết rằng chuyển tiếp X11 đang được thiết lập chính xác:

debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 1: request x11-req confirm 1

Nhưng :0dòng đầu tiên khiến tôi tin rằng vẫn còn lỗi cấu hình ở phía cục bộ theo cách bạn đang gọi ssh. Trên nhiều hệ thống, giá trị mặc định DISPLAY:0.0không :0. Bạn bằng cách nào đó thiết lập giá trị của DISPLAYchính mình trước khi gọi lệnh ssh?

Thông tin thêm về hệ thống cục bộ của bạn và cách bạn gọi lệnh ssh sẽ hữu ích vào thời điểm này.

  • Vui lòng cung cấp số phiên bản và số phân phối Linux của bạn.
  • Bạn có đang sử dụng môi trường Gnome hoặc KDE mặc định cho X hoặc thứ gì khác mà bạn tự tùy chỉnh không?
  • Bạn đang gọi ssh trực tiếp trên một dòng lệnh từ cửa sổ terminal?
  • Bạn đang sử dụng thiết bị đầu cuối nào? xterm, gnome-terminal, hay?
  • Làm thế nào bạn bắt đầu thiết bị đầu cuối chạy trong môi trường X? Từ thực đơn? Hotkey? hoặc là ?
  • Bạn có thể chạy xeyestừ cùng một cửa sổ thiết bị đầu cuối nơi ssh -Xthất bại?
  • Bạn có đang gọi lệnh ssh với cùng một người dùng mà bạn đã đăng nhập vào phiên X không?

Mục cuối cùng này là quan trọng. Nếu bạn đang chạy ssh với tư cách người dùng khác (ví dụ: nếu bạn đã mở cửa sổ thiết bị đầu cuối gốc thay vì cửa sổ thiết bị đầu cuối người dùng), thì bạn sẽ gặp phải sự cố này ngay cả khi bạn đang cài đặt rõ ràng DISPLAY=:0vì bạn không có quyền kết nối với máy chủ X theo mặc định là người dùng khác (thậm chí là root!)


Cập nhật câu hỏi cơ thể
azat

Tôi đã thêm một phần CẬP NHẬT mới yêu cầu thêm thông tin để giúp gỡ lỗi này hơn nữa.
aculich

Tôi không t set hiển thị thủ công. Trong thực tế tôi nghĩ rằng tôi hiểu tại sao nó không hoạt động, bởi vì X -nolistentrên máy cục bộ
azat

-nolistenkhông có gì để làm với vấn đề này. Theo như X có liên quan thì nó không biết gì về kết nối ssh từ xa của bạn. Đối với X, nó trông giống như bất kỳ chương trình địa phương khác.
aculich

1
sshdcũng có thể được bắt đầu ở phía trước với độ dài thêm trong trường hợp vấn đề nằm ở phía máy chủ.
0xC0000022L

1

Cấu hình của bạn có vẻ ổn, nhưng hãy thử "ssh -X home" như Agemen đề xuất.

Ngoài ra, nếu vẫn thất bại, hãy thử điều này:

Sau khi bạn ssh đến máy gia đình của bạn từ nơi làm việc, trên loại "nhà":

xauth list

Sau đó, vào "công việc", gõ

xauth

Nó sẽ cung cấp cho bạn một dấu nhắc "xauth>". Từ đây, nhập "thêm", sau đó sao chép dán đầu ra của "danh sách xauth", mỗi dòng một dòng (mỗi dòng được mở đầu bằng "thêm"). Ví dụ:

someguy@work:~$ xauth
Using authority file /var/run/gdm/auth-for-someguy-4MYV85/database
xauth> add work/unix:0  MIT-MAGIC-COOKIE-1  781cc753194fd55ecdf6c4cf105c40e3
xauth> 

Hãy cho chúng tôi biết.


Tôi đã thử ssh -X home(viết trong bài). Về xauth tôi sẽ thử vào ngày mai.
azat

Tôi đã thử xauth list & xauth add, nhưng vẫn không hoạt động
azat

Tôi đã thêm bản ghi này qua xauth add azat/unix:10 MIT-MAGIC-COOKIE-1 ad01c582768c832ff591277b27863bc7(vì $ DISPLAY = localhost: 10.0), nếu điều này có thể giúp
azat

-1

Tôi không hiểu rõ nếu bạn muốn hiển thị các ứng dụng từ xa trên màn hình cục bộ của mình (work ) hoặc nếu bạn muốn hiển thị chúng trên hệ thống từ xa ( home).

Trong trường hợp đầu tiên, tôi nghĩ ssh -X hostlà đủ, không cần sử dụng xhost.

Trong trường hợp thứ hai, hệ thống mà bạn cần sử dụng xhost homelà không đủ, bạn cũng cần xuất biến hiển thị.

xhost +work
export DISPLAY=:0.0

Tôi không hoàn toàn chắc chắn về những gì bạn muốn làm ... và vì tôi không biết sự khác biệt tồn tại giữa hệ thống của bạn và của tôi, mặt khác, và cấu hình chính xác cần thiết cho trường hợp của bạn (mặt khác Tôi không phải là chuyên gia ^ _ ^). Hy vọng nó sẽ giúp bạn trong một số cách, vì cấu hình này cũng đã làm việc cho tôi.


Tôi đã thử ssh -X home(viết trong bài). Có, tôi muốn hiển thị các ứng dụng từ xa trên màn hình cục bộ của mình.
azat
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.