OpenVPN 서비스가 개인 키 암호 입력에서 멈춥니다: 해결 방법
서비스에는 터미널이 없으므로 암호화된 키에는 askpass와 읽을 수 있는 파일이 필요합니다. 키 암호와 서버 로그인을 분리하고 unit을 확인하세요.
OpenVPN 은 로컬 머신에서 개인 키 암호를 묻기 때문에, 정상적인 로그인 파일이 그것에 답하지 못합니다. 서비스에는 입력할 터미널이 없고, 시작은 멈추거나 원인이 아니라 입력을 지목하는 저널 항목과 함께 실패합니다. 여기에는 두 가지 비밀이 있고, unit을 다시 시작하기 전에 각각 자신의 읽을 수 있는 원천이 필요합니다. 아래 과정은 둘을 분리한 뒤, 실제로 각 파일을 여는 ID를 확인합니다.
두 프롬프트를 구분하세요
키 암호는 로컬 개인 키를 복호화하고, 계정 자격 증명은 서버와의 세션을 인증합니다. 둘은 다른 곳에서 오고, 다른 시점에 실패하며, 다른 메시지를 냅니다. 이를 혼동하면 계정이 관여하지도 않았는데 암호 재설정을 찾게 됩니다. 어떤 비밀이 빠졌는지 알려 주는 신뢰할 만한 단서는 문구뿐이므로, 옵션을 바꾸기 전에 프롬프트 문장을 읽으세요.
Community OpenVPN 2.x 에서 askpass 은 첫 줄에 키 암호를 담은 파일을 가리키고, auth-user-pass 은 한 줄에 사용자 이름, 다음 줄에 암호를 담은 파일을 가리킵니다. 어느 파일도 다른 옵션을 만족하지 못합니다. 데스크톱 앱이나 NetworkManager 프로필은 둘 다 자체 비밀 저장소에 보관할 수 있고, 명령줄 클라이언트는 그것을 읽지 않으므로, 경로를 쓰기 전에 어떤 클라이언트를 구성하는지 확인하세요.
두 옵션을 읽을 수 있는 파일로 지정하세요
두 입력이 모두 필요한 프로필은 결국 세 개의 파일 참조 를 갖습니다. 암호화된 키, 그것을 여는 암호, 로그인 쌍입니다. CA와 ID 검사는 건드리지 말고 추가하세요. 그것들은 서버가 누구인지 정하며 이 문제의 범위가 아닙니다. 배포가 계정 자격 증명을 전혀 쓰지 않는다면, auth-user-pass 를 더하면 아무도 제공할 수 없는 입력이 생깁니다.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth인수 없는 옵션은 경로가 있는 옵션과 다르게 동작하며, 서비스에서는 이 차이가 중요합니다. 인수 없는 askpass 은 여전히 콘솔을 읽고, 사용자 이름만 있는 auth-user-pass 파일은 여전히 암호 입력 대기를 남깁니다. 클라이언트가 데몬이 되면 터미널에 입력을 요청할 수 없으므로, 이렇게 구성된 서비스는 올라오지 않습니다.
절대 경로는 작업 디렉터리 문제를 없애지만 접근 권한을 주지는 않습니다. 그다음 소유자, 모드, 경로 통과가 오고, 셋 모두 프로세스가 실행되는 계정에 대해 확인됩니다.
프로필보다 먼저 unit 구성을 읽으세요
인스턴스가 어떤 구성을 읽을지는 편집하던 파일이 아니라 unit이 정합니다. 그 명령줄과 모든 drop-in을 읽고, 작업 디렉터리를 따라 실제로 쓰이는 프로필로 가세요. 다른 .ovpn 파일에 넣은 암호 참조는 이 인스턴스에 아무것도 바꾸지 않습니다.
세 개의 읽기 전용 명령이 대부분을 답합니다. 첫째는 unit과 모든 drop-in을, 둘째는 프로세스를 묶는 ID와 샌드박스 설정을, 셋째는 지난 시작이 실제로 무엇을 호소했는지를 출력합니다. 호스트에 있는 인스턴스 이름을 쓰세요.
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome 과 프로필 자체의 user, group, chroot 옵션에 주의하세요. 홈 디렉터리 아래의 파일은 셸에서는 읽히지만 홈 디렉터리가 가려지면 서비스 내부에서는 보이지 않습니다. systemd가 시작하는 계정이 항상 마지막에 키를 여는 계정은 아닙니다.
런타임 ID가 두 파일을 모두 열 수 있음을 증명하세요
모드를 읽는 것만으로는 부족합니다. 경로의 모든 디렉터리가 같은 ID로 통과 가능해야 하기 때문입니다. 경로를 구성 요소별로 따라가고, 프로세스가 쓰는 계정으로 열기를 시험하세요. root 소유에 모드 600 인 파일은 프로세스가 아직 root일 때만 동작하며, 많은 프로필이 하는 권한 하강 후에는 그렇지 않습니다. 두 명령이 통과와 열기를 모두 다룹니다.
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable첫 명령은 각 구성 요소의 모드를 출력하고 계정이 통과할 수 없는 곳에서 실패합니다. 둘째는 유일하게 중요한 질문, 즉 런타임 ID가 그 파일을 읽기용으로 열 수 있는지에 답합니다. 둘 다 파일 내용을 출력하지 않으며, 파일이 암호를 담을 때 바로 그 점이 핵심입니다. 로그인 파일에도 같은 시험을 반복하세요. 둘은 흔히 다른 소유자로 저장됩니다.
프로세스가 chroot나 제한된 namespace를 쓴다면 같은 시험을 그 뷰 안에서 실행하세요. 그렇지 않으면 답은 잘못된 파일 시스템을 설명합니다. 숨겨진 홈 디렉터리 아래에 둔 암호는 unit 밖에서는 통과하고 안에서는 실패하는 시험의 전형적인 예입니다.
첫 시작을 확인한 다음 재연결을 확인하세요
인스턴스를 한 번 시작하고 마지막이 아니라 첫 실패를 읽으세요. 입력 파일 누락, 키 복호화 실패, 서버 측 AUTH_FAILED 는 서로 다른 세 사건이고 수리도 셋으로 나뉩니다. 권한 경고를 고쳐도 키가 열렸는지는 아무것도 증명하지 못합니다.
저널 줄이 셋 중 어느 것인지 알려 줍니다. 수리는 어느 입력이 실패했는지에서 나옵니다.
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
그다음 실제로 필요한 수명 주기 를 시험하세요. 부팅 시 시작과 지원되는 모든 재연결이며, 셸에서 수동으로 시작하는 것만이 아닙니다. auth-nocache 에서는 입력이 첫 사용 후 버려지므로, 이후 재연결에도 읽을 수 있는 원천이 필요합니다. 데스크톱 로그인 때 열리는 키링은 누군가 로그인하기 전에 시작된 서비스에 쓸 수 없고, 수동 시험은 통과하는데 재부팅은 실패하는 흔한 이유가 이것입니다. 첫 시작이 성공하고 이후 재연결이 실패하면, 권한을 다시 바꾸기 전에 재연결 사건의 저널을 읽으세요.
암호를 키 옆에 두면 암호화가 주는 이점이 줄어들므로, 그 파일과 백업을 제한하세요. 키 암호 제거는 빠진 입력의 수리가 아니라 별도의 자격 증명 결정으로 다루세요. 사람의 승인이나 대화형 MFA에 의존하는 배포에는 지원되는 에이전트나 관리 통합이 필요합니다. 영구 저장된 일회용 코드는 동등한 대체물이 아닙니다.