Ubuntu VPS root 비밀번호 변경 및 분실 시 복구 방법

Ubuntu에서 VPS root 비밀번호를 변경하는 방법

Ubuntu에서 VPS(가상 사설 서버)의 root 비밀번호를 변경하려면, sudo을 실행할 수 있는 사용자로 SSH(Secure Shell) 세션에 접속한 뒤 sudo passwd root을 실행합니다. 이 명령은 새 비밀번호를 두 번 입력받으며, 이미 sudo를 통해 사용자 인증을 마쳤으므로 기존 비밀번호는 묻지 않습니다. 본인의 로그인 비밀번호를 변경하려면 인자 없이 passwd을 실행하십시오. 이 경우 현재 비밀번호를 먼저 입력해야 합니다.

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

작업은 이것으로 끝입니다. 아래 내용은 문제가 발생할 수 있는 부분들입니다. 현재 접속 중인 세션을 잃기 전에 새 비밀번호가 정상 작동하는지 확인하는 방법, 스크립트에서 비밀번호를 설정하는 방법, 의도적으로 비밀번호를 만료시키는 방법, 그리고 비밀번호를 분실했을 때 다시 접속하는 방법을 다룹니다.

비밀번호를 변경하기 전에 두 번째 세션을 여십시오

지금 두 번째 SSH 세션을 열고 연결된 상태로 두십시오. 이 가이드에서 발생하는 거의 모든 오류는 인증된 셸이 하나라도 살아있을 때 2분이면 해결할 수 있지만, 마지막 세션이 닫히면 콘솔에 직접 접근해야 하는 상황이 발생합니다.

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

첫 번째 세션을 그대로 둔 상태에서 두 번째 세션으로 새 비밀번호를 테스트하십시오.

passwd 명령어로 비밀번호 변경하기

passwd

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

passwd: password updated successfully은 /etc/shadow의 해시가 정상적으로 교체되었음을 의미하는 유일한 출력 결과입니다. 그 외의 다른 메시지가 출력되었다면 기존 비밀번호가 그대로 유지된 것입니다.

이 과정에서 두 가지 실패 사례가 발생할 수 있습니다. passwd: Authentication token manipulation error에 이어 passwd: password unchanged가 출력된다면, 입력한 현재 비밀번호가 틀렸거나 /etc/shadow이 위치한 파일 시스템에 쓰기 권한이 없는 경우입니다. 후자는 복구 모드에서 흔히 나타나는 상태입니다. You must choose a longer password.은 /etc/pam.d/common-password의 pam_unix 설정에서 발생하며, 이는 일반 사용자에게 비밀번호 길이 및 유사성 검사를 적용합니다.

대부분의 VPS 이미지에서 기본 계정(ubuntu 또는 서비스 제공업체가 제공하는 계정명)은 비밀번호가 설정되어 있지 않으며 SSH 키만 사용합니다. passwd는 대조할 현재 비밀번호가 없으므로 첫 번째 프롬프트를 통과할 수 없습니다. 대신 sudo passwd $USER을 사용하십시오. 해당 이미지의 sudoers 설정 파일이 해당 계정에 비밀번호 없이 sudo을 실행할 수 있는 권한을 부여하므로 이 방법이 정상적으로 작동합니다.

sudo passwd를 사용하여 다른 사용자의 비밀번호 변경하기

sudo passwd deploy

root 사용자는 이전 비밀번호를 요구받지 않으며, pam_unix은 일반 사용자에게 적용되는 강도 검사를 건너뜁니다. 따라서 root는 사용자가 스스로 설정할 수 없는 비밀번호도 지정할 수 있습니다.

계정 잠금은 별도의 작업입니다. sudo passwd -l deploy는 저장된 해시 앞에 !을 추가하여 어떤 비밀번호로도 일치하지 않게 만듭니다. sudo passwd -u deploy은 이를 제거합니다. sudo passwd -S deploy를 사용하여 현재 상태를 확인할 수 있습니다.

비밀번호를 잠그더라도 해당 사용자의 로그인이 차단되지는 않습니다. 공개 키 인증은 /etc/shadow를 읽지 않으므로 사용자의 ~/.ssh/authorized_keys에 있는 키는 여전히 작동합니다. 계정을 완전히 차단하려면 계정 자체를 만료시켜야 합니다.

sudo usermod --expiredate 1 deploy

이 명령은 계정 만료일을 1970년으로 설정하므로, 어떤 자격 증명을 제시하더라도 sshd는 로그인을 거부합니다. sudo usermod --expiredate '' deploy를 사용하여 이를 되돌릴 수 있습니다.

passwd -d은 사용하지 마십시오. 이 명령은 비밀번호를 잠그는 대신 빈 비밀번호로 설정합니다. PAM 스택에 nullok이 포함된 구형 릴리스에서는 누구나 빈 비밀번호를 사용하여 로그인할 수 있게 됩니다.

VPS에서 root 계정의 비밀번호가 필요한가?

Ubuntu는 기본적으로 root 계정이 잠긴 상태로 배포됩니다. /etc/shadow에는 해시 대신 !가 설정되어 있으며, sudo passwd -S root은 root L로 시작하는 줄을 출력합니다. 비밀번호를 직접 설정하기 전까지는 그 누구도 root 계정으로 비밀번호 로그인을 할 수 없으며, 이것이 바로 서버 이미지에서 sudo 권한을 가진 사용자를 기본으로 제공하는 이유입니다. root 계정으로 직접 작업하기보다 VPS에서 최소 권한 사용자 계정 사용하기를 통해 작업하는 것이 권장되는 방식입니다.

root 비밀번호를 설정하면 한 가지 이점이 있습니다. 바로 제공업체의 콘솔을 통해 접속할 수 있다는 점입니다. 해당 콘솔은 네트워크 스택 하위의 가상 머신에 직접 연결되므로, sshd 설정이 잘못되었거나 방화벽 규칙에 문제가 생겼을 때도 접속이 가능합니다. 하지만 그만큼 대가도 따릅니다. GRUB 복구 메뉴의 root 셸은 root 비밀번호가 설정되어 있으면 이를 요구하므로, 잊어버린 비밀번호를 재설정하기 위해 사용하는 도구조차 해당 비밀번호 뒤에 숨게 됩니다.

root 비밀번호를 설정한다고 해서 SSH를 통한 root 로그인이 허용되는 것은 아닙니다. Ubuntu는 기본적으로 PermitRootLogin prohibit-password 설정이 적용되어 있어 키 기반 인증만 가능합니다. 서버가 실제로 어떤 설정을 사용하는지 확인하려면 다음을 실행하십시오.

sudo sshd -T | grep -i permitrootlogin

sshd -T은 모든 Include 줄이 해석된 후의 최종 설정을 출력하므로, /etc/ssh/sshd_config.d/에 드롭인 파일이 포함된 경우 가장 정확한 정보를 확인할 수 있는 유일한 방법입니다.

chpasswd를 사용하여 스크립트에서 비밀번호 설정하기

passwd은 터미널에서 입력을 읽어오므로 스크립트로 제어할 수 없습니다. chpasswd은 표준 입력에서 user:password 쌍을 한 줄에 하나씩 읽어 처리합니다.

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

위 방식은 작동하지만, 평문 비밀번호가 셸 히스토리와 CI(지속적 통합) 로그에 남습니다. 대신 먼저 해시를 생성하십시오.

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

openssl passwd -6는 비밀번호를 두 번 입력받아 에코 없이 처리한 뒤, $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 패키지는 해당 메서드 이름을 인식하지 못합니다. 이러한 해시는 릴리스 업그레이드 후에도 유지되므로, 24.04 서버를 26.04로 이전할 때 사용자의 비밀번호를 강제로 재설정할 필요가 없습니다.

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

먼저 메타데이터를 확인한 다음, 로그인을 통해 증명하십시오.

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 계정 단계를 실행하기 때문입니다. 따라서 스크립트로 작성된 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년부터 정기적인 비밀번호 만료 정책을 권장하지 않고 있습니다. 이는 사용자가 예측 가능한 방식으로 비밀번호를 조금씩 변경하게 만들기 때문이며, 대신 침해 증거가 있을 때만 변경을 강제할 것을 권고합니다. 비밀번호 관리자에 저장된 길고 고유한 비밀번호와 키 기반 SSH를 사용하는 것이 90일 주기 변경보다 훨씬 안전합니다.

root 비밀번호를 분실했을 때의 대처법

시스템의 어떤 계정이라도 sudo를 실행할 수 있다면 복구할 것은 없습니다. sudo passwd root 명령으로 새 비밀번호를 설정하면 됩니다. 가장 어려운 경우는 로그인 가능한 계정이 전혀 없는 상황입니다.

아래의 모든 과정은 제공자의 콘솔이 필요합니다. 대부분의 관리 패널에서는 VNC(virtual network computing) 또는 시리얼 콘솔로 표시됩니다. 이 콘솔은 네트워크 스택 하위의 가상 머신에 직접 연결되므로, sshd 설정이나 방화벽 규칙의 영향을 받지 않습니다.

1. 관리 패널에서 서버를 재부팅하고 콘솔을 확인합니다.
2. GRUB 메뉴로 진입합니다. 클라우드 이미지는 보통 GRUB_TIMEOUT=0로 설정되어 있으므로, 재부팅이 시작되자마자 BIOS 부팅 환경에서는 Shift를 누르고 있거나, UEFI 부팅 환경에서는 Esc을 반복해서 누릅니다.
3. Advanced options for Ubuntu를 선택한 다음 (recovery mode)로 끝나는 항목을 선택하고, 복구 메뉴에서 root을 선택합니다.
4. 먼저 mount -o remount,rw /을 실행합니다. 복구 모드는 루트 파일 시스템을 읽기 전용으로 마운트하므로, 이 과정을 거치지 않으면 /etc/shadow에 기록할 수 없어 passwd 명령이 passwd: Authentication token manipulation error 오류와 함께 실패합니다.
5. 필요한 계정에 대해 passwd ubuntu을 실행한 뒤, 관리 패널에서 서버를 재부팅합니다.

만약 root 계정에 이미 비밀번호가 설정되어 있고 그 비밀번호를 분실한 경우, 복구 셸에서 비밀번호를 요구하므로 이 방법은 사용할 수 없습니다. 대신 제공자가 제공하는 구조(rescue) 이미지를 부팅한 뒤, 실제 디스크를 마운트하여 내부에서 비밀번호를 변경해야 합니다.

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

이 페이지의 /dev/vda1을 그대로 복사하지 말고 lsblk에서 파티션 레이아웃을 직접 확인하십시오. 루트 파티션은 용량이 큰 파티션입니다. UEFI 이미지의 경우, /etc 디렉터리가 전혀 없는 작은 EFI 파티션 옆에 루트 파티션이 위치합니다.

SSH가 비밀번호 입력을 거부할 때의 대처법

현재 접속이 유지된 세션을 사용하십시오. 남은 세션이 없다면 콘솔을 이용하십시오.

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

Permission denied (publickey).은 서버가 비밀번호 인증을 아예 제안하지 않았음을 의미합니다. PasswordAuthentication no이 어딘가에 설정되어 있으며, Ubuntu 22.04 이상에서는 보통 /etc/ssh/sshd_config.d/ 아래의 드롭인 파일이 메인 파일을 덮어쓰는 방식으로 존재합니다. 적용된 값을 확인하십시오:

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이 반복된 인증 실패로 인해 귀하의 IP 주소를 차단했음을 의미합니다. 기본 차단 규칙은 패킷을 드롭하는 대신 거부 응답을 보내므로, 타임아웃이 발생하지 않고 즉시 연결 거부 메시지가 돌아옵니다. 콘솔에서 sudo fail2ban-client status sshd를 실행하면 차단된 주소 목록을 볼 수 있으며, sudo fail2ban-client set sshd unbanip 203.0.113.10를 통해 본인의 주소를 차단 해제할 수 있습니다.

비밀번호는 징검다리일 뿐, 공개 키 인증이 최종 단계입니다

SSH에서 비밀번호를 사용하면 인터넷상의 모든 스캐너가 해당 비밀번호를 추측할 수 있게 됩니다. 공개 키 기반 인증으로 전환하면 이러한 추측은 더 이상 의미가 없어집니다. 키 쌍을 생성하고 공개 키를 설치한 뒤, 다른 터미널에서 해당 키로 로그인이 정상적으로 수행되는지 확인하십시오. 그 후 다른 설정을 변경해야 합니다. SSH 키 관리 기초에서 키 생성, authorized_keys 및 암호 구문(passphrase)에 대해 다룹니다.

그다음 비밀번호 인증을 비활성화하고, 편집한 파일을 맹신하는 대신 sudo sshd -T 명령어로 설정이 적용되었는지 확인하십시오. VPS의 SSH 보안 강화에서는 변경할 가치가 있는 나머지 sshd 설정들을 다루며, 새로운 VPS에서 처음 10분에서는 새 서버에서 수행해야 할 작업 순서를 안내합니다.

그 이후에도 비밀번호는 하나 유지하십시오. sshd 설정이 잘못되어 키로만 접속할 수 있는 서버는 제공업체의 콘솔을 통해서만 접근할 수 있으며, 해당 콘솔은 사용자 이름과 비밀번호를 요구합니다. 안전하게 보관된 강력한 비밀번호를 가진 계정은 5분 만에 끝날 수 있는 수정 작업과 서버 재설치 사이를 가르는 기준이 됩니다.

FAQ

기존 root 비밀번호를 모를 때 VPS에서 비밀번호를 어떻게 변경합니까?

sudo 권한이 있는 사용자로 로그인한 뒤 sudo passwd root를 실행합니다. sudo을 통해 이미 인증된 상태이므로 기존 비밀번호를 묻지 않고 새 비밀번호를 설정합니다. 시스템에 sudo 권한을 가진 계정이 없다면, 제공업체의 콘솔을 열어 GRUB 복구 메뉴로 재부팅한 뒤 root 셸 항목을 선택하고 mount -o remount,rw /을 실행한 다음 passwd를 실행하십시오. root 계정에 이미 비밀번호가 설정되어 있고 이를 분실한 경우, 복구 셸에서 비밀번호를 요구하게 됩니다. 이 경우 남은 방법은 제공업체의 구조용 이미지(rescue image)로 부팅하여 디스크를 마운트하고 chroot하는 것입니다.

passwd 명령에서 "Authentication token manipulation error"가 발생하는 이유는 무엇입니까?

이 메시지는 두 가지 원인으로 발생합니다. 가장 흔한 원인은 Current password: 프롬프트에서 잘못된 답변을 입력하는 것이며, 그 아래의 passwd: password unchanged 줄은 아무것도 기록되지 않았음을 나타냅니다. 다른 원인은 파일 시스템에 쓰기가 불가능한 경우입니다. 복구 모드에서는 /이 읽기 전용으로 마운트되므로 이 문제가 발생합니다. mount -o remount,rw /을 실행하여 쓰기 권한을 부여한 뒤 다시 시도하십시오.

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

그렇습니다. sudo는 별도의 비밀번호를 가지지 않습니다. PAM을 통해 SSH 및 su이 사용하는 것과 동일한 /etc/shadow 항목으로 인증하므로, 계정당 하나의 비밀번호만 존재합니다. 비밀번호 변경 후 첫 번째 sudo 프롬프트가 실제 테스트가 되는 이유도 이 때문입니다. 현재 세션이 유지되는 동안 sudo -k && sudo -v을 실행하여 해당 프롬프트를 즉시 확인해 보십시오.

비밀번호를 변경하면 SSH 키나 열려 있는 세션이 끊깁니까?

아니요. 공개 키 인증은 /etc/shadow를 읽지 않으므로 비밀번호 변경, passwd -l, chage -d 0 이후에도 키는 계속 작동합니다. SSH는 로그인 시에만 자격 증명을 확인하므로 이미 열려 있는 세션은 그대로 유지됩니다. 활성 세션 내에서 변경되는 유일한 것은 sudo이며, 이는 15분 타임스탬프가 만료된 후 새 비밀번호를 요구합니다.

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

sudo chage -d 0 deploy 또는 동일한 기능을 수행하는 sudo passwd -e deploy를 실행하십시오. 저장된 마지막 변경 날짜가 epoch 시간으로 이동하며, PAM은 비밀번호가 만료된 것으로 간주합니다. 따라서 다음 대화형 로그인 시 셸이 시작되기 전에 새 비밀번호를 설정해야 합니다. SSH를 통해 스크립트가 사용하는 계정에는 이 작업을 수행하지 마십시오. 비대화형 명령이 Password change required but no TTY available. 오류와 함께 실패하여 실행되지 않게 됩니다.