잘못된 암호는 컨테이너 문제이지 비밀번호 규칙 문제가 아니다
거부된 자격 증명은 게이트웨이에 도달하지 않았을 수 있다. 먼저 입력 컨테이너, 인증 단계, 계정 자체를 비교하라.
"invalid secrets"를 보면 보통 한 가지 결론이 나온다: VPN이 문장부호를 싫어한다는 것이다. 그 결론은 대개 틀린데, 게이트웨이가 계정을 들여다보기 전에 로컬 처리에서 메시지가 나오는 경우가 많기 때문이다. 같은 비밀번호를 전달하는 두 가지 설계, 즉 그래픽 입력란과 자격 증명 파일은 서로 다른 지점에서 실패한다. 내내 멀쩡했던 비밀번호를 단순화하기 전에 컨테이너를 비교하라.
오류는 게이트웨이보다 먼저 온다
로컬 검증, 잠긴 비밀 저장소, 없는 에이전트, 형식이 잘못된 자격 증명 파일은 모두 사용자에게 하나의 거부로 보이는 실패를 만든다. 그중 어느 것도 인증 서버와 관계없다. 게이트웨이 자체의 거부는 별개의 사건이며, 보통 다른 메시지와 다른 시점에 도착한다. 그것은 터널이 존재하고 자격 증명이 전송된 뒤에 일어난다.
따라서 첫 질문은 어떤 문자가 합법인가가 아니라 시도가 어디서 멈췄는가이다. 연결을 한 번도 열지 않은 클라이언트는 누구에게도 거부되지 않았다. 관찰한 단계를 적어 두어라, 이후의 모든 단계가 그 분류에 달려 있다.
이 구분은 누가 고치는지도 바꾼다. 컨테이너 문제는 기기와 그 소유자의 몫이고, 계정 거부는 인증 백엔드를 운영하는 사람의 몫이다.
문자가 아니라 컨테이너를 비교하라
GUI 비밀번호 입력란, 키체인 항목, 두 줄짜리 자격 증명 파일, 자동화 비밀은 모두 같은 값을 다른 봉투에 담는다. 봉투에는 자체 규칙이 있고, 보통 깨지는 것은 그 규칙이다. 값이 문제인 경우는 드물고 값의 운송이 문제다. 두 개념을 분리하면 진단이 짧아진다.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Community OpenVPN 2.6 클라이언트 옵션 문서는 auth-user-pass용 두 줄 파일을 설명하며, 비밀번호 줄이 없을 때 클라이언트가 대신 물어본다는 동작까지 다룬다. 그 한 가지 세부가 "이미 제공한 비밀번호를 왜 또 묻지"라는 보고 부류를 설명한다. 또한 두 번째 줄이 비어 있는 것은 무해한 형식 선택이 아니라 의미 있는 상태임을 알려 준다.
인용은 또 다른 층이다: 일반 자격 증명 파일 안의 따옴표는 데이터로 저장되지만, 셸은 프로그램이 보기 전에 그것을 제거한다. 같은 문자가 한 곳에서는 무해하고 다른 곳에서는 구조적이다. 표는 클라이언트가 어떤 컨테이너를 썼는지 알려 주지 않으므로, 행을 고르기 전에 클라이언트 자체의 구성을 읽어라.
줄바꿈도 구조적이다. 줄로 구분된 필드를 가진 파일은 개행을 포함한 값을 담을 수 없으며, 이는 형식의 한계이지 비밀번호 강도에 대한 판단이 아니다. 임시 파일에 맞추려고 비밀을 잘라내는 대신 배포가 지원하는 전달 방식을 사용하라.
셸 손상 없이 자격 증명 파일 만들기
가장 안전한 로컬 경로는 비밀을 셸 기록과 프로세스 인자 목록 밖에 두는 것이다. 두 필드를 대화식으로 읽은 다음 클라이언트가 기대하는 두 줄을 써라. 나머지는 검토하기 쉬운 구성 파일에 둘 수 있다.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds처음 두 명령은 사용자 이름과 비밀번호를 에코 없이 읽고, 세 번째는 두 줄을 쓰며, 네 번째는 파일 권한을 제한하고, 마지막은 그 파일로 클라이언트를 시작한다. read -r가 백슬래시를 보존한다는 점에 주목하라, 바로 이런 세부를 빠뜨리면 잘 되던 비밀번호가 실패하기 때문이다.
따옴표 없는 변수나 셸 확장으로 가득한 here-document로 파일을 만들지 마라. 둘 다 문자가 파일에 도달하기 전에 변형할 수 있고, 그 결과 실패는 디스크의 비밀번호가 당신이 아는 비밀번호와 실제로 다르기 때문에 VPN 거부처럼 보인다. 의심되면 비밀 자체를 출력하지 말고 파일의 바이트 길이를 예상 값과 비교하라. 한두 바이트 차이는 인용 사고의 서명이다.
첫 오류에서 단계를 읽어라
한 번의 시도에서 나온 첫 번째 구체적 메시지를 보관한 뒤 분류하라. 로컬 검증 오류, 없는 개인 키, 사용할 수 없는 비밀 에이전트, 게이트웨이 인증 실패는 서로 다른 네 가지 결과이며 책임자도 넷이다. 그중 계정에 관한 것은 하나뿐이다.
올바르게 전달된 자격 증명을 게이트웨이가 정말 거부한다면, 관리자와 함께 계정, 인증 백엔드, 필요한 챌린지를 확인하라. 일반 인증 실패는 금지된 문자를 지목하지 않는다.
승인된 값을 문자와 숫자로 줄이지 말고 올바른 메커니즘으로 복원하라. 비밀번호 정책은 운영자의 것이며, 그것을 조용히 무력화하는 우회는 해결이 아니다. 그것은 다음 사람에게서 진짜 결함을 숨기고, 그 사람은 더 약한 비밀번호로 같은 오류를 만나게 된다.