☰

여러 개의 일치하는 주소가 있는 sshd_config

tag-icon • tag-icon linux ssh openssh sshd
여러 개의 일치하는 주소가 있는 sshd_config

작동하지 않아야 한다고 생각하지만 작동하는 sshd 구성을 이해하려고 노력하고 있습니다. 전제는 제가 개발 중인 프로덕션 시스템에서 비롯되었지만 자체 테스트를 위해 단순화했습니다. 이 간단한 예제가 작동하는 이유를 설명할 수 없기 때문에 더 복잡한 반복이 작동하는 이유도 설명할 수 없습니다.

Auser, Buser 및 Cuser 사용자가 있는 두 개의 서버가 있습니다.

내 클라이언트 컴퓨터의 IP 주소는 192.168.10.1입니다.

내 서버에는 다음과 같은 sshd 구성이 있습니다.

AllowGroups Cuser
Match Address 192.168.10.1
    AllowGroups Cuser Buser
Match Address 192.168.10.1
    AllowGroups Cuser Auser

sshd_config(5)의 매뉴얼 페이지에 따르면

일치에는 조건부 블록이 도입됩니다. 일치하는 줄의 모든 조건이 충족되면 다음 줄의 키워드는 다른 일치하는 줄이나 파일 끝까지 구성 파일의 전역 섹션에 설정된 키워드를 재정의합니다. 조건을 충족하는 둘 이상의 일치 블록에 키워드가 나타나는 경우 해당 키워드의 첫 번째 인스턴스만 적용됩니다.

내 해석은 클라이언트(192.168.10.1)에서는 Cuser와 Buser만 서버에 SSH로 접속할 수 있어야 한다는 것입니다.

그러나 이것을 테스트했을 때 Auser, Buser 및 Cuser 세 사용자 모두 액세스 권한이 있었습니다. 서버의 sshd 로그를 보면 일치하는 각 블록이 어디에 적용되는지 알 수 있습니다.

Jul 25 10:48:59 server1 sshd[3525]: debug3: Trying to reverse map address 192.168.10.1.
Jul 25 10:48:59 server1 sshd[3525]: debug2: parse_server_config: config reprocess config len 854
Jul 25 10:48:59 server1 sshd[3525]: debug3: checking match for 'Address 192.168.10.1' user buser host client addr 192.168.10.1 laddr 192.168.10.4 lport 22
Jul 25 10:48:59 server1 sshd[3525]: debug1: connection from 192.168.10.1 matched 'Address 192.168.10.1' at line 138
Jul 25 10:48:59 server1 sshd[3525]: debug3: match found
Jul 25 10:48:59 server1 sshd[3525]: debug3: reprocess config:139 setting AllowGroups cuser buser
Jul 25 10:48:59 server1 sshd[3525]: debug3: checking match for 'Address 192.168.10.1' user buser host fedora addr 192.168.10.1 laddr 192.168.10.4 lport 22
Jul 25 10:48:59 server1 sshd[3525]: debug1: connection from 192.168.10.1 matched 'Address 192.168.10.1' at line 140
Jul 25 10:48:59 server1 sshd[3525]: debug3: match found
Jul 25 10:48:59 server1 sshd[3525]: debug3: reprocess config:141 setting AllowGroups cuser auser

흥미롭게도 매뉴얼 페이지에 대한 해석에 따르면 첫 번째 "reprocess config:139" 줄만 적용될 것으로 예상했습니다. 이는 AllowGroups 키워드의 첫 번째 인스턴스이기 때문입니다. 그러나 로그를 보면 "구성 재처리 중: 141 AllowGroups cuser auser 설정"이 표시되므로 두 번째 인스턴스를 적용하고 싶을 것입니다.

그러나 세 명의 사용자가 모두 연결할 수 있었기 때문에 이러한 설명 중 어느 것도 올바른 것으로 보이지 않습니다.

그래서 몇 가지 추가 테스트를 통해 sshd_config를 다음과 같이 변경했습니다.

AllowGroups Cuser
Match Address 192.168.10.1
    AllowGroups Cuser Buser
Match Address 192.168.10.1
    AllowGroups Auser

그리고

AllowGroups Cuser
Match Address 192.168.10.1
    AllowGroups Auser
Match Address 192.168.10.1
    AllowGroups Cuser Buser

세 명의 사용자 모두 계속 로그인할 수 있습니다.

또 하나의 최종 테스트

AllowGroups Cuser
Match Address 192.168.10.1
    AllowGroups Buser
Match Address 192.168.10.1
    AllowGroups Auser

마지막으로 Auser와 Buser만 액세스할 수 있습니다.

이는 첫 번째 일치 블록이 기본 설정을 재정의하는 것과 거의 비슷하지만 후속 일치 블록은 이전 일치 블록에 추가됩니다.

답변1

코드를 원하는 만큼 자세히 추적할 수는 없지만 무슨 일이 일어나고 있는지는 알 것 같습니다. 매우 중요한 단서는 명령줄 인수, sshd_config 파일 및 여기에 포함된 파일을 구문 분석하는 루틴의 소스 코드 파일입니다.

/*
 * The strategy for the Match blocks is that the config file is parsed twice.
 *
 * The first time is at startup.  activep is initialized to 1 and the
 * directives in the global context are processed and acted on.  Hitting a
 * Match directive unsets activep and the directives inside the block are
 * checked for syntax only.
 *
 * The second time is after a connection has been established but before
 * authentication.  activep is initialized to 2 and global config directives
 * are ignored since they have already been processed.  If the criteria in a
 * Match block is met, activep is set and the subsequent directives
 * processed and actioned until EOF or another Match block unsets it.  Any
 * options set are copied into the main server config.
 */

기본적으로 세 가지 구문 분석 단계(명령줄 매개변수, 블록을 건너뛰는 첫 번째 패스 , 블록을 읽는 두 번째 패스) 를 통해 구성 키워드와 매개변수(예: Compression no및 ) 를 읽는 루틴이 있습니다 . 구문 분석이 어느 단계에 있는지 추적하는 여러 플래그 변수가 있습니다. 하나는 명령줄 구문 분석을 위한 것이고 다른 하나는 첫 번째 및 두 번째 파일 전달을 위한 것입니다.AllowGroups foo bar bazMatchMatch

AllowGroups, DenyGroups, AllowUsers 및 DenyUsers는 단일 값 대신 여러 값을 사용하는 매개 변수입니다. 따라서 루틴은 해당 줄에 대한 인수 목록을 구문 분석하고 각 인수를 문자열 배열에 추가합니다. 첫 번째 및 두 번째 파일 패스에 대한 플래그는 있지만 "새 일치 블록입니다" 플래그는 없습니다.

즉, 첫 번째 Match 블록이 구문 분석되고(두 번째 패스 시작) AllowGroups 매개변수가 포함되면 기존 값 목록(Match 블록 전)이 삭제되고 Match 블록의 새 매개변수로 대체됩니다. 그러나 두 번째 Match 블록도 일치하여 구문 분석되면 루틴에 목록을 다시 지우라는 신호가 없습니다. AllowGroups가 단일 값 매개 변수인 경우 첫 번째 인스턴스를 위해 각각의 새 인스턴스가 무시됩니다. 그러나 다중 값 매개변수이므로 새 매개변수가 목록에 추가됩니다. 이것은 발견했을 때 혼란스러워지는 행동입니다. (저도요)

내 생각에는 구문 분석 루틴 작성자가 테스트 서버와 같은 구성을 구상하지 않은 것 같습니다. 즉, 동일한 다중 값 매개 변수를 설정하는 여러 개의 유효한 일치 블록을 갖는 것입니다. 일반적으로 하나의 Match 블록만 성공하고 구문 분석됩니다. 왜냐하면 서로 다른 항목과 일치하기 때문입니다. 또는 여러 블록이 성공하는 경우 여러 블록이 발생하는 이유는 각 블록이 서로 다른 매개변수를 설정하기 때문입니다.

며칠 전 댓글에서 이 네 가지 매개변수가 작동하는 방식이 직관적이지 않다고 언급한 적이 있습니다. 이것이 질문에 대한 직접적인 대답은 아니지만 여기에 (후손을 위해) 내가 찾은 내용을 추가하겠습니다.

연결이 설정되고 구성 구문 분석의 두 번째 단계가 완료된 후 코드는 허용/거부 그룹을 확인하여 적용되는 그룹을 확인합니다. DenyUsers, AllowUsers, DenyGroups 및 AllowGroups 순서로 확인됩니다. 허용/거부 테스트 및 결정은 다음 의사코드와 유사하게 작동합니다.

if DenyUsers has > 0 items and user is one of them
    deny
if AllowUsers has > 0 items and user is not one of them
    deny
if DenyGroups has > 0 items and user is member of one of them
    deny
if AllowGroups has > 0 items and user is not a member of any of them
    deny

allow

"거부" 결정이 내려지면 루틴은 추가 확인을 중지합니다. 따라서 "AllowUsers" 목록은 직관적인 방식으로 작동하지 않습니다. "AllowUsers" 목록에 이름을 입력하면 목록에 없는 다른 모든 사용자가 거부됩니다. 다른 사용자가 "AllowGroups" 목록에 있는지 여부는 중요하지 않습니다. "AllowGroups"를 참조하기 전에 코드가 확인을 중지하기 때문입니다. "AllowGroups" 목록에 있는 모든 그룹은 해당 그룹에 속하지 않은 사용자가 "AllowUsers"에 나열되어 있더라도 거부되도록 합니다.

관련 정보