우분투 원격 데스크톱(xrdp) 설정: 접속 불능을 피하려고 확인할 것들

원격 데스크톱 설정에서 정말 곤란한 상황은 설치가 안 되는 것이 아니라, 설정을 바꾼 뒤 원격 접속도 로컬 로그인도 안 되어 기계에 손댈 수 없게 되는 것이다. 이 글은 그 위험을 줄이려는 순서를 정리한다. 우분투 24.04 컨테이너(aarch64)에 apt install xrdp를 해서 확인한 내용과, 컨테이너라서 확인하지 못한 내용을 구분해서 적는다.

컨테이너에서 확인한 것

xrdp를 설치하면 /etc/xrdp/ 아래에 다음 파일이 생겼다.

• xrdp.ini: 접속 포트, 보안 계층, 세션 종류 메뉴
• sesman.ini: 세션 관리자 설정
• startwm.sh: 로그인 뒤 실행되는 시작 스크립트
• reconnectwm.sh, rsakeys.ini, xrdp_keyboard.ini

xrdp.ini의 주요 값은 [Globals]에서 port=3389, security_layer=negotiate, crypt_level=high였다. 세션 종류를 정하는 항목으로 [Xorg]와 [Xvnc]가 있었고, 이 항목에서 port=-1로 보이는 것은 자동 할당을 뜻하는 설정이다. 마지막에 port=ask5900, port=ask3389로 시작하는 접속 대상 항목도 있었다.

startwm.sh의 주석을 뺀 내용은 짧다. /etc/profile과 ~/.profile을 읽은 뒤 /etc/X11/Xsession을 exec로 실행한다. 이 스크립트가 틀리면 로그인 직후 세션이 바로 끝나는 증상이 나올 수 있으므로, 수정할 때 가장 조심할 파일이다. 다만 그런 증상은 이 컨테이너에서 재현해 보지 않았다.

패키지 정보로는 ssl-cert에 의존하고(그룹 ssl-cert가 생성됨), xorgxrdp와 pipewire-module-xrdp를 권장 패키지로 두며 guacamole을 제안한다. 권장 패키지를 빼고 설치하면 화면이나 소리가 빠질 수 있다는 점만 의식해 두면 된다. 실제로 빠지는지는 확인하지 못했다.

xrdp를 실제로 띄워 보고 확인한 것

같은 컨테이너(Ubuntu 24.04)에서 xrdp와 xrdp-sesman을 직접 실행해 보았다. systemd가 없어서 서비스가 아니라 프로그램을 직접 시작했다. 데스크톱 환경이 없으므로 RDP 클라이언트로 로그인하는 단계까지는 가지 못했다.

확인	결과
설치된 버전	xrdp 0.9.24
ss -tlnp	*:3389를 xrdp가, [::1]:3350을 xrdp-sesman이 대기
프로세스	xrdp-sesman, xrdp 두 개
sesman.ini의 ListenPort	3350 (세션 관리자는 외부가 아닌 로컬에서만 받음)
EnableUserWindowManager, UserWindowManager, DefaultWindowManager	true, startwm.sh, startwm.sh
MaxSessions	50
KillDisconnected, DisconnectedTimeLimit	false, 0 (끊긴 세션을 지우지 않고 시간 제한도 없음)
잘못된 형식의 접속 패킷을 보냈을 때 /var/log/xrdp.log	xrdp_sec_incoming: xrdp_iso_incoming failed, xrdp_process_main_loop: libxrdp_process_incoming failed 같은 ERROR가 시각과 함께 기록됨

여기서 알 수 있는 것:

• 외부에 열리는 포트는 3389 하나이고 3350은 로컬 전용이라 방화벽 규칙은 3389만 다루면 된다(외부에 직접 여는 것이 안전한지는 앞 절의 SSH 터널 이야기를 참고).
• 접속이 안 될 때 가장 먼저 볼 로그는 /var/log/xrdp.log와 /var/log/xrdp-sesman.log다. 클라이언트가 접속을 시도하면 이 로그에 시각과 단계(xrdp_iso_incoming, xrdp_sec_incoming 등)가 남는다. 이 실험에서 일부러 보낸 틀린 패킷도 어느 단계에서 실패했는지 로그로 구분할 수 있었다. 실제로 로그인이 실패하는 원인(인증, 세션 시작 스크립트)별 로그 모양은 이 환경에서 만들어 보지 못했다.
• KillDisconnected=false 기본값 때문에 창만 닫고 끊은 세션이 서버에 남는다. 같은 계정으로 다시 접속하면 이전 세션에 붙을 수도 있고 새 세션이 생기기도 하는데, 이 동작은 이 환경에서 확인하지 못했다. 세션이 쌓이는 것이 문제라면 DisconnectedTimeLimit(초)을 정하는 방법이 있다.

설정을 바꾼 뒤 확인하는 명령 모음

sudo ss -tlnp | grep -E '3389|3350'     # xrdp가 포트를 열었는지
sudo tail -n 50 /var/log/xrdp.log        # 접속 시도와 실패 단계
sudo tail -n 50 /var/log/xrdp-sesman.log # 세션 시작(로그인, startwm.sh) 쪽
sudo systemctl status xrdp xrdp-sesman   # 서비스 상태 (컨테이너에서는 실행하지 못함)

위 네 가지 중 ss와 두 로그 파일은 컨테이너에서 확인했다(/var/log/xrdp.log는 소유자 xrdp, /var/log/xrdp-sesman.log는 root이고 둘 다 그룹 adm만 읽을 수 있으며, 시작하자 starting xrdp-sesman with pid ...가 INFO로 기록됐다. 로그 수준은 sesman.ini의 LogLevel=INFO). systemctl 명령은 systemd가 없어 실행하지 못했다. 설정을 하나 바꿀 때마다 ss로 포트, 로그로 오류를 확인하면 어느 변경이 문제인지 좁히기 쉽다.

설정을 바꾸기 전에 할 것

1. SSH 접속을 먼저 확보한다. 원격 데스크톱이 안 열려도 SSH가 되면 복구할 수 있다. 다른 터미널 하나로 SSH 세션을 열어 두고 작업한다.
2. 백업한다. sudo cp -a /etc/xrdp /etc/xrdp.bak처럼 설정 디렉터리 전체를 복사해 둔다. 홈 디렉터리의 ~/.xsession, ~/.xsessionrc도 있으면 같이 복사한다.
3. 한 번에 하나만 바꾼다. 설정을 두세 개 같이 바꾸면 어느 것이 원인인지 알 수 없다.
4. 바꾼 뒤에는 현재 세션을 닫기 전에 새 세션으로 접속해 본다. 기존 연결을 끊지 않은 채로 다른 클라이언트로 접속이 되는지 확인한 뒤에 기존 연결을 닫는다.
5. 서비스 재시작은 SSH에서 한다. sudo systemctl restart xrdp로 재시작하고 systemctl status xrdp와 journalctl -u xrdp로 로그를 확인한다. 이 명령은 컨테이너에 systemd가 없어 실행해 보지 못했다.

포트를 그대로 열지 않는다

기본 포트가 3389이므로 공유기나 방화벽에서 이 포트를 인터넷에 그대로 여는 것은 위험하다. 외부에서 접속해야 한다면 SSH 터널(ssh -L 3389:localhost:3389 사용자@서버)로 연결하고 클라이언트는 localhost:3389로 접속하는 방법이 있다. 이 방식은 명령 형태만 소개하며 이 글에서 연결까지 확인하지는 않았다.

접속이 안 될 때 확인 순서

원인을 좁히는 순서를 적는다. 각 단계의 결과는 환경에 따라 다르다.

1. 서비스 상태: systemctl status xrdp xrdp-sesman
2. 포트 대기 여부: ss -tlnp | grep 3389
3. 방화벽: sudo ufw status
4. 로그: journalctl -u xrdp -u xrdp-sesman, /var/log/xrdp-sesman.log
5. 같은 계정으로 로컬 데스크톱에 이미 로그인된 상태인지. 같은 계정의 로컬 세션과 원격 세션이 겹치면 문제가 생길 수 있는지는 이 글에서 확인하지 못했다.

확인하지 못한 것

• 데스크톱 환경(GNOME)과 Wayland 세션에서의 로그인
• startwm.sh를 잘못 고쳤을 때의 정확한 증상과 복구 방법
• 오디오 리다이렉션과 클립보드 동작
• 실제 클라이언트(Windows 원격 데스크톱 연결, macOS용 Microsoft Remote Desktop)에서의 접속

우분투 초기 설정 전반은 우분투 개발 환경 초기 설정에서 다룬다.