VPN 저장소를 추가한 뒤 NO_PUBKEY로 apt 업데이트가 실패할 때

VPN 공급업체의 apt 소스가 패키지 관리자를 망가뜨렸고, 해결책은 명령이 아니라 결정입니다. NO_PUBKEY, 또는 저장소에 Release 파일이 없다는 불평은 apt가 그 소스를 신뢰하지 않기로 했다는 뜻이므로, 이후의 모든 패키지 작업이 같은 경고를 계속 출력합니다. 터널 자체는 아마 무관합니다. 그 소스를 계속 원하는지에 대한 세 가지 질문에 답하면 올바른 수리가 거의 기계적으로 결정됩니다.

먼저 실패를 올바른 분류에 넣으세요

신뢰 실패는 소스 파일 이름과, 빠진 키 또는 없는 Release 파일을 지목합니다. 전송 실패는 모습이 다릅니다. TLS 인증서 오류, 연결 거부, 시간 초과, 또는 CONNECT를 거부하는 프록시입니다. 이 구분이 어떤 글을 읽어야 하는지를 정합니다. TLS를 가로채거나 공급업체 호스트를 막는 VPN은 서명 오류가 아니라 전송 오류를 냅니다.

sudo apt update만 실행하고 위에 있는 캐시된 결과는 무시한 채 끝부분을 읽으세요. 중요한 줄은 /etc/apt/sources.list.d/ 를 지목하며 어떤 파일을 열어야 하는지 알려줍니다.

터널이 올라온 뒤에 실패한다면 터널을 내린 상태와 DNS를 시스템 리졸버로 해석한 상태에서 시험하세요. VPN 없이 동작하는 소스라면 경로나 가로채기 문제이며, 어떤 키 관리로도 고쳐지지 않습니다.

길을 고르는 세 가지 질문

이 소스에서 아직 패키지를 설치하거나 업그레이드하나요? 클라이언트를 실제로 쓰고 있다면 신뢰를 수리하세요. 클라이언트를 한 번 설치하고 이제 NetworkManager로 평범한 프로필을 가져오는 정도라면, 그 소스는 쓸모없는 짐이고 제거가 정직한 수리입니다.

둘째, 공급업체가 대역 밖에서 검증할 수 있는 키와 지문을 공개하나요? 셋째, 이 호스트의 키를 누가 관리하나요, 배포판인가요 아니면 당신인가요? 검증할 수 없는 키로 서명된 소스는 주어서는 안 될 업데이트 권한입니다.

첫 질문에 아니라고 답하면 분석은 끝납니다. 세 항목 모두 예라면 signed-by 수리로 이어지며, 그것이 동작하면서 감사 가능성도 유지하는 유일한 구성입니다. 두 길을 섞어 소스를 남긴 채 억지로 통과시키는 것만은 분명히 배제할 가치가 있습니다.

trusted=yes가 수리처럼 보이지만 아닌 이유

sources.list 매뉴얼 페이지 는 이 점을 분명히 말합니다. Trusted 옵션을 yes 로 설정하면 인증에 실패해도 소스를 받아들이라고 apt에 지시하는 것이고, 그 저장소의 apt-secure가 꺼집니다. 페이지는 이것을 쓰더라도 로컬 맥락으로 한정합니다.

이것은 공급업체를 신뢰하는 좁은 버전이 아닙니다. 인덱스에 누가 서명했는지라는 질문을 없애므로, 그 호스트 이름에 답할 수 있는 사람이면 누구든 root로 설치되는 패키지를 당신의 기계에 건넬 수 있습니다.

수리 경로: 키를 가져온 뒤 고정하세요

공급업체가 문서화한 위치에서 키를 가져와 관리자가 관리하는 키링으로 풀어 넣고, 저장소 줄을 그 파일로 향하게 해서 신뢰가 흘러가지 않게 하세요.

1. 실패하는 줄을 읽어 키 ID와 소스 파일 이름을 얻으세요.
2. 공급업체의 ASCII 장갑 키를 내려받아 gpg --dearmor 를 /etc/apt/keyrings/vendor-name.gpg 로 실행하세요.
3. [signed-by=/etc/apt/keyrings/vendor-name.gpg] 를 그 공급업체의 .list 파일 항목에 추가하세요.
4. 실행하세요 sudo apt update 그리고 소스가 서명 경고를 반복하는 대신 인덱스를 가져오는지 확인하세요.

패키지와 함께 오는 키에는 /usr/share/keyrings 를, 직접 두는 키에는 /etc/apt/keyrings 를 우선하세요. 이 구분은 겉치레가 아닙니다. 다음 관리자에게 어떤 키가 패키지 업그레이드를 견디고 어떤 키에 사람이 필요한지 알려줍니다.

신뢰하기 전에 지문을 공급업체의 공개 값과 대조하세요. 포럼 글에서 붙여 넣은 키 ID는 누구도 이름 붙일 수 없는 업데이트 권한을 기계가 신뢰하기 시작하는 통로입니다.

제거 경로, 그리고 오류가 다시 올 수 있는 이유

설치 프로그램이 실제로 무엇을 썼는지 보세요. 여러 파일이 같은 공급업체를 언급할 수 있고 그중 하나는 보통 남은 사본입니다.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt는 그 디렉터리에서 .list 와 .sources 파일만 읽으므로 .save 나 .distUpgrade 사본은 이미 무시됩니다. 그래도 지우면 나중에 읽는 사람이 실수로 되살리지 못합니다. 소스를 제거해도 무엇도 설치 해제되지 않으며, apt는 그 뒤 설치된 VPN 패키지를 로컬 설치 또는 더 이상 사용할 수 없음으로 설명할 수 있는데, 이는 패키지 상태 메시지이지 신뢰 오류의 재발이 아닙니다.

반복되는 사례는 키를 apt-key 로 전역 신뢰 고리에 설치하던 오래된 안내입니다. 그 경로는 폐기되었고, 릴리스 업그레이드가 키를 떨어뜨리거나 그냥 참조되지 않게 남길 수 있습니다. 일 년 동안 조용하던 오류가 업그레이드하는 주에 나타나는 이유가 바로 그것입니다. /etc/apt/trusted.gpg.d/ 를 확인하고, 그다음 신뢰 결정을 저장소 줄, 제자리로 옮기세요. 공급업체가 여전히 apt-key 지침을 싣고 있다면 그래도 signed-by를 쓰세요. 매뉴얼이 문서화한 구성이고, 업그레이드를 견디는 쪽도 그것입니다.