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 권한을 가진 사용자를 기본으로 제공하는 이유입니다. 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 스택을 실행하기 때문입니다. 하나만 끄고 다른 하나를 켜두면, 키 전용 로그인처럼 보이는 서버가 계속해서 입력받은 비밀번호를 허용하게 됩니다.

동일한 메시지는 키 로그인이 거부될 때도 출력됩니다. 따라서 비밀번호가 아닌 키를 사용 중이었다면, 서버의 비밀번호 설정은 Permission denied (publickey) 오류의 5가지 원인 중 하나일 뿐이며, ssh -v 출력을 통해 정확한 원인을 파악할 수 있습니다.

연결 종료 메시지에 포함된 Too many authentication failures는 클라이언트가 비밀번호를 시도하기 전에 여러 개의 키를 먼저 제시했고, 서버가 MaxAuthTries(기본값 6) 제한에 도달했음을 의미합니다. 인증 방식을 하나로 강제하십시오:

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

방금 전까지 잘 작동하던 포트에서 Connection refused가 발생한다면, 보통 SSH를 감시하는 fail2ban이 반복된 실패로 인해 귀하의 IP 주소를 차단한 것입니다. fail2ban의 기본 차단 규칙은 패킷을 드롭하지 않고 거부(reject) 응답을 보내기 때문에, 타임아웃 없이 즉시 연결 거부 메시지가 돌아옵니다. 콘솔에서 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. 오류와 함께 실패하며 실행되지 않게 됩니다.