Ubuntu VPS root 비밀번호 변경 방법

Ubuntu에서 VPS root 암호를 변경하는 방법

Ubuntu에서 VPS(가상 사설 서버)의 root 암호를 변경하려면 sudo을 실행할 수 있는 사용자로 SSH(보안 셸) 세션을 연 다음 sudo passwd root을 실행합니다. 새 암호를 2번 입력하라는 메시지가 표시되며 기존 암호는 묻지 않습니다. sudo이 이미 사용자의 신원을 확인했기 때문입니다. 자신의 로그인 암호를 변경하려면 인수 없이 passwd을 실행합니다. 이 경우 먼저 현재 암호를 입력하라는 메시지가 표시됩니다.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

작업은 이것으로 끝입니다. 아래 내용은 문제가 발생하는 경우를 다룹니다. 세션이 끊겨 문제를 해결할 수 없게 되기 전에 새 암호가 작동하는지 확인하는 방법, 스크립트에서 암호를 설정하는 방법, 암호를 의도적으로 만료시키는 방법, 암호를 이미 잃어버린 경우 다시 로그인하는 방법을 설명합니다.

비밀번호를 변경하기 전에 두 번째 세션 열기

지금 두 번째 SSH 세션을 열고 연결된 상태로 유지합니다. 이 가이드에서 발생하는 거의 모든 오류는 인증된 셸이 하나라도 계속 실행 중이면 2분 안에 수정할 수 있습니다. 마지막 셸까지 종료되면 콘솔에 접속해야 합니다.

이미 열려 있는 셸은 해당 셸이 속한 계정을 변경하거나 잠그거나 만료시킨 후에도 계속 작동합니다. SSH는 로그인할 때 자격 증명을 확인하고, 이후에는 다시 확인하지 않기 때문입니다. 예외는 sudo입니다. sudo는 타임스탬프가 만료되면 PAM(플러그형 인증 모듈)을 통해 비밀번호를 다시 확인합니다. 기본적으로 마지막 프롬프트 표시 후 15분이 지나면 타임스탬프가 만료됩니다. 따라서 새 비밀번호가 실제로 처음 테스트되는 시점은 로그인할 때가 아니라 다음에 sudo가 비밀번호를 요청할 때입니다.

첫 번째 세션을 열린 상태로 유지하면서 두 번째 세션에서 새 비밀번호를 테스트합니다.

passwd로 자신의 비밀번호 변경

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully만 /etc/shadow의 해시가 교체되었다는 의미입니다. 그 외의 출력은 기존 비밀번호가 그대로 유지되었다는 뜻입니다.

여기서는 2가지 오류가 발생합니다. passwd: Authentication token manipulation error에 이어 passwd: password unchanged가 표시되면 입력한 현재 비밀번호가 잘못되었거나, /etc/shadow을 포함하는 파일 시스템에 쓰기 권한이 없는 것입니다. 후자는 recovery mode에서 일반적으로 발생하는 상태입니다. You must choose a longer password.는 /etc/pam.d/common-password의 pam_unix에서 발생합니다. 이 설정은 일반 사용자에게 길이 및 유사성 검사를 적용합니다.

대부분의 VPS 이미지에서는 기본 계정(ubuntu 또는 공급자가 제공하는 다른 이름)에 비밀번호가 없고 SSH 키만 있습니다. passwd에는 확인할 현재 비밀번호가 없으므로 첫 번째 프롬프트를 통과할 수 없습니다. 대신 sudo passwd $USER을 사용합니다. 이미지의 sudoers drop-in 파일에서 해당 계정이 비밀번호 없이 sudo을 실행할 수 있도록 허용하므로 이 방법은 작동합니다.

sudo passwd로 다른 사용자의 비밀번호 변경

sudo passwd deploy

root에는 기존 비밀번호를 묻지 않습니다. 또한 pam_unix은 일반 사용자에게 적용되는 비밀번호 강도 검사를 건너뜁니다. 따라서 root는 해당 사용자가 직접 설정할 수 없는 비밀번호도 설정할 수 있습니다.

잠금은 별도의 작업입니다. sudo passwd -l deploy은 저장된 해시 앞에 !을 추가하므로 어떤 비밀번호도 일치하지 않습니다. sudo passwd -u deploy은 이를 제거합니다. sudo passwd -S deploy으로 현재 상태를 확인합니다.

비밀번호를 잠가도 해당 사용자의 로그인이 중지되지는 않습니다. 사용자의 ~/.ssh/authorized_keys에 있는 키는 계속 작동합니다. 공개 키 인증에서는 /etc/shadow을 읽지 않기 때문입니다. 계정을 완전히 중지하려면 계정 자체를 만료 처리합니다.

sudo usermod --expiredate 1 deploy

이 명령은 계정 만료일을 1970년의 날짜로 설정합니다. 그러면 sshd는 어떤 인증 정보가 제공되더라도 로그인을 거부합니다. sudo usermod --expiredate '' deploy으로 되돌립니다.

passwd -d은 사용하지 마십시오. 이 명령은 비밀번호를 잠그는 대신 빈 비밀번호를 설정합니다. 또한 nullok이 PAM 스택에 남아 있는 이전 릴리스에서는 빈 비밀번호를 누구나 사용할 수 있습니다.

VPS에서 root에 암호가 필요합니까?

Ubuntu는 root를 잠근 상태로 출시됩니다. /etc/shadow에는 해시 대신 !가 있으며, sudo passwd -S root는 root L로 시작하는 줄을 출력합니다. 암호를 설정하기 전에는 암호로 root에 로그인할 수 없습니다. 따라서 이미지가 sudo 권한이 있는 사용자를 제공하는 것입니다. root가 아니라 VPS에서 최소 권한 사용자 계정 사용 방식으로 작업해야 합니다.

root 암호를 설정하면 한 가지 기능을 사용할 수 있습니다. provider console을 통해 접속할 수 있습니다. 이 console은 network stack 아래에서 virtual machine에 연결됩니다. 따라서 sshd 설정이 잘못되었거나 firewall rule이 잘못되어도 계속 작동합니다. 하지만 대가도 있습니다. root에 암호가 설정되어 있으면 GRUB recovery menu의 root shell에서 root 암호를 요구합니다. 잊어버린 암호를 재설정할 때 사용할 도구가 동일한 암호 뒤에 놓이게 됩니다.

root 암호를 설정해도 SSH를 통해 root로 로그인할 수 있는 것은 아닙니다. Ubuntu는 PermitRootLogin prohibit-password와 함께 출시되며, 이는 key만 허용한다는 뜻입니다. 서버가 실제로 사용하는 설정을 확인합니다.

sudo sshd -T | grep -i permitrootlogin

sshd -T는 모든 Include 줄을 해석한 후의 유효한 설정을 출력합니다. 따라서 /etc/ssh/sshd_config.d/에 drop-in 파일이 있을 때 확인할 수 있는 유일하게 정확한 답입니다.

스크립트에서 chpasswd로 비밀번호 설정

passwd는 터미널에서 입력을 읽으므로 스크립트로 실행할 수 없습니다. chpasswd는 표준 입력에서 user:password 쌍을 한 줄에 하나씩 읽습니다.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

이 명령은 작동하지만 셸 기록과 CI(continuous integration) 로그에 평문 비밀번호가 남습니다. 먼저 해시하십시오.

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6는 에코 없이 비밀번호를 2번 입력하도록 요청한 다음, $6$으로 시작하는 SHA-512 crypt 해시를 출력합니다. -e은 chpasswd에 두 번째 필드가 이미 해시되었음을 알려 줍니다. 따라서 해당 값은 변경하지 않고 /etc/shadow에 복사됩니다. 이 해시는 저장소나 CI 변수에 안전하게 보관할 수 있습니다. 평문 비밀번호는 입력한 시스템 밖으로 나가지 않습니다.

Ubuntu 24.04에서는 passwd가 새 비밀번호를 설정할 때 yescrypt($y$)로 해시합니다. 반면 openssl passwd -6은 SHA-512를 사용합니다. libxcrypt가 두 형식을 모두 읽기 때문에 로그인 시 두 형식 모두 검증됩니다. 두 형식을 혼용해도 됩니다. openssl passwd -6은 모든 Ubuntu LTS 릴리스에서 동일하게 동작하지만 chpasswd -c YESCRYPT은 그렇지 않습니다. 20.04의 이전 shadow 패키지는 해당 방식 이름을 인식하지 못합니다.

암호가 실제로 변경되었는지 확인하는 방법

먼저 메타데이터를 확인한 다음 로그인으로 검증합니다.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

두 번째 필드는 상태입니다. 사용 가능한 암호는 P, 잠긴 암호는 L, 암호가 전혀 없는 경우는 NP입니다. 날짜는 암호가 마지막으로 변경된 날짜이므로 오늘 날짜로 표시되어야 합니다. 그 뒤의 숫자는 아래에서 설명하는 암호 만료 기간 필드입니다.

가장 안전한 실시간 테스트는 sudo 자체입니다. sudo -k은 캐시된 타임스탬프를 삭제하고, sudo -v는 새 암호 입력 프롬프트를 강제로 표시합니다. 새 암호가 여기서 승인되면 PAM이 암호를 승인한 것입니다. 이 과정에서 현재 세션에는 아무런 변화가 없습니다.

sudo -k && sudo -v

다른 계정을 테스트하려면 권한이 없는 셸에서 su - deploy를 실행합니다. sudo su - deploy은 실행하지 마십시오. root에는 암호를 묻지 않으므로 이 테스트로는 아무것도 확인할 수 없습니다. 잘못된 암호를 입력하면 su: Authentication failure이 출력됩니다.

실제 테스트는 현재 작업 중인 세션을 계속 열어 둔 상태에서 노트북으로 새 SSH 로그인을 수행하는 것입니다.

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

여기서 Permission denied (publickey).은 서버가 암호 인증을 제공하지 않았다는 뜻이므로 암호를 변경해도 로그인할 수 없습니다. Permission denied, please try again.은 서버가 암호 인증을 제공했지만 입력한 암호를 거부했다는 뜻입니다.

chage로 다음 로그인 시 비밀번호 변경 강제

sudo chage -d 0 deploy

-d 0은 마지막 변경 날짜를 epoch로 설정하므로 PAM이 비밀번호를 만료된 것으로 처리합니다. 다음 대화형 로그인에서는 셸을 제공하기 전에 현재 비밀번호를 입력하라는 메시지가 표시되고, 이어서 새 비밀번호를 입력하라는 메시지가 표시됩니다. sudo passwd -e deploy도 정확히 같은 작업을 수행합니다.

비밀번호로 대화형 로그인하는 계정에만 사용합니다. sshd는 인증에 키를 사용한 경우에도 PAM account 단계를 실행하므로, 만료된 비밀번호는 키 기반 로그인에도 영향을 줍니다. 스크립트에서 실행한 ssh deploy@203.0.113.10 'systemctl restart app'은 다음 오류와 함께 실패하고 중지됩니다.

Password change required but no TTY available.

해당 줄 다음의 명령은 실행되지 않으며, 작업에는 0이 아닌 종료 코드만 보고됩니다.

비밀번호 만료 필드의 의미

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

이 숫자는 /etc/shadow에서 해당 사용자의 행에 있는 4번째 필드부터 8번째 필드까지입니다. 최소 일수(chage -m)는 사용자가 비밀번호를 다시 변경하기 전에 기다려야 하는 기간입니다. 강제 변경 후 기존 비밀번호로 바로 되돌리는 것을 방지합니다. 최대 일수(chage -M)는 비밀번호가 유효한 기간입니다. 경고 일수(chage -W)가 되면 로그인할 때 경고가 표시되기 시작합니다. 비활성 일수(chage -I)는 만료 후 비밀번호가 더 이상 허용되지 않을 때까지의 유예 기간입니다. 계정 만료(chage -E)는 고정된 날짜이며 비밀번호 만료와는 별개입니다.

sudo chage -M 90 -W 14 deploy

정책에서 요구하는 경우에만 설정합니다. NIST(미국 국립표준기술연구소)는 예측 가능한 비밀번호 변형을 사용하게 만들기 때문에 2017년부터 정기적인 비밀번호 만료를 권장하지 않았습니다. 대신 비밀번호가 유출되었다는 증거가 있을 때 변경을 강제하도록 권장합니다. 비밀번호 관리자에 보관한 길고 고유한 비밀번호와 key based SSH를 함께 사용하면 90일 주기보다 안전합니다.

root 비밀번호를 잃어버렸을 때 수행할 작업

서버의 계정 중 하나라도 sudo를 실행할 수 있다면 복구할 필요가 없습니다. sudo passwd root로 새 비밀번호를 설정할 수 있습니다. 가장 어려운 경우는 정상적으로 로그인할 수 있는 계정이 전혀 없는 경우입니다.

아래 절차에는 provider console이 필요합니다. 대부분의 패널에서는 이를 VNC (virtual network computing) 또는 serial console로 표시합니다. 이 콘솔은 network stack 아래의 virtual machine에 연결되므로 sshd 설정과 firewall 규칙의 영향을 받지 않습니다.

1. 패널에서 서버를 재부팅하고 console을 모니터링합니다.
2. GRUB 메뉴를 표시합니다. Cloud image는 일반적으로 GRUB_TIMEOUT=0을 설정하므로, BIOS 부팅에서는 재부팅이 시작되자마자 Shift를 누르고, UEFI 부팅에서는 Esc을 반복해서 누릅니다.
3. Advanced options for Ubuntu를 선택한 다음, (recovery mode)로 끝나는 항목을 선택하고, recovery menu에서 root을 선택합니다.
4. 먼저 mount -o remount,rw /을 실행합니다. Recovery는 root filesystem을 read-only로 mount하므로 이 명령이 없으면 passwd이 passwd: Authentication token manipulation error와 함께 실패합니다. /etc/shadow에 쓸 수 없기 때문입니다.
5. 필요한 계정에 passwd ubuntu을 실행한 다음, 패널에서 재부팅합니다.

root에 이미 비밀번호가 설정되어 있고 잃어버린 비밀번호가 바로 그 비밀번호라면 recovery shell에서 해당 비밀번호를 요구하므로 이 방법을 사용할 수 없습니다. 대신 provider의 rescue image로 부팅한 다음 실제 disk를 mount하고 해당 환경 안에서 비밀번호를 변경합니다.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

lsblk에서 partition layout을 확인하고, 이 페이지의 /dev/vda1을 그대로 복사하지 마십시오. root partition은 크기가 큰 partition입니다. UEFI image에서는 root partition 옆에 작은 EFI partition이 있으며, 이 partition에는 /etc directory가 전혀 없습니다.

SSH가 비밀번호를 더 이상 허용하지 않을 때 수행할 작업

아직 유지 중인 세션에서 작업합니다. 세션이 남아 있지 않으면 콘솔을 사용합니다.

Permission denied, please try again.는 서버가 비밀번호 인증을 제시했지만 입력한 비밀번호를 거부했다는 의미입니다. 일반적인 원인은 Caps Lock이 켜져 있거나, 비밀번호를 설정할 때 사용한 키보드 레이아웃과 콘솔의 키보드 레이아웃이 다른 경우입니다.

Permission denied (publickey).는 서버가 비밀번호 인증을 전혀 제시하지 않았다는 의미입니다. PasswordAuthentication no가 어딘가에 설정되어 있으며, Ubuntu 22.04 이상에서는 일반적으로 주 파일을 재정의하는 /etc/ssh/sshd_config.d/ 아래의 drop-in 파일에 설정되어 있습니다. 적용되는 값을 확인합니다.

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes가 PasswordAuthentication no과 함께 설정되어 있으면 비밀번호 인증이 여전히 허용됩니다. keyboard-interactive 방식도 동일한 PAM 스택을 실행하기 때문입니다. 한 방식은 끄고 다른 방식을 켜 두면, 키 전용처럼 보이는 서버가 입력한 비밀번호를 계속 허용하게 됩니다.

연결 종료 메시지의 Too many authentication failures은 클라이언트가 비밀번호 인증에 도달하기 전에 여러 키를 제시했고, 서버가 기본값 6인 MaxAuthTries에 도달했다는 의미입니다. 하나의 인증 방식만 강제합니다.

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

방금 전까지 작동하던 포트에서 Connection refused이 표시되면, SSH를 모니터링하는 fail2ban이 반복된 인증 실패 후 사용자의 주소를 차단했을 가능성이 큽니다. 기본 차단 규칙은 패킷을 무시하는 대신 거부하므로 연결이 시간 초과되지 않고 빠르게 거부됩니다. 콘솔에서 sudo fail2ban-client status sshd는 차단된 주소를 표시하고, sudo fail2ban-client set sshd unbanip 203.0.113.10는 사용자의 주소 차단을 해제합니다.

비밀번호는 디딤돌이고 키가 최종 상태입니다

SSH에서 작동하는 비밀번호는 인터넷의 모든 스캐너가 추측할 수 있는 비밀번호입니다. 키 기반 인증으로 전환하면 추측 공격은 더 이상 중요하지 않습니다. 키 쌍을 생성하고 공개 키를 설치한 다음, 다른 터미널에서 키로 로그인되는지 확인한 후 다른 설정을 변경합니다. SSH 키 관리 기본 사항에서는 키 생성, authorized_keys 및 암호문을 다룹니다.

그런 다음 비밀번호 인증을 끄고, 편집한 파일을 그대로 믿지 말고 sudo sshd -T로 변경 사항을 확인합니다. VPS에서 SSH 보안 강화에서는 변경할 가치가 있는 나머지 sshd 설정을 설명하고, 새 VPS에서 처음 10분에서는 새 서버에서 적용할 순서로 정리합니다.

그 후에도 비밀번호 하나는 유지합니다. sshd 설정이 손상된 키 전용 서버는 공급자의 콘솔을 통해서만 접근할 수 있으며, 해당 콘솔에서는 사용자 이름과 비밀번호를 요구합니다. 저장해 둔 강력한 비밀번호를 사용하는 계정이 있으면 5분 만에 수정할 수 있는 문제와 재설치해야 하는 문제를 구분할 수 있습니다.

FAQ

VPS에서 이전 root 비밀번호를 모르는 경우 어떻게 root 비밀번호를 변경합니까?

sudo를 실행할 수 있는 사용자로 로그인한 후 sudo passwd root를 실행합니다. sudo가 이미 인증했기 때문에 이전 비밀번호를 묻지 않고 새 비밀번호를 설정합니다. 시스템의 어떤 계정도 sudo를 실행할 수 없다면 provider console을 열고, GRUB recovery menu로 재부팅한 다음 root shell 항목을 선택하고 mount -o remount,rw /을 실행한 후 passwd를 실행합니다. root에 이미 비밀번호가 설정되어 있고 분실한 비밀번호가 바로 그 비밀번호라면 recovery shell에서 해당 비밀번호를 요구합니다. 이 경우 남은 방법은 provider의 rescue image를 사용해 디스크를 마운트하고 chroot하는 것입니다.

passwd에서 "Authentication token manipulation error"가 표시되는 이유는 무엇입니까?

이 메시지는 2가지 원인으로 발생합니다. 일반적인 원인은 Current password: 프롬프트에 잘못 입력한 경우이며, 그 아래의 passwd: password unchanged 줄에서 아무것도 기록되지 않았음을 확인할 수 있습니다. 다른 원인은 파일 시스템에 쓰기 작업을 수행할 수 없는 경우입니다. recovery mode에서는 /이 read-only로 마운트되므로 이 문제가 발생합니다. mount -o remount,rw /를 실행한 후 다시 시도합니다.

Linux 비밀번호를 변경하면 sudo 비밀번호도 변경됩니까?

그렇습니다. sudo에는 자체 비밀번호가 없습니다. PAM을 통해 SSH와 su이 사용하는 동일한 /etc/shadow 항목을 기준으로 인증하므로, 계정마다 비밀번호는 1개입니다. 따라서 변경 후 처음 표시되는 sudo 프롬프트가 실제로 변경을 확인하는 테스트이기도 합니다. 활성 세션을 유지하는 동안 sudo -k && sudo -v을 실행하면 해당 프롬프트를 강제로 표시할 수 있습니다.

비밀번호를 변경하면 SSH key 또는 현재 열려 있는 세션이 중단됩니까?

아닙니다. Public key authentication은 /etc/shadow를 읽지 않으므로 비밀번호 변경 후에도, passwd -l 후에도, chage -d 0 후에도 key는 계속 작동합니다. 이미 열려 있는 세션은 계속 유지됩니다. SSH는 로그인할 때만 인증 정보를 확인하기 때문입니다. 활성 세션에서 변경되는 한 가지는 sudo입니다. sudo은 15분 timestamp가 만료되면 새 비밀번호를 한 번 요구합니다.

다음 로그인 시 사용자가 비밀번호를 변경하도록 강제하려면 어떻게 합니까?

sudo chage -d 0 deploy 또는 동일한 작업을 수행하는 sudo passwd -e deploy를 실행합니다. 저장된 마지막 변경 날짜가 epoch로 변경되고, PAM은 비밀번호를 만료된 것으로 처리합니다. 그러면 다음 interactive login에서 shell이 시작되기 전에 새 비밀번호를 설정해야 합니다. SSH를 통해 script에서 사용하는 계정에는 이 작업을 수행하지 마십시오. 그러면 non-interactive command가 Password change required but no TTY available.와 함께 실패하고 실행되지 않습니다.