GCP SSH authentication has failed 해결

임동혁 Ldhbenecia·2025년 8월 26일

Devops & Infra

목록 보기
4/4
post-thumbnail

개요

CI/CD가 실패하였다.

코드를 복사해서 동기화를 시키는 과정에서 깨졌고 SCP 오류가 발생하길래
대체 어떤 이슈인가 하여 인스턴스에 직접 연결하려고 하였으나 아래와 같이 연결이 불가능했다.

[2634896.861606] systemd-journald[128]: Failed to create new runtime journal: No such file or directory 
[2745305.921730] systemd-journald[128]: Failed to create new system journal: No space left on device 
[2745305.932901] systemd-journald[128]: Failed to create new user journal: No space left on device

직렬 포트 로그를 찾아보니 제일 하단부에 No space가 잔뜩 떠 있었다.

처음 인스턴스를 생성할 때 용량을 좀 줄였다가 Docker 기반 데이터가 쌓여서 한번 정리를 해준 다음
용량을 늘려주고 해당 디스크로 Docker 경로를 수정했는데도 불구하고, 처음에 설정했던 용량이 작아서 발생한 것 같다.

더 문제점은 직렬 포트 연결 사용이 중지되어 콘솔에 따로 입력을 할 수 없었다.

부팅 디스크 스케일 업

부팅 디스크 용량이 부족하므로 10GB에서 30GB로 늘렸고 실행해보았으나 여전히 실행이 되지 않았다.

부트 디스크를 다른 인스턴스에 연결해서 수정

  1. 현재 인스턴스 중지
  2. 부트 디스크를 다른 정상 동작하는 Ubuntu 인스턴스에 추가 디스크로 연결
  3. 마운트 후 로그 파일 이동, /var/log/journal 또는 /tmp 정리
  4. 디스크 분리 후 원래 인스턴스에 다시 붙이고 부팅

문제 상황 정리

  • GCE 인스턴스의 부팅 디스크(10GB) 용량이 가득 차 SSH 접속이 불가능해짐
  • 디스크 크기를 30GB로 확장했지만 파티션 및 파일시스템이 확장되지 않아 문제가 지속됨
  • 임시 인스턴스에 문제의 디스크를 추가 디스크로 연결하여 복구 작업을 진행함

1. 디스크 연결 및 기본 정리

임시 인스턴스에 문제가 생긴 디스크(sdb)를 연결하고 마운트하여 기본적인 파일을 정리한다.

# 1. 연결된 디스크 파티션 구조 확인
lsblk

# 2. 작업용 디렉터리(마운트 포인트) 생성
sudo mkdir -p /oldD

# 3. 문제의 디스크 파티션을 작업용 디렉터리에 마운트
# /dev/sdb1은 주 파티션을 의미
sudo mount /dev/sdb1 /oldD

# 4. 마운트된 디스크의 용량 확인 (100% 점유 상태 확인)
df -h

# 5. 불필요한 로그, 임시 파일, 패키지 캐시 삭제로 최소 공간 확보
sudo rm -rf /oldD/var/log/*.log.*
sudo rm -rf /oldD/tmp/*
sudo rm -rf /oldD/var/cache/apt/archives/*

2. 파티션 및 파일시스템 확장

디스크 크기에 맞게 파티션과 그 안의 파일시스템을 확장한다.

# 1. 마운트 포인트 밖으로 이동 (umount 오류 방지)
cd /

# 2. 작업 디렉터리 마운트 해제
sudo umount /oldD

# 3. (핵심) /dev/sdb 디스크의 1번 파티션을 디스크 최대 크기로 확장
sudo growpart /dev/sdb 1

# 4. 파일시스템 무결성 검사 (권장)
sudo e2fsck -f /dev/sdb1

# 5. (핵심) 확장된 파티션 크기에 맞게 파일시스템 리사이즈
sudo resize2fs /dev/sdb1

3. 용량 분석 및 심층 정리

확장된 디스크를 다시 마운트하고, 어떤 파일이 용량을 많이 차지했는지 분석하여 근본 원인을 정리한다.

# 1. 확장된 디스크를 다시 마운트
sudo mount /dev/sdb1 /oldD

# 2. 확장 결과 확인 (Size가 29G 정도로 표시되는지 확인)
df -h

# 3. 디스크 용량 상세 분석 (용량 큰 순으로 정렬)
sudo du -sh /oldD/* | sort -rh
sudo du -sh /oldD/var/* | sort -rh
sudo du -sh /oldD/var/lib/* | sort -rh

# 4. 분석 결과에 따라 불필요한 대용량 파일/디렉터리 삭제
# 예: 오래된 Docker 데이터 삭제
sudo rm -rf /oldD/var/lib/docker.old

4. 정리

기존의 10GB였던 부팅디스크를 30GB로 확장 후 파일 시스템 리사이즈 처리를 끝낸 후 이 깡통 인스턴스는 제거한다.
그리고 기존에 띄웠던 서버의 부팅디스크에 이 디스크를 다시 넣어서 인스턴스를 실행한다.

정상적으로 복구가 되었다.

학습 참조: https://hyungin0505.tistory.com/61

profile
지극히 평범한 공대생

0개의 댓글