Ubuntu 26.04 강좌 / 공식 ISO 내려받고 체크섬·전자서명 검증하기
Ubuntu 26.04 ISO는 공식 다운로드 경로에서 받은 뒤, 같은 배포 위치의 SHA256SUMS와 SHA256SUMS.gpg로 확인합니다. 전자서명은 체크섬 목록의 서명자를 검증하고, SHA-256 비교는 내려받은 ISO가 그 목록의 값과 같은지 확인하므로 두 검사를 구분해 진행해야 합니다.
ISO·체크섬 목록·서명 파일 준비하기
ISO는 설치 매체의 내용을 담은 디스크 이미지입니다. 일반 VM에서는 가상 광학 드라이브에 연결해 사용할 수 있으며, 물리 PC용 USB 설치 매체를 만들 때는 별도의 이미지 기록 과정이 필요합니다. ISO 파일을 다운로드했다는 사실만으로 USB가 부팅 가능한 상태가 되지는 않습니다.
Ubuntu Server 다운로드에서 26.04 LTS와 아키텍처를 선택합니다. 이 글의 amd64 예시는 ubuntu-26.04.1-live-server-amd64.iso이며, 다른 아키텍처나 포인트 릴리스를 받았다면 실제 파일명과 같은 배포 디렉터리의 검증 자료를 사용합니다.
- 예를 들어 다운로드 폴더 안에
ubuntu-26.04-verify라는 작업 폴더를 만들고 선택한 ISO를 저장합니다. - ISO가 있는 공식 배포 목록에서
SHA256SUMS와SHA256SUMS.gpg를 받아 같은 폴더에 둡니다. amd64 예시는 26.04 공식 배포 디렉터리에서 확인할 수 있습니다. - 파일 확장자가 숨겨져 있다면 표시하도록 바꿉니다. 체크섬을 저장한 파일이
SHA256SUMS.txt나 HTML 페이지가 되지 않았는지, ISO가 아직 임시 다운로드 파일인 상태는 아닌지 확인합니다.
.torrent나 .zsync는 다운로드를 위한 별도 자료이며 ISO 자체가 아닙니다. 또 26.04.1 ISO에 다른 릴리스·다른 이미지 위치의 체크섬을 적용하면 정상 파일도 일치하지 않을 수 있습니다. 세 파일을 한 폴더에 모으는 것은 작업을 단순하게 하기 위한 것이고, 파일들이 서로 대응하는지 확인하는 일은 별도로 필요합니다.
체크섬 목록과 서명 파일은 받은 바이트 그대로 사용합니다. 텍스트 편집기로 내용을 저장하면서 줄바꿈이나 문자 인코딩을 바꾸면 서명 검증에 실패할 수 있습니다. 내용을 읽어 보는 것과 편집한 파일을 다시 저장하는 것을 구분하세요.
해시 일치와 전자서명 검증의 차이
SHA-256은 파일의 바이트 내용을 고정 길이의 해시값으로 계산하는 방식입니다. ISO의 실제 값이 신뢰할 수 있는 기대값과 같다면 같은 내용을 받았는지 확인할 수 있습니다. 그러나 공격자가 ISO와 체크섬 목록을 함께 바꾼 상황까지 해시 비교만으로 구분할 수는 없습니다.
SHA256SUMS.gpg는 체크섬 목록에 대한 분리 서명입니다. GnuPG의 gpg로 서명을 검사하고, 사용한 공개키의 전체 지문을 Ubuntu 공식 안내와 대조한 뒤 체크섬을 비교합니다. 서명자가 누구인지 확인하는 단계와 파일이 일치하는지 확인하는 단계를 합쳐서 ‘해시가 맞으니 공식 파일이다’라고 단정하지 않습니다. 검증의 기본 절차는 Ubuntu 공식 다운로드 검증 안내를 참고하세요.
GnuPG와 별도 공개키 폴더 준비하기
서명 검증에는 GnuPG가 필요합니다. Ubuntu의 신뢰할 수 있는 기존 환경에서는 command -v gpg로 명령 존재 여부를 확인하고, 없다면 공식 저장소에서 sudo apt install gnupg로 설치할 수 있습니다. Windows에서는 Gpg4win 공식 배포판처럼 신뢰할 수 있는 GnuPG 설치 경로를 사용하고 새 터미널에서 gpg --version이 동작하는지 확인합니다. 임의의 실행 파일을 검색해 내려받지는 않습니다.
아래 GPG 명령은 작업 폴더를 현재 위치로 연 터미널에서 실행합니다. Windows PowerShell과 Linux 터미널 모두 외부 명령인 gpg를 사용할 수 있지만 설치 경로가 준비되어 있어야 합니다. 현재 폴더 안에 ubuntu-verify-keys라는 빈 디렉터리를 먼저 만드세요. Linux에서는 mkdir -m 700 ubuntu-verify-keys, Windows에서는 파일 탐색기의 새 폴더 기능을 사용할 수 있습니다. 기존에 같은 폴더가 있다면 새 이름을 정하고 명령의 경로도 함께 맞춥니다.
별도 폴더를 지정하면 평소 사용하던 공개키 저장소와 검증용 키를 구분할 수 있습니다. 여기에는 비밀키나 로그인 비밀번호를 넣지 않습니다. 아래에서 사용하는 전체 지문은 Ubuntu의 ‘Ubuntu CD Image Automatic Signing Key (2012)’에 대응하며, 키 이름이나 짧은 키 ID만 같다는 이유로 신뢰하지 말고 공식 안내의 전체 지문과 비교해야 합니다.
gpg --homedir ./ubuntu-verify-keys --keyserver hkps://keyserver.ubuntu.com --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg --homedir ./ubuntu-verify-keys --fingerprint 843938DF228D22F7B3742BC0D94AA3F0EFE21092공식 안내와 대조할 지문은 다음과 같습니다. 공백은 읽기 편하도록 나눈 것이며, 비교할 때는 40자리 전체를 확인합니다.
8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092키 서버는 공개키를 가져오는 경로이며, 그 서버에서 키를 받았다는 사실 자체가 소유자의 신뢰를 보장하지는 않습니다. 키가 교체되었거나 서명에 다른 키가 사용되었다면, 오류 메시지에 나온 ID를 무조건 가져와 통과시키지 말고 현재 Ubuntu 공식 검증 안내를 다시 확인하세요.
체크섬 목록의 서명 확인하기
gpg --homedir ./ubuntu-verify-keys --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS첫 번째 파일은 서명, 두 번째 파일은 서명된 체크섬 목록입니다. Good signature와 서명자의 정보·지문을 확인하고, 바로 뒤의 종료 상태도 확인할 수 있습니다. Linux 셸에서는 printf 'exit=%s\n' "$?", PowerShell에서는 $LASTEXITCODE를 바로 실행해 0인지 확인합니다. 표시 문구와 날짜는 언어·서명 시점에 따라 달라질 수 있습니다.
별도 키 저장소에서는 This key is not certified with a trusted signature 같은 신뢰 관계 경고가 나올 수 있습니다. 이는 서명 계산이 틀렸다는 BAD signature와 다른 메시지입니다. 그렇다고 경고를 무조건 무시하는 것이 아니라, 앞 단계에서 확인한 전체 지문이 Ubuntu 공식 안내와 일치하는지까지 함께 판단해야 합니다. 분리 서명 검사에서 두 파일을 명시하는 이유는 GnuPG의 verify 명령 설명에서도 확인할 수 있습니다.
No public key라면 필요한 공개키를 가져왔는지와 지정한 키 폴더가 같은지 확인합니다. BAD signature라면 체크섬 목록과 서명 파일의 조합, 파일이 HTML로 잘못 저장되었는지 등을 확인하고 공식 위치에서 다시 받습니다. 이 단계가 해결되지 않았다면 그 목록을 신뢰한 검증이 완료됐다고 판단하지 않습니다.
Windows PowerShell에서 ISO 해시 비교하기
ISO·체크섬·서명 파일을 둔 폴더를 파일 탐색기에서 연 뒤, 그 폴더를 현재 위치로 하는 PowerShell 터미널을 엽니다. Get-Location과 Get-ChildItem으로 경로와 파일을 확인하세요. 아래 코드는 $isoName에 적은 파일의 항목이 정확히 하나 있을 때만 비교하며, 전체 64자리 값을 대소문자 구분 없이 대조합니다. 파일명의 .1·live-server·amd64/arm64를 실제 다운로드와 맞춥니다.
$isoName = 'ubuntu-26.04.1-live-server-amd64.iso'
$pattern = '^([0-9A-Fa-f]{64}) [ *]' + [regex]::Escape($isoName) + '$'
$entries = @(Get-Content -LiteralPath '.\SHA256SUMS' | Where-Object { $_ -match $pattern })
if ($entries.Count -ne 1) {
throw 'Expected exactly one matching checksum entry.'
}
$expected = ($entries[0] -split '\s+', 2)[0]
$actual = (Get-FileHash -LiteralPath $isoName -Algorithm SHA256).Hash
if ($actual -ieq $expected) {
'SHA-256 MATCH'
} else {
throw 'SHA-256 MISMATCH: do not use this image.'
}계산값이 같으면 SHA-256 MATCH가 나옵니다. 항목이 없다는 오류는 파일명이나 검증 목록이 다른 경우일 수 있고, 값이 다르다는 오류는 내용이 다르다는 뜻입니다. 두 오류를 같은 것으로 처리하지 마세요. Get-FileHash 공식 문서는 파일 해시와 알고리즘 선택을 설명합니다.
Linux에서 ISO 해시 비교하기
Linux에서는 세 파일을 둔 작업 폴더로 이동한 뒤 pwd와 ls로 위치를 확인합니다. sha256sum --help에서 --check와 --ignore-missing 옵션을 지원하는지도 확인하세요. 아래 명령은 목록에 있지만 현재 폴더에 없는 파일을 건너뛰므로 여러 아키텍처·설치 형태가 함께 적힌 목록을 사용할 때 편리합니다.
sha256sum --check --ignore-missing SHA256SUMS
printf 'exit=%s\n' "$?"선택한 파일에 대해 ubuntu-26.04.1-live-server-amd64.iso: OK와 종료 상태 0을 확인합니다. 폴더 안에 ISO가 여러 개라면 다른 파일의 OK만 보고 자신이 사용할 파일까지 통과했다고 생각하지 마세요. 검사할 파일이 하나도 없거나 내용이 다르면 실패로 처리되며, 목록에 없는 임의의 파일은 이 명령으로 자동 검증되지 않습니다.
Windows PowerShell과 Linux 예시는 같은 ISO를 같은 서명 검증된 목록과 비교하는 두 가지 경로입니다. 두 운영체제를 모두 준비할 필요는 없습니다. 다만 Windows에서 해시만 비교하고 GPG 서명을 확인하지 않았다면, 완료한 것은 해시 일치 확인 단계라는 점을 구분합니다.
실패했을 때 점검할 순서
| 증상 | 우선 확인 | 처리 |
|---|---|---|
| 체크섬 목록에 ISO 이름이 없음 | 릴리스·아키텍처·파일명·다운로드 위치 | 그 ISO와 같은 공식 배포 위치의 검증 자료 사용 |
| 해시가 다름 | 다운로드가 끝났는지, 파일이 변경되었는지 | 해당 ISO 사용을 멈추고 공식 위치에서 다시 다운로드·재검증 |
| 서명 키를 찾지 못함 | 키 폴더·전체 지문·공식 키 안내 | 공식 지문을 확인하고 필요한 공개키 준비 |
| 서명이 올바르지 않음 | SHA256SUMS와 서명 파일의 짝, HTML 오저장 | 두 파일을 공식 경로에서 다시 받고 서명부터 재확인 |
검증을 마치면 ISO 원래 파일명·다운로드 경로·확인한 서명 지문과 결과를 작업 기록에 남깁니다. 가상 머신에 연결할 때도 검증한 바로 그 파일을 선택하세요. USB에 이미지를 기록하거나 설치 대상 디스크를 정하는 작업은 데이터를 바꿀 수 있으므로, 파일 검증 완료와 실제 설치 대상 확인을 각각 수행해야 합니다.
