기준: 리눅스마스터 1급 출제 기준오류 제보
:1 → 5901). 화면을 픽셀로 통째 전송하며, 암호화가 약해 SSH 터널과 짝지어 쓴다.DISPLAY가 "그림을 어느 화면으로 보낼지" 정한다 — :0은 로컬, 호스트:0은 원격, ssh -X면 보통 localhost:10.0.xhost +는 전체 허용으로 매우 위험하다. 안전한 원격 GUI는 ssh -X(암호화 터널 + xauth 자동).| 구성요소 | 역할 |
|---|---|
| VNC 서버 | 원격(접속 대상) 컴퓨터에서 실행, 자기 화면을 전송 |
| VNC 뷰어(클라이언트) | 사용자 앞 컴퓨터에서 실행, 원격 화면을 표시·조작 |
| RFB 프로토콜 | VNC가 화면·입력을 주고받는 프로토콜 |
VNC 기본 포트 = 5900 + 디스플레이 번호
:0 → 5900
:1 → 5901
:2 → 5902# 서버 측: TigerVNC 서버 설치·실행
dnf install tigervnc-server
vncserver :1 # 디스플레이 1번(포트 5901)으로 서버 시작
vncpasswd # VNC 접속 비밀번호 설정
vncserver -kill :1 # 서버 종료
# 클라이언트 측: 뷰어로 접속
vncviewer 192.168.1.10:1 # 또는 192.168.1.10:5901⚠️ 함정: VNC 포트는 5900 + 디스플레이 번호다.
:1은 5901,:2는 5902다. "디스플레이 1번이 5900"이라고 적은 보기는 틀렸다(그건 :0). 이 +번호 계산이 핵심이다.
VNC는 RDP(윈도)와 같은 "화면 통째 전송" 방식이다. 화면의 픽셀을 압축해 보내므로, X 포워딩처럼 개별 창만 보내는 것과 달리 데스크톱 전체를 그대로 가져온다. 다만 VNC 자체는 암호화가 약하므로, 실무에서는 보통 SSH 터널 위에 VNC를 실어 안전하게 쓴다.
VNC가 SSH 터널과 짝지어 쓰이는 이유는 RFB 프로토콜의 암호화가 빈약하기 때문이다. ssh -L 5901:localhost:5901 user@host로 터널을 뚫고 vncviewer localhost:5901로 접속하면, 픽셀 데이터가 SSH 암호화 터널을 지나 안전해진다. "VNC + SSH 터널"이 실무 표준 조합이다.
| 구성요소 | 역할 |
|---|---|
| X 서버 | 화면·키보드·마우스 등 하드웨어를 관리, 그리기 요청을 받아 실제로 그림 |
| X 클라이언트 | 응용프로그램(터미널·브라우저 등), "이렇게 그려줘"라고 X 서버에 요청 |
| 윈도 매니저 | 창의 테두리·이동·최소화 등 창 관리(클라이언트의 일종) |
| 디스플레이 매니저 | 그래픽 로그인 화면(gdm, lightdm) 제공 |
[사용자 앞 모니터·키보드 = X 서버] ←─ 그리기 요청 ─ [응용프로그램 = X 클라이언트]
(화면을 가진 쪽이 서버) (그림을 부탁하는 쪽이 클라이언트)핵심 구분: 왜 역전됐나? X 서버는 "그리기 서비스를 제공하는 쪽"이고, 응용프로그램은 그 서비스를 "이용하는 쪽(클라이언트)"이기 때문이다. 서비스를 제공하는 게 서버라는 일반 원칙에는 충실하다 — 다만 "제공하는 서비스 = 화면 그리기"라는 점만 이해하면 된다. "화면 가진 쪽 = X 서버"가 정답 신호다.
⚠️ 함정: "원격 서버에서 실행한 프로그램이 X 서버"라는 보기는 틀렸다. 원격에서 돌더라도 응용프로그램은 항상 X 클라이언트이고, 그 그림이 표시되는 내 앞 화면이 X 서버다. 이 역전을 뒤집은 보기가 함정이 된다.
DISPLAY 환경변수로 안다.DISPLAY 형식 = 호스트:디스플레이번호.화면번호
:0 → 로컬 0번 디스플레이
:0.0 → 로컬 0번 디스플레이의 0번 모니터
192.168.1.5:0 → 원격 호스트 192.168.1.5의 0번 디스플레이# 현재 DISPLAY 확인
echo $DISPLAY
# :0
# 원격 X 서버로 출력하도록 지정(원격 디스플레이에 그림)
export DISPLAY=192.168.1.5:0
xclock # 이제 192.168.1.5의 화면에 시계가 뜸DISPLAY는 X 클라이언트에게 "그 그림을 어느 화면으로 보낼까"를 알려주는 주소다. 로컬이면 :0, 원격 화면에 띄우려면 호스트:0을 지정한다. SSH X11 포워딩(ssh -X)을 쓰면 이 DISPLAY가 자동으로 localhost:10.0 같은 값으로 설정돼 터널을 통해 안전하게 전달된다.
핵심 구분: DISPLAY가 :0이면 로컬, 호스트명:0이면 원격이다. SSH X11 포워딩에서는 보통 localhost:10.0처럼 10번대 디스플레이가 잡히는데, 이는 SSH가 터널 끝에 가상 X 디스플레이를 만들어 연결하기 때문이다. DISPLAY는 그림을 보낼 화면 주소다.
| 도구 | 방식 | 설명 |
|---|---|---|
| xhost | 호스트 기반 | 특정 호스트(IP) 단위로 X 서버 접근 허용/차단 |
| xauth | 쿠키 기반 | 매직 쿠키(MIT-MAGIC-COOKIE)로 사용자 단위 인증 |
# xhost — 호스트 단위 제어
xhost +192.168.1.5 # 이 호스트의 X 접근 허용
xhost -192.168.1.5 # 이 호스트 차단
xhost + # 모든 호스트 허용(위험! 보안 취약)
xhost - # 기본 인증으로 복귀
xhost # 현재 접근 목록 확인
# xauth — 매직 쿠키 기반 제어
xauth list # 현재 등록된 인증 쿠키 목록
xauth add ... # 쿠키 추가xhost +(인자 없이 +)는 모든 호스트의 X 접근을 허용하는 매우 위험한 명령이다. 누구나 내 화면을 캡처하거나 키 입력을 가로챌 수 있다. 시험에서 "보안상 위험한 명령"의 예가 된다. 반대로 xhost -는 호스트 기반 허용을 끄고 기본 인증으로 돌린다.
핵심 구분: xhost는 호스트(IP) 단위의 거친 제어, xauth는 매직 쿠키로 사용자 단위의 정밀한 제어다. xhost는 같은 호스트의 모든 사용자를 허용해버려 보안이 약하고, xauth는 쿠키를 가진 특정 사용자만 허용해 더 안전하다. 그래서 SSH X11 포워딩은 xauth 쿠키 방식을 쓴다.
실무에서 export DISPLAY=원격:0 + xhost + 조합으로 GUI를 띄우다 보안 사고로 이어질 수 있다. 그래서 오늘날은 평문 X 포워딩 대신 ssh -X(신뢰 시 -Y)로 암호화 터널 + xauth 쿠키를 자동 처리하는 방식이 표준이다. "원격 GUI를 안전하게 = ssh -X"로 정리된다.
# SSH X11 포워딩으로 원격 프로그램을 내 화면에 띄우기
ssh -X alice@192.168.1.10
echo $DISPLAY # localhost:10.0 (포워딩으로 자동 설정됨)
xclock # 원격에서 실행되나 내 화면에 표시됨
xeyes # 또 다른 X 클라이언트 테스트:0 로컬, 호스트:0 원격)xhost +(인자 없음)는 전체 허용으로 매우 위험ssh -X(X11 포워딩, xauth 자동):0, :1 같은 화면 식별자. VNC 포트는 여기에 5900을 더해 정해진다.DISPLAY : X 클라이언트가 그림을 보낼 화면 주소. 호스트:디스플레이번호.화면번호 형식이다.xhost +(인자 없음) : 모든 호스트를 허용하는 매우 위험한 명령. 화면 캡처·키 입력 가로채기가 가능해진다.ssh -X) : 원격 응용프로그램의 GUI를 SSH 암호화 터널로 내 화면에 띄우는 기능. xauth 쿠키를 자동 처리한다.선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
X 윈도 시스템에서 X 서버와 X 클라이언트의 역할로 옳은 것은?
문제 2
VNC 서버를 디스플레이 :2로 실행했을 때 기본적으로 사용하는 TCP 포트는?
문제 3
X 클라이언트가 그림을 출력할 대상 X 서버(화면)를 지정하는 환경변수는?
문제 4
다음 중 보안상 매우 위험하여 권장되지 않는 X 접근 제어 명령은?
문제 5
원격 컴퓨터의 데스크톱 화면 전체를 픽셀 단위로 전송하여 그대로 조작하게 해주는 원격 접속 방식은?
문제 6
xhost와 xauth의 X 접근 제어 방식 차이로 옳은 것은?
문제 7
SSH X11 포워딩(ssh -X)을 사용해 원격 프로그램을 실행했을 때의 동작으로 옳은 것은?