Ubuntu VPS 설정: SSH, Nginx와 HTTPS로 첫 사이트 배포

서버, 도메인과 복구 접근 준비하기

공인 IPv4가 있는 새 Ubuntu 24.04 VPS, SSH 포트 22, sudo 사용이 가능한 초기 계정과 직접 관리하는 도메인을 준비하세요. 로컬 명령은 Linux·macOS·WSL의 Bash에서, 서버 명령은 SSH 안에서 실행합니다. 예시 경로에 기존 서비스가 있으면 멈추고 별도 테스트 서버를 사용하세요.

203.0.113.10과 app.example.com은 문서용 예시입니다. 모든 위치에서 실제 주소와 호스트명으로 바꾸세요. 초기 사용자 ubuntu도 제공업체가 정한 이름으로 바꿉니다. 접근이나 방화벽을 바꾸기 전에 복구 콘솔을 열고 이미지의 방화벽 지침을 확인하세요. Oracle Cloud에는 아래 UFW 분기를 적용하지 않습니다.

키를 만들고 기존 접근을 유지한 채 연결 확인하기

내 컴퓨터에서 전용 키를 생성하고 암호 문구를 정하세요. 같은 이름이 있으면 이후 명령을 포함해 다른 이름을 사용합니다. .pub는 공개 키이며 개인 키는 컴퓨터 밖으로 보내지 않습니다.

mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/ubuntu_vps
cat ~/.ssh/ubuntu_vps.pub

새 VPS를 만들 경우 지금 Ubuntu 24.04 인스턴스를 생성하면서 이 공개 키를 등록하세요. 초기 계정을 확인하고 아래 호스트 지문 확인으로 이동합니다. 기존 서버용 복사·추가 명령은 건너뜁니다.

이미 만들어진 빈 VPS라면 기존 SSH 세션을 유지하세요. 컴퓨터의 다른 터미널에서 현재 작동하는 인증으로 새 공개 키를 복사합니다. existing_vps_key는 기존 개인 키 이름입니다. 비밀번호나 에이전트로 접속한다면 -i ~/.ssh/existing_vps_key 부분만 생략하고 서버 인증 정책은 바꾸지 않습니다.

scp -i ~/.ssh/existing_vps_key ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

기존 서버 세션에서 업로드한 공개 키를 검사한 뒤 자신의 초기 계정 authorized_keys에 추가합니다. 기존 항목을 유지하며, 마지막 줄에 개행이 없는 파일도 구분되도록 개행을 추가합니다. 현재 접근이 전혀 없다면 먼저 제공업체의 복구 절차를 이용하세요.

if ssh-keygen -lf ~/ubuntu-vps-admin.pub; then
    mkdir -p ~/.ssh
    chmod 700 ~/.ssh
    printf '\n' >> ~/.ssh/authorized_keys
    cat ~/ubuntu-vps-admin.pub >> ~/.ssh/authorized_keys
    chmod 600 ~/.ssh/authorized_keys
fi

어느 경로든 첫 연결을 승인하기 전에 신뢰하는 복구 콘솔에서 해당 알고리즘의 서버 호스트 키 지문을 확인하세요. Ed25519라면 콘솔 안에서 다음을 실행합니다.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

내 컴퓨터에서 새 키로 별도 연결을 열고 지문을 비교합니다. 성공할 때까지 원래 접근을 유지하세요.

ssh -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

다른 로컬 터미널에서 다음 단계의 별도 관리자에게 사용할 공개 키를 복사합니다. 위 기존 서버 경로에서 같은 임시 공개 키 파일을 올렸어도 다시 복사할 수 있습니다.

scp -i ~/.ssh/ubuntu_vps ~/.ssh/ubuntu_vps.pub ubuntu@203.0.113.10:ubuntu-vps-admin.pub

별도 관리자를 만들고 새 세션에서 sudo 확인하기

서버에서 먼저 getent passwd deploy를 실행하세요. 계정이 나오면 사용하지 않는 이름을 정하고 홈 경로와 그룹명까지 모두 바꿉니다. 기존 사용자의 키 파일을 교체하지 않기 위한 확인입니다.

이미지와 자원을 확인하고 업그레이드를 검토한 뒤 새 관리자를 생성합니다. sudo 인증에 쓸 강한 비밀번호를 설정하세요. install 명령은 새 계정에 키 파일 소유권과 제한된 권한을 부여합니다.

cat /etc/os-release
free -h
df -h /
sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo install -m 600 -o deploy -g deploy ~/ubuntu-vps-admin.pub /home/deploy/.ssh/authorized_keys

내 컴퓨터의 새 터미널에서 별도 관리자로 접속합니다.

ssh -i ~/.ssh/ubuntu_vps deploy@203.0.113.10

그 새 서버 세션에서 아래 명령이 deploy의 비밀번호를 받아 root를 출력하는지 확인하세요. 새 접속과 sudo가 모두 작동하면 이 세션에서 계속하며 원래 접근도 유지합니다.

sudo whoami

Nginx 설치와 이미지에 맞는 방화벽 설정하기

서버에서 Nginx를 먼저 설치합니다. 제공업체 네트워크 방화벽과 게스트 방화벽이 모두 접근에 영향을 주므로 복구 콘솔과 작동 중인 SSH 세션을 유지하세요.

sudo apt install nginx
sudo systemctl enable --now nginx

제공업체 방화벽에서 관리 위치의 TCP 22와 방문자용 TCP 80/443을 허용합니다. SSH가 다른 포트라면 실제 포트 규칙을 유지하세요. 네트워크 허용만으로 게스트 방화벽 차단이 해제되지는 않습니다.

Oracle Cloud Ubuntu 이미지: 아래 UFW 명령 전체를 건너뛰세요. 이미지의 필수 방화벽 규칙과 충돌해 부팅이 막힐 수 있습니다. iSCSI 부트·블록 볼륨을 보호하는 기존 iptables 규칙을 유지하고 OCI 보안 목록/NSG와 문서화된 HTTP/HTTPS 게스트 규칙을 설정합니다. 규칙을 비우거나 방화벽 패키지를 교체하지 마세요.

UFW를 지원하는 다른 새 이미지: 제공업체가 허용하고 별도 관리 방화벽이 필요 없는 경우에만 사용합니다. 활성화 전에 실제 SSH 포트를 허용해야 하며 예시는 22입니다.

sudo apt install ufw
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

어느 분기든 새 SSH 연결을 검증하세요. 이미 열린 세션은 새 접속 시험이 아닙니다. 인증서 요청 전에는 다음 단계의 외부 HTTP 요청도 성공해야 합니다.

독립된 Nginx 사이트로 페이지 게시하기

서버에서 새 문서 루트와 설정 파일을 만듭니다. 블록 안의 호스트명을 바꾸고 따옴표가 있는 EOF 표시는 유지하세요. 그래야 셸이 Nginx의 $uri 같은 변수를 먼저 확장하지 않습니다.

sudo install -d -m 755 /var/www/first-site
printf '%s\n' '<!doctype html><html lang="ko"><title>첫 배포</title><h1>Ubuntu VPS에서 제공하는 페이지입니다</h1></html>' | sudo tee /var/www/first-site/index.html
sudo tee /etc/nginx/sites-available/first-site >/dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;
    server_name app.example.com;
    root /var/www/first-site;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s /etc/nginx/sites-available/first-site /etc/nginx/sites-enabled/first-site
sudo nginx -t

nginx -t가 성공했을 때만 서버에서 다시 불러오세요.

sudo systemctl reload nginx

DNS를 바꾸기 전에 내 컴퓨터에서 해당 호스트명을 서버 주소로 지정해 요청합니다. 기본 Nginx 환영 화면이 아닌 생성한 페이지 제목이 나와야 합니다.

curl --resolve app.example.com:80:203.0.113.10 http://app.example.com/

DNS와 HTTPS 인증서 연결하기

호스트명의 A 레코드를 VPS IPv4로 지정합니다. IPv6가 실제로 작동할 때만 AAAA를 게시하세요. 오래된 AAAA는 방문자와 인증서 검증을 다른 서버로 보낼 수 있습니다. 이 절차는 프록시 없이 DNS가 VPS를 직접 가리키는 경우입니다.

내 컴퓨터에서 --resolve 없이 http://app.example.com/를 요청해 페이지가 나오는지 확인합니다. 서버에서는 Ubuntu 저장소의 Certbot과 Nginx 플러그인을 설치합니다. Universe 저장소가 필요한 패키지이므로 찾을 수 없다는 오류가 나면 먼저 저장소 문제를 해결하세요.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com --redirect
sudo nginx -t
sudo certbot renew --dry-run
systemctl list-timers --all certbot.timer

이메일과 약관 안내에 따라 진행하면 Certbot이 해당 사이트 설정과 HTTP→HTTPS 리디렉션을 구성합니다. 갱신 타이머가 예약됐는지 확인하고 비활성 상태라면 sudo systemctl enable --now certbot.timer로 활성화합니다. HTTP 방식 검증과 갱신을 위해 포트 80 접근도 유지하세요.

외부 요청과 재부팅 후 동작 확인하기

내 컴퓨터에서 HTTP 리디렉션, HTTPS 인증서와 내용을 확인합니다. 인증서 검증 오류를 숨기는 curl -k 옵션은 추가하지 마세요.

curl -I http://app.example.com/
curl -I https://app.example.com/
curl -fsS https://app.example.com/

아직 실습 서버일 때 서버에서 sudo reboot를 실행합니다. 돌아오면 deploy로 다시 연결하고 systemctl is-active nginx 및 외부 HTTPS 요청을 반복하세요. 재부팅은 SSH를 끊는 정상 동작입니다. 서버가 돌아오지 않으면 복구 콘솔로 확인합니다.

실패 원인을 구분하고 복구 자료 보관하기

표를 가로로 움직이면 나머지 열을 볼 수 있습니다.

증상	먼저 확인할 항목
SSH 시간 초과	주소, 제공업체·게스트 방화벽과 복구 콘솔
공개 키 인증 실패	사용자, 개인 키와 authorized_keys 권한
기본 Nginx 페이지 표시	DNS 목적지, server_name과 활성 사이트
인증서 검증 실패	공개 A/AAAA와 포트 80 접근
Nginx 변경 후 실패	sudo nginx -t 및 sudo journalctl -u nginx -n 50 --no-pager

접속이 안 되면 SSH 오류 진단으로 네트워크, 서비스와 키 문제를 나눈 뒤 변경하세요. 사이트 파일, Nginx 설정, DNS와 재구축 절차는 VPS 밖에 보관하고 별도 서버에서 복원을 시험합니다. 인증서 개인 키를 보관한다면 보호된 저장소가 필요합니다.

파일 백업·복원 실습은 정적 페이지와 설정의 독립 사본을 검사합니다. 전체 복구에는 나머지 파일과 인증서, 서비스 설정도 필요합니다. 가용성과 인증서 만료를 감시하세요. 한 번의 성공이 다음 갱신까지 감시해 주지는 않습니다.

이 절차는 정적 파일을 제공합니다. 데이터베이스나 런타임에는 별도 서비스 설정과 백업 방법이 필요하며, 추가 후에는 자원을 다시 측정해야 합니다.

새 Ubuntu 24.04 VPS, 직접 DNS와 SSH 포트 22를 기준으로 한 문서 기반 예제입니다. 모든 제공업체 이미지에서 전체 절차를 실행한 결과는 아닙니다. OCI Ubuntu 이미지에서는 UFW 분기를 건너뛰세요.

자주 묻는 질문

기존 운영 사이트에서 그대로 실행해도 되나요?

별도 테스트 VPS를 먼저 사용하세요. 이 예제는 파일과 방화벽을 만들고 Certbot이 설정을 변경하므로 기존 사이트·접근 규칙과 복구 방법을 먼저 검토해야 합니다.

WordPress나 Node.js도 설치되나요?

정적 HTTPS 사이트까지만 구성합니다. 이후 런타임을 추가하고 시작 동작, 상태 확인과 데이터 복구를 별도로 검증하세요.

인증서가 한 번 발급되면 끝인가요?

자동 갱신 타이머, 검증 포트와 만료 감시가 필요합니다. dry-run과 실제 외부 HTTPS 확인도 수행하세요.

Ubuntu VPS 설정과 첫 HTTPS 웹사이트 배포

서버, 도메인과 복구 접근 준비하기

키를 만들고 기존 접근을 유지한 채 연결 확인하기

별도 관리자를 만들고 새 세션에서 sudo 확인하기

Nginx 설치와 이미지에 맞는 방화벽 설정하기

독립된 Nginx 사이트로 페이지 게시하기

DNS와 HTTPS 인증서 연결하기

외부 요청과 재부팅 후 동작 확인하기

실패 원인을 구분하고 복구 자료 보관하기

자주 묻는 질문

다음에 필요한 가이드

Ubuntu 이미지 선택과 배포 전 호환성 확인

Ubuntu VPS에서 SSH 연결 오류를 진단하는 방법

VPS 백업 복구를 파일 두 개로 연습하기

필요한 자원과 복구 조건을 비교하세요.