내 메인 호스트 [ A
] (화면 있음) 에서 ssh
중계 시스템 [ B
] (화면 있음 -X
)으로 이동하고 거기에서 대상 시스템 [ C
] (다시 화면 있음 -X
)에 로그인하면 X 전달이 작동하는 것 같습니다. 한동안은 괜찮아 . vim에서 대상 컴퓨터 [ ]에서 작업한 후 갑자기 X 전달 기능을 사용할 수 없게 되었고, C
로그아웃한 후 SSH 세션을 다시 시작해야 했고 다시 정상적으로 작동했습니다. 이는 정상적인 하루 동안 발생합니다. 즉, 호스트가 정지되거나 전원이 꺼지지 않습니다.C
B
X
모든 것이 예상대로 작동하면 C
다음이 표시됩니다.
$ echo $DISPLAY
localhost:10.0
유사한 애플리케이션이 화면에 잘 xeyes
전달되고 렌더링됩니다 . A
그러면 갑자기 다음과 같이 보고됩니다.
$ xeyes
Error: Can't open display: localhost:10.0
$ echo $DISPLAY
localhost:10.0
수상한 징후 도 /var/log/syslog
없으며 SSH 세션은 활성 상태로 유지되고 다시 정상적으로 실행됩니다 journalctl
. C
문제가 무엇인지 아는 사람이 있습니까?
호스트에 대한 자세한 내용:
A
물리적인 만자로 박스입니다(LAN에 연결되어 있음)B
물리적 Ubuntu 21.04 시스템(LAN에 연결됨)C
Ubuntu 18.04를 실행하는 가상 머신입니다B
(NAT를 통해 연결됨).
답변1
ForwardX11Trusted
Debian's man 항목에 이에 대한 설명이 있습니다.ssh_config
, Ubuntu는 Debian과 동일하게 동작하지만 Manjaro와는 다릅니다.
ForwardX11Trusted
이 옵션이 다음으로 설정된 경우예, (Debian 특정 기본값), 원격 X11 클라이언트는 원래 X11 디스플레이에 대한 전체 액세스 권한을 갖게 됩니다.
이 옵션이 다음으로 설정된 경우아니요(업스트림 기본값), 원격 X11 클라이언트는 신뢰할 수 없는 클라이언트로 처리되며 신뢰할 수 있는 X11 클라이언트에 속한 데이터는 도난당하거나 변조되는 것을 방지합니다. 또한, 세션에 사용된 xauth(1) 토큰은 20분 후에 만료되도록 설정됩니다. 이 시간이 지나면 원격 클라이언트의 액세스가 거부됩니다.
이것은 주로 Debian 기반 시스템(예: Ubuntu)을 사용하는 경우 이전에 이 문제가 발생하지 않았을 수 있는 이유를 설명할 수 있습니다.
이 옵션을 활성화하는 바로가기는 입니다 -Y
. 그래서 당신은 단순히 첫 번째 것으로 -X
바꿀 수 있습니다-Y
SSH문제를 "수정"하는 명령입니다.
그런데 X11 디스플레이를 두 번 전달하는 것은 최선의 접근 방식이 아닙니다. 특히 -Y
이것이 다중 사용자 배스천 시스템인 경우 X11 디스플레이는 중간 시스템 B의 다른 사용자에게 노출됩니다. 대상 머신 C의 포트 22를 전달하고 다른 모든 것을 이를 통해 터널링하는 것이 더 좋습니다. 다행히도 이를 위해 특별히 설계된 몇 가지 옵션이 있습니다.ProxyJump
옵션 및 단축키 -J
. 마지막으로 머신 A에서 실행할 수 있습니다.
ssh -Y -J userb@computerB userc@machineC