호스트 시스템에 나타나도록 KVM 게스트에서 X11 애플리케이션을 실행합니다.

Question 1

SSH에 대한 X11 전달은 일반 포트 전달보다 조금 더 뛰어나며 적어도 원하는 것을 달성하는 가장 쉬운 방법일 것입니다.사용자보다.

네가 원한다면기술적으로더 간단히 말하면, X11이 원래 어떻게 사용되도록 구상되었는지 이해해야 합니다.

X11 지원 시스템이 많은 환경에서는 사용자 정보가 NIS를 통해 중앙에서 관리될 수 있으며 홈 디렉토리는 전용 디스크 서버에서 NFS(일부 자동 설치 포함)가 있는 다른 모든 시스템으로 공유될 수 있습니다. 또한 모든 컴퓨터는 서로의 호스트 이름을 확인할 수 있어야 합니다. 신뢰할 수 있는 내부 네트워크에서는 (아마도) X11 서버의 TCP 수신 포트를 비활성화하지 않습니다.

이러한 환경에서는 한 호스트에서 다른 호스트로 연결할 수 있습니다. DISPLAY원격 X11 클라이언트 프로그램이 로컬 X11 서버와 로컬 모니터에 직접 연결할 수 있도록 환경 변수가 올바르게 설정되었는지 확인하세요. 홈 디렉토리는 NFS와 공유되므로 ~/.Xauthority원격 호스트와 로컬 호스트 모두 동일한 디렉토리를 봅니다.

NIS가 없으면 어떻게 되나요? 이것은 X11의 문제가 아닙니다. 실제로는 ID에 관심이 없습니다. X11 서버에 연결하는 모든 클라이언트가 파일 ~/.Xauthority(또는 환경 변수가 가리키는 기본이 아닌 파일 )에서 XAUTHORITY올바른 X11 인증 쿠키를 제공 할 수 있는 한 X11은 작동합니다. 단, 공유 UID/GID 번호가 할당되지 않은 경우 홈디렉토리는 공유되지 않을 수 있습니다.

공유 홈 디렉터리가 없나요? 이 경우 X11 인증 쿠키도 전달해야 합니다. 일반적으로 예를 들어 디스플레이 호스트에서 쿠키를 추출한 다음 콘텐츠를 xauth nextract /some/file :0.0원격 호스트로 전송하고 거기에서 이를 사용하여 원격 호스트의 파일에 추가합니다./some/filexauth nmerge~/.Xauthority

xhost +(또는 다음을 사용하여 보안 검사를 완전히 비활성화하거나 특정 원격 호스트에 대해서만 비활성화 할 수 있습니다.아주 나쁜 생각이야: 원격 호스트에 다른 사용자가 있는 경우 전체 X11 세션에 대한 모든 키보드 및 마우스 이벤트를 모니터링하는 등의 xsnow위험, 감염 또는 더 심각한 결과를 초래할 수 있습니다. xroach)

그러나 암호화되지 않은 X11 프로토콜은 상당한 보안 허점이 있는 것으로 밝혀졌습니다. 당시 미국 암호화폐 수출법으로 인해 전 세계는 X11 포워딩과 함께 SSH를 사용하고 X11 서버의 TCP 포트를 비활성화하기로 결정했습니다. X 서버는 Xorg -nolisten tcp <other options...>.

최근 X.org는 이를 인식하고 TCP 수신 논리를 뒤집었습니다. -nolisten tcp기본적으로 X11 서버를 시작할 때 Linux 배포판에 해당 옵션이 없으면 X11 서버 버전에 실제로 하나의 명시적 -listen tcp옵션이 필요하기 때문일 수 있습니다. 고전적이고 안전하지 않은 X11 TCP 수신기.

그럼... 예, 다음을 수행할 수 있습니다.

호스트의 X11 서버에서 TCP 수신기를 활성화합니다.
가상 머신이 호스트의 IP 주소를 확인하고 호스트의 포트 6000(= :0.0TCP의 DISPLAY에 해당) 에 연결할 수 있는지 확인하세요.
가상 머신이 DISPLAY변수를 가리키도록 준비하십시오.kvmhost:0.0
X11 인증 쿠키를 VM에 전달하는 데 필요한 단계를 수행합니다.

이를 통해 X11은 추가적인 기술적 복잡성을 최소화하면서 "고전적인 방식"으로 작동할 수 있습니다. 하지만 훨씬 더 복잡하다실제 설정를 사용할 뿐만 아니라 ssh -X virtualmachine고대의 잘 알려진 다양한 공격에 노출될 수 있습니다.

Answer

SSH에 대한 X11 전달은 일반 포트 전달보다 조금 더 뛰어나며 적어도 원하는 것을 달성하는 가장 쉬운 방법일 것입니다.사용자보다.