OpenConnect의 --key-password는 VPN 계정 비밀번호인가요?

옵션 이름을 문자 그대로 읽으세요. 그것은 키를 가리키며, 열리는 파일이 인증되는 계정과 혼동될 때 혼란이 시작됩니다. 그 옵션에 계정 비밀번호를 붙여 넣으면 클라이언트가 그것으로 키 파일을 열려고 시도하고, 이는 VPN 로그인과 아무 관련이 없는 이유로 실패합니다.

혼란스러운 점은 하나의 연결이 두 비밀을 모두 정당하게 필요로 할 수 있다는 것입니다. 클라이언트 인증서 인증에는 암호화된 키가 필요할 수 있고, 인증서가 수락된 뒤에도 같은 게이트웨이가 사용자 인증 교환을 수행할 수 있습니다. 어느 비밀도 다른 단계를 충족하지 못하며, 한쪽의 실패는 밖에서 보면 다른 쪽의 실패와 매우 비슷합니다.

두 개의 비밀, 두 가지 다른 역할

역할을 파일 접근과 네트워크 진입 허가로 나누어 읽으세요. 키 비밀번호는 --sslkey에 지정된 PEM 개인 키를 복호화하여 TLS 클라이언트 인증서를 제시할 수 있게 합니다. 그 복호화는 클라이언트 프로세스 안에서 로컬로 일어나며, 암호 문구 자체는 게이트웨이로 전달되지 않습니다. 게이트웨이가 보는 것은 인증서와 키로 만든 서명입니다. OpenConnect의 설명서는 --key-password를 --certificate 및 --sslkey 옆에 두며, TPM에 보관된 키를 사용할 수 있는 빌드에서는 같은 옵션이 대신 저장소 루트 키의 비밀번호를 담습니다.

계정 비밀번호는 종류가 다릅니다. 그것은 사용자 이름과 비밀번호 양식, 토큰, SAML 왕복, 또는 게이트웨이가 알리는 어떤 조합으로 인증 교환에 들어갑니다. 인증서가 유일한 요소일 때 전혀 요구하지 않는 배포도 있고 인증서 뒤에도 요구하는 배포도 있는데, 인증서는 장치를 증명하고 계정은 사람을 증명하기 때문입니다.

둘을 섞으면 오해를 부르는 오류가 생깁니다. 로그인을 거부하는 게이트웨이는 보통 인증 실패를 보고하지만, 잘못된 키 암호 문구는 보통 더 일찍, TLS 계층이 키 파일을 읽지 못할 때 실패합니다. 이것들은 다른 단계이고 해결책도 다르지만 이름이 비슷해서 사람들이 서로 바꾸어 쓰고 나서 잘못된 로그를 쫓으므로, 설정을 바꾸기 전에 어떤 프롬프트가 나타났는지 기록하세요. 프롬프트의 문구가 가장 값싼 진단 수단입니다.

키 비밀번호가 정말로 필요한 때

이 옵션은 열어야 할 암호화된 키가 있을 때만 의미가 있습니다. 사용자 이름과 비밀번호로 그리고 클라이언트 인증서 없이 연결한다면 --key-password는 작용할 대상이 없고, 그것을 포함해도 아무것도 바뀌지 않습니다. --certificate와 --sslkey로 연결한다면 암호 문구를 요구할지는 키 파일 자체의 형식이 결정합니다.

하나의 명령에 두 비밀이 있는 것은 관리 환경에서 흔하며, 암호화된 키 안의 장치 인증서에 더해 사용자별 로그인이 있습니다. 올바른 순서는 클라이언트가 키 암호 문구를 로컬에서 묻도록 하고, 인증서 핸드셰이크를 끝낸 다음, 게이트웨이의 계정 프롬프트를 따로 처리하는 것입니다. 하나의 재사용 스크립트로 둘 다 미리 채우려는 시도가 혼란이 보통 시작되는 지점입니다.

유용한 진단은 실패가 언제 일어나는지 보는 것입니다. 네트워크 인증이 시작되기 전에 클라이언트가 멈춘다면 키 파일, 그 형식, 또는 암호 문구를 의심하세요. TLS 세션이 수립된 뒤 게이트웨이가 사용자를 거부한다면 키는 제 역할을 했고 문제는 계정 교환에 있습니다.

두 비밀을 셸 기록 밖에 두기

명령줄 인수는 프로세스 테이블을 통해 다른 로컬 사용자가 읽을 수 있고 셸 기록, 스크립트, 지원 기록에 자주 남습니다. OpenConnect는 --passwd-on-stdin으로 표준 입력에서 계정 비밀번호를 읽을 수 있고, 키 암호 문구는 인수가 아니라 대화형 프롬프트나 에이전트에서 올 수 있습니다. 어느 메커니즘도 비밀을 그 자체로 안전하게 만들지는 않지만, 둘 다 가장 노출된 곳에서 멀리 둡니다.

파일에도 같은 주의가 필요합니다. 암호 문구를 임시 파일에 쓰는 스크립트는 제한된 권한으로 만들고, 종료할 때 삭제하며, 모든 사람이 읽을 수 있는 디렉터리를 피해야 합니다. 세션 후 임시 디렉터리에 남은 암호 문구는 만들기를 잊은 복사본입니다. 환경 변수는 자식 프로세스에 보이고 디버깅 도구에 의해 출력되기 쉬우므로 인수보다 공짜 개선이 아닙니다.

진단 출력은 조용한 유출입니다. 자세한 정도를 높인 클라이언트 로그는 요청 본문이나 옵션 값을 보여 줄 수 있고, 복사한 터미널 기록은 티켓에 붙여 넣기 쉬우므로 공유하기 전에 출력을 읽으세요.

죽은 데스크톱 버튼은 다른 결함입니다

회전 표시를 보여 준 뒤 아무것도 하지 않는 데스크톱 VPN 항목은 보통 인증 문제가 전혀 아닙니다. 그 버튼은 네트워크 관리자, 공급업체 애플릿, 또는 사용자를 대신해 OpenConnect를 실행하는 플러그인의 것이며, 빠진 구성 요소나 읽을 수 없는 프로필이 정확히 그 증상을 만들 수 있습니다. 버튼이 어느 프로세스를 시작하는지 찾아내고 자격 증명을 건드리기 전에 그 오류를 읽으세요.

GUI가 연결을 거부할 때 인증서 검증을 느슨하게 하거나 검사를 끄고 싶어집니다. 그것은 클라이언트 통합 결함을 보안 저하로 바꾸고 실행 문제를 거의 고치지 못합니다. 서버 검증은 그대로 두고, 프로필이 의도한 게이트웨이를 가리키는지 확인하며, GUI가 기대하는 도우미가 실제로 설치되어 있는지 점검하세요.

짧은 점검 목록이 사례를 구분합니다. 패킷이 나가기 전의 로컬 실패는 키나 클라이언트 설치를 가리킵니다. TLS 세션 후의 게이트웨이 거부는 계정 교환을 가리킵니다. 클라이언트를 전혀 시작하지 않는 버튼은 데스크톱 통합을 가리킵니다. 세 가지 다른 결함이며, 그중 하나는 잘못된 상자에 붙여 넣으려던 비밀번호입니다.