OCI에서 돌리고 있던 Ubuntu 서버에 SSH 접속이 되지 않았다.
환경은 대략 이렇다.
Oracle Cloud Infrastructure
Shape : VM.Standard.A1.Flex
OS : Ubuntu
Region: ap-osaka-1
SSH : PuTTY
Key : .ppk평소 사용하던 .ppk 파일은 가지고 있었다.
처음에는 서버 쪽 SSH 공개키가 꼬였거나 authorized_keys가 잘못된 정도라고 생각했다.
결론적으로 SSH 접속은 복구했지만, 최초에 접속이 안 되기 시작한 정확한 원인까지는 특정하지 못했다.
복구 과정에서 키와 부팅 환경을 여러 차례 건드렸고, 최초 장애 시점의 auth.log나 디렉터리 권한 상태를 확보하지 못했기 때문이다.
다만 마지막까지 남아 있던
Server refused our key문제는 /home/ubuntu 권한을 777 → 755로 변경하자 바로 해결됐다.
그 과정에서 Bastion부터 Serial Console, GRUB, 커널 직접 부팅까지 거의 다 건드렸다.
아래는 실제로 진행한 순서다.
1. 일단 Bastion으로 들어가 보기
SSH로 직접 못 들어가니 제일 먼저 OCI Bastion을 이용해 보기로 했다.
Bastion을 생성하고 Managed SSH Session을 만들려고 했는데 바로 오류가 났다.
관리형 SSH 세션을 생성하려면 대상 인스턴스에서
Bastion 플러그인이 활성화되어 있어야 합니다.막힌 이유
대상 인스턴스의 Oracle Cloud Agent에서 Bastion 플러그인이 비활성화되어 있었다.
우회
OCI 콘솔에서 대상 인스턴스로 들어가 Bastion 플러그인을 활성화했다.
Compute
→ Instances
→ 대상 Instance
→ Oracle Cloud Agent
→ Bastion
→ Enabled이후 Managed SSH Session 생성까지는 성공했다.
기존에 사용하던 OCJP.ppk를 PuTTYgen으로 열고,
Public key for pasting into OpenSSH authorized_keys file에 표시되는 공개키를 Bastion Session 생성 시 사용했다.
여기까지는 생각보다 순조로웠다.
2. PPK를 Windows ssh에 쓰려니 또 막힘
Bastion Session을 만든 뒤 OCI에서 Copy SSH command를 가져왔다.
명령은 이런 형태다.
ssh -i <privateKey> \
-o ProxyCommand="ssh -i <privateKey> ..." \
ubuntu@10.x.x.x문제는 내가 가지고 있는 개인키가 PuTTY의 .ppk 형식이었다는 점이다.
당시 판단
OCI에서 복사해 주는 명령은 Windows OpenSSH의 ssh.exe를 사용하는 형태라 .ppk를 그대로 넣기보다는 OpenSSH 형식으로 변환하는 편이 나아 보였다.
우회
PuTTYgen에서 기존 키를 Load한 뒤:
Conversions
→ Export OpenSSH key로 OpenSSH용 private key를 만들었다.
그런데 이번에는 다음 오류가 나왔다.
WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions for 'OCJP-openssh.key' are too open.한 단계 넘어가면 꼭 한 단계씩 막혔다.
3. Windows private key 권한 문제
이번 오류는 서버 문제가 아니라 로컬 Windows의 파일 권한 문제였다.
OpenSSH가 private key를 읽기는 했지만 파일 ACL이 너무 넓다고 판단해서 사용하지 않은 것이다.
우회
PowerShell에서 해당 파일의 권한 상속을 끊고 현재 사용자에게만 읽기 권한을 줬다.
$key = "C:\Users\Sihyeon\Desktop\OCJP-openssh.key"
icacls $key /inheritance:r
icacls $key /grant:r "$($env:USERNAME):(R)"이후 UNPROTECTED PRIVATE KEY FILE 오류는 사라졌다.
드디어 Bastion을 통해 실제 인스턴스까지 들어가나 싶었는데,
다음 단계에서 또 막혔다.
4. Bastion은 통과했는데 Ubuntu에서 공개키 인증 실패
다시 SSH를 실행하자 Bastion 자체는 정상적으로 연결됐다.
Warning: Permanently added '10.0.0.205' ...그런데 최종 대상 서버에서:
ubuntu@10.0.0.205: Permission denied (publickey).가 나왔다.
즉 대략 이런 상태였다.
내 PC
↓
OCI Bastion 통과
↓
Ubuntu Instance 공개키 인증 실패당시 판단
Bastion 자체의 연결 문제는 아니었다.
문제는 최종 Ubuntu 인스턴스의 인증 단계였다.
Managed SSH Session을 새 키로 다시 만들어 보기도 했지만 결과는 같았다.
우회
Bastion에서 계속 시간을 쓰느니 서버의 Boot Volume을 다른 Linux VM에 붙여서 authorized_keys를 직접 고치기로 했다.
이론상 가장 확실한 방법이었다.
5. 복구용 A1 인스턴스를 하나 만들려고 했는데 한도 초과
계획은 간단했다.
문제의 VM 정지
↓
Boot Volume 분리
↓
임시 Linux VM에 데이터 디스크로 연결
↓
/home/ubuntu/.ssh/authorized_keys 수정
↓
원래 VM에 다시 연결같은 A1 Ubuntu를 하나 더 만들려고 했는데 서비스 한도에 걸렸다.
막힌 이유
기존 A1 인스턴스가 무료 제공 CPU와 메모리 한도를 거의 다 사용 중이었다.
우회
복구용 VM에서 원래 디스크를 부팅할 필요는 없었다.
단순히 ext4 파일시스템을 마운트해서 텍스트 파일 하나만 수정할 목적이었기 때문에 E2 계열 Ubuntu VM을 만들어 보기로 했다.
ARM과 x86의 차이는 해당 볼륨으로 부팅하는 게 아니라 데이터 디스크로 읽는 상황에서는 큰 문제가 되지 않을 것이라고 판단했다.
그런데 E2도 생성되지 않았다.
6. 이번엔 Boot Volume 200GB 한도
E2 인스턴스를 만들려고 하니:
bootVolumeQuota Service limit reached오류가 발생했다.
확인해 보니 기존 A1 인스턴스의 Boot Volume이 이미:
200GB였다.
무료로 사용할 수 있는 Block/Boot Volume 용량을 기존 인스턴스 하나가 전부 쓰고 있는 상태였다.
기존 Boot Volume 200GB
남은 무료 공간 0GB새 VM을 하나 만들려면 새 Boot Volume도 하나 필요하니 생성할 수가 없었다.
우회
복구용 VM 방식도 포기했다.
이제 기존 VM 자체 안으로 어떻게든 들어가는 방법을 찾아야 했다.
7. Run Command가 있길래 이걸로 하면 끝인 줄 알았다
OCI 콘솔에 인스턴스 내부에서 스크립트를 실행할 수 있는 Run command 메뉴가 있었다.
SSH가 안 되더라도 여기서:
chmod
authorized_keys 수정정도만 하면 바로 끝날 것 같았다.
일단 테스트로 아주 간단한 명령만 넣었다.
id
echo "=== sudo test ==="
sudo -n true && echo SUDO_OK || echo NO_SUDO
echo "=== ubuntu ssh ==="
ls -ld /home/ubuntu /home/ubuntu/.ssh 2>&1그런데 실행 결과가 안 왔다.
5분,
10분,
17분이 지나도 그대로였다.
상태는:
ACCEPTED막힌 이유
스크립트 자체가 오래 걸리는 게 아니었다.
인스턴스 쪽에서 명령을 가져가 실행하지 못하고 있었다.
Oracle Cloud Agent 목록을 다시 확인해 보니 정작:
Compute Instance Run Command플러그인이 없었다.
우회
Timeout을 3600초에서 줄여서 다시 실행한다고 해결될 문제가 아니었다.
이 방법도 포기했다.
이쯤부터 슬슬 정상적인 복구 방법이 떨어져 갔다.
8. 결국 Serial Console로 들어감
남은 선택지는 Serial Console이었다.
OCI에서:
Compute
→ Instances
→ 대상 Instance
→ Console connection
→ Launch Cloud Shell connection으로 들어갔다.
처음에는 Linux 쉘이 아니라 UEFI 화면이 보였다.
KVM Virtual Machine
virt-4.2
Device Manager
Boot Manager
Boot Maintenance Manager
Continue
Reset여기서 부팅 과정을 타고 들어가 GRUB 프롬프트까지 진입했다.
GNU GRUB version 2.06
grub>이제부터는 서버 디스크를 직접 찾아야 했다.
9. GRUB에서 Ubuntu 루트 파티션 찾기
먼저 디스크 구조를 확인했다.
grub> ls결과:
(proc) (memdisk) (hd0) (hd0,gpt15) (hd0,gpt1) (hd1)하나씩 확인했다.
grub> ls (hd0,gpt1)/결과:
lost+found/
bin/
boot/
dev/
etc/
home/
lib/
media/
mnt/
opt/
proc/
root/
run/
sbin/
snap/
srv/
sys/
tmp/
usr/
var/따라서:
(hd0,gpt1)이 실제 Ubuntu root filesystem이었다.
gpt15는 EFI 쪽 파티션이었다.
10. grub.cfg를 불러오면 메뉴가 뜰 줄 알았는데 그냥 부팅됨
루트 파티션을 찾았으니:
configfile (hd0,gpt1)/boot/grub/grub.cfg를 입력했다.
나는 정상 GRUB 메뉴가 나타날 것으로 생각했는데,
그냥 Ubuntu가 바로 부팅됐다.
막힌 이유
GRUB 설정상 메뉴를 거의 표시하지 않고 기본 엔트리로 바로 넘어가는 상태였던 것으로 보인다.
우회
다시 GRUB에 들어가 이번에는 grub.cfg를 사용하지 않고 커널을 직접 로딩하기로 했다.
먼저 root filesystem의 UUID를 확인했다.
set root=(hd0,gpt1)
probe --set=rootuuid --fs-uuid (hd0,gpt1)
echo $rootuuid실제 값은:
3e94fe91-5d5a-4fac-a227-4cebcfc4b420이었다.
그리고 설치된 커널을 확인했다.
ls /boot/최신 커널은:
vmlinuz-6.8.0-1060-oracle
initrd.img-6.8.0-1060-oracle이었다.
11. GRUB에서 커널 직접 부팅
이제 정상 systemd 대신 /bin/bash를 바로 실행하도록 커널 파라미터를 넣었다.
set root=(hd0,gpt1)
linux /boot/vmlinuz-6.8.0-1060-oracle \
root=UUID=3e94fe91-5d5a-4fac-a227-4cebcfc4b420 \
rw init=/bin/bash console=ttyAMA0,115200
initrd /boot/initrd.img-6.8.0-1060-oracle
boot드디어 로그인 절차 없이 root shell을 얻었다.
root@(none):/#루트 파일시스템을 다시 RW로 마운트했다.
mount -o remount,rw /정상적으로:
EXT4-fs (sda1): re-mounted ...가 출력됐다.
이제 서버 파일을 직접 수정할 수 있었다.
12. 여기서 Ctrl+D 한 번 잘못 눌렀다가 일이 더 커짐
authorized_keys를 수정하면서 처음에는:
cat >> /home/ubuntu/.ssh/authorized_keys를 사용했다.
키를 붙여넣고 입력을 끝내려고 Ctrl+D를 눌렀다.
그 뒤부터 Serial Console이 이상해지고 서버도 제대로 응답하지 않았다.
PuTTY로 접속해 보니:
Network error: Connection refused가 발생했다.
당시 상황
init=/bin/bash로 부팅했기 때문에 systemd가 올라와 있지 않았다.
따라서 sshd도 실행되지 않는 게 당연했고, 22번 포트에서 아무것도 듣지 않으니 Connection refused가 발생했다.
게다가 /bin/bash 자체가 정상 부팅 시의 init 역할을 하고 있는 상태라 평소 쉘 다루듯 접근하면 안 되는 환경이었다.
우회
이후에는 Ctrl+D로 입력을 종료하는 방식을 사용하지 않았다.
키 입력은 heredoc으로 바꿨다.
cat > /home/ubuntu/.ssh/authorized_keys <<'EOF'
ssh-rsa AAAAB3NzaC1yc2E...
EOF마지막 EOF를 직접 입력하는 방식이다.
13. 서버가 Reboot에서도 한참 움직이지 않음
중간에 VM이 이상한 상태에 들어가면서 Reboot를 눌러도 한동안 반응이 없었다.
10분,
13분 정도까지 별 변화가 없어서 이쯤에서는 진짜 서버가 죽은 줄 알았다.
결국 다시 부팅되면서 파일시스템 체크가 진행됐다.
Will now check root file system
fsck.ext4 ...
cloudimg-rootfs: clean다행히:
cloudimg-rootfs: clean으로 파일시스템에는 이상이 없었다.
우회
다시 Serial Console → GRUB → 직접 커널 부팅으로 root shell까지 들어갔다.
이번에는 다른 건 건드리지 않고 SSH 공개키만 제대로 다시 넣기로 했다.
14. authorized_keys를 아예 새로 만듦
먼저:
mount -o remount,rw /
mkdir -p /home/ubuntu/.sshPuTTYgen에서 원래 사용하던 OCJP.ppk를 Load하고:
Public key for pasting into OpenSSH authorized_keys file에 표시된 키를 가져왔다.
중간에 같은 키를 두 번 넣어버린 것도 찝찝해서 아예 파일을 덮어썼다.
cat > /home/ubuntu/.ssh/authorized_keys <<'EOF'
ssh-rsa AAAAB3NzaC1yc2E...
EOF권한도 다시 설정했다.
chown -R ubuntu:ubuntu /home/ubuntu/.ssh
chmod 700 /home/ubuntu/.ssh
chmod 600 /home/ubuntu/.ssh/authorized_keys
sync그리고 실제로 키가 한 줄인지 확인했다.
nl -ba /home/ubuntu/.ssh/authorized_keys결과:
1 ssh-rsa AAAAB3NzaC1yc2E...여기까지 보면 정상처럼 보였다.
복구용 bash에서 정상 init으로 넘겼다.
exec /sbin/init부팅 후 PuTTY로 다시 접속했다.
그런데:
Server refused our key
No supported authentication methods available
(server sent: publickey)여전히 안 됐다.
공개키를 다시 넣었고,
.ssh도 700,
authorized_keys도 600인데 접속이 안 됐다.
15. 마지막으로 홈 디렉터리까지 권한 확인
다시 GRUB root shell에 들어갔다.
이번에는 공개키를 또 손대지 않고 디렉터리 권한 전체를 확인했다.
stat -c '%U:%G %a %n' \
/home/ubuntu \
/home/ubuntu/.ssh \
/home/ubuntu/.ssh/authorized_keys결과:
ubuntu:ubuntu 777 /home/ubuntu
ubuntu:ubuntu 700 /home/ubuntu/.ssh
ubuntu:ubuntu 600 /home/ubuntu/.ssh/authorized_keys여기서 눈에 걸리는 부분이 하나 있었다.
/home/ubuntu = 777.ssh와 authorized_keys는 정상 권한이었는데 상위 홈 디렉터리가 world-writable 상태였다.
우회
홈 디렉터리 권한을 일반적인 형태로 다시 변경했다.
chown ubuntu:ubuntu /home/ubuntu
chmod 755 /home/ubuntu
chown -R ubuntu:ubuntu /home/ubuntu/.ssh
chmod 700 /home/ubuntu/.ssh
chmod 600 /home/ubuntu/.ssh/authorized_keys
sync다시 확인했다.
stat -c '%U:%G %a %n' \
/home/ubuntu \
/home/ubuntu/.ssh \
/home/ubuntu/.ssh/authorized_keys결과:
ubuntu:ubuntu 755 /home/ubuntu
ubuntu:ubuntu 700 /home/ubuntu/.ssh
ubuntu:ubuntu 600 /home/ubuntu/.ssh/authorized_keys이후:
exec /sbin/init으로 정상 부팅.
PuTTY에서 기존 OCJP.ppk로 다시 접속했다.
이번에는 바로 접속됐다.
그래서 최초 원인이 777이었나?
여기까지 보면:
/home/ubuntu 777이 모든 문제의 시작처럼 보일 수 있다.
그런데 그건 확실하게 말할 수 없다.
내가 /home/ubuntu 권한을 처음 확인한 시점은 복구 작업을 상당히 진행한 이후였기 때문이다.
그 사이에:
- Bastion Session 생성
- 새로운 공개키 테스트
- authorized_keys 여러 차례 수정
- init=/bin/bash로 복구 부팅
- 비정상적인 Reboot
- 파일 재생성
등을 이미 진행했다.
따라서 최초 SSH 장애가 발생했을 당시에도 /home/ubuntu가 777이었는지는 확인할 자료가 없다.
최종적으로 정상화한 권한
결국 SSH 관련 경로는 다음 상태로 맞췄다.
/home/ubuntu 755
/home/ubuntu/.ssh 700
/home/ubuntu/.ssh/authorized_keys 600소유자는 전부:
ubuntu:ubuntu확인은:
stat -c '%U:%G %a %n' \
/home/ubuntu \
/home/ubuntu/.ssh \
/home/ubuntu/.ssh/authorized_keys다음에 Server refused our key가 뜬다면
적어도 다음에는 Bastion부터 만들지는 않을 것 같다.
서버에 다른 방식으로라도 접근할 수 있다면 우선:
stat -c '%U:%G %a %n' \
$HOME \
$HOME/.ssh \
$HOME/.ssh/authorized_keys부터 확인할 것 같다.
.ssh와 authorized_keys만 볼 게 아니라 그 상위 홈 디렉터리까지 같이 확인하는 게 중요했다.
그리고 이번 삽질 동안 비슷해 보이지만 의미가 다른 오류도 몇 개 만났다.
Connection refused이때는 init=/bin/bash 상태라 sshd 자체가 실행 중이지 않았다.
반면:
Permission denied (publickey)나:
Server refused our key는 SSH 서버까지 도달한 뒤 공개키 인증 단계에서 실패한 상황이었다.
메시지는 비슷해 보여도 확인해야 할 위치가 완전히 달랐다.
마무리
처음에는 SSH 공개키 하나 다시 넣으면 금방 끝날 줄 알았다.
실제로 한 일은:
Bastion 생성
Bastion Plugin 활성화
PPK → OpenSSH 변환
Windows private key ACL 수정
Managed SSH 접속
복구용 A1 생성 시도
복구용 E2 생성 시도
Boot Volume 용량 한도 확인
Run Command 시도
Oracle Cloud Agent 확인
Serial Console
UEFI
GRUB
Root Partition 탐색
Filesystem UUID 확인
Kernel 직접 부팅
init=/bin/bash
authorized_keys 재생성
Reboot 대기
fsck
SSH 권한 재점검까지 갔다.
그리고 마지막으로 접속을 살린 변경은:
chmod 755 /home/ubuntu였다.
이 한 줄이 처음부터 문제였는지는 모른다.
하지만 적어도 그 순간의 Server refused our key를 해결한 건 이 권한 변경이었다.
덕분에 다음에 같은 일이 생기면 어디부터 볼지는 확실히 알게 됐다.