MaxSessions, MaxStartups 아니면 기기 등록: 어떤 SSH 한도를 고를까

가입자당 기기 하나를 약속하는 터널 서비스는 그 약속을 MaxSessions에서 거의 얻지 못하며, 첫 번째 테스트가 보통 그것을 증명합니다. 가입자는 두 번째 ssh 프로세스를 열고, 첫 번째 세션은 계속 실행되며, 두 터널 모두 트래픽을 나릅니다. 각 구성 옵션은 서로 다른 것을 세며, 어느 것도 기기를 세지 않습니다. 약속을 먼저 이름 붙이는 것이 둘 사이의 선택을 분명하게 만듭니다.

각 옵션이 실제로 세는 것

MaxSessions는 인증된 네트워크 연결 하나가 나르는 열린 세션의 수를 제한합니다. 여기서 세션이란 셸, exec 요청, SFTP 같은 하위 시스템, 또는 하나의 SSH 트랜스포트 안에서 멀티플렉스되는 유사한 채널을 뜻합니다. 두 번째 ssh 호출은 두 번째 트랜스포트를 열고, 다시 인증하고, 자기 몫을 받습니다. 첫 연결의 세션 수는 그것과 무관합니다.

MaxStartups는 아직 인증되지 않은 동시 연결을 시작 임계값, 비율, 전체 임계값으로 제한합니다. 절반만 열린 핸드셰이크의 폭주가 인증 전에 데몬의 자원을 고갈시키지 못하도록 존재합니다. 클라이언트가 인증하면 그 연결은 MaxStartups에 대해 세어지지 않고 누군가의 세션이 됩니다. 그것은 결코 사용자별 할당량이 아니었고, 올린다고 해서 가입자가 더 많은 일을 할 수 있지는 않습니다.

기기 등록 규칙은 sshd 옵션이 전혀 아닙니다. 그것은 자격 증명을 발급하고 어느 기기가 그것을 보유하는지 추적하는 시스템에 속하며, 이는 카운터 대신 등록, 목록, 폐기가 필요하다는 뜻입니다. 그 요구를 sshd 구성에 섞는 것이 이런 설계 대부분이 막히는 지점입니다.

MaxSessions가 할당량이기를 멈추는 곳

Match User 블록은 그 사용자에게 어떤 구성 값이 적용되는지를 바꾸므로, 서비스 계정에 더 엄격한 MaxSessions를 설정하기에 자연스러운 곳입니다. 할 수 없는 것은 연결을 가로질러 집계하는 것이며, 옵션은 트랜스포트마다 평가됩니다. 두 트랜스포트는 각자의 한도를 받고, 사용자는 블록이 허용하는 것의 두 배를 갖게 됩니다.

전달은 별개의 놀라움입니다. TCP 전달은 세션 채널이 필요 없으므로 MaxSessions 0은 셸과 하위 시스템을 금지하면서도 -L 및 -R 터널은 허용할 수 있습니다. 오직 전달만 하면서 세션 수를 자기 터널 할당량으로 여기는 서비스는 아무것도 측정하지 않습니다. 그 동작은 OpenSSH 서버 구성 참조에 문서화되어 있으며, 옵션 이름을 중심으로 설계하기 전에 읽을 가치가 있습니다.

로드되었다고 생각하는 파일이 아니라 실제 유효한 구성을 덤프하세요. 포함과 drop-in 디렉터리 때문에 유효한 값이 편집한 값과 다른 경우가 흔합니다.

MaxStartups는 가입자가 아니라 데몬을 보호한다

MaxStartups의 세 부분 형식은 데몬이 새 연결의 일정 비율을 버리기 시작하기 전에 인증되지 않은 연결이 몇 개 존재할 수 있는지를 설명합니다. 기본 형식이 있는 이유는 인증되지 않은 SSH 연결은 여는 것이 싸고 유지하는 것이 비싸기 때문입니다. 이것은 서버를 위한 자원 보호 제어이며, 모두에게 동시에 적용됩니다.

로그인 폭풍 중에 올리는 것은 데몬 보호를 입장과 맞바꾸는 것이며, 때로는 올바른 거래이고 항상 의도적인 거래입니다. 두 번째 터널을 원하는 가입자에게는 첫 터널이 이미 인증되었기 때문에 아무 효과가 없습니다. 둘을 혼동하면 잘못된 증상을 고치면서 동시에 서버를 약화시키는 변경이 됩니다.

로그인이 몰려서 거부될 때는 두 옵션 중 어느 것도 건드리기 전에 데몬 로그에서 인증 전 메시지를 보세요. 메시지는 어느 가드가 작동했는지 알려 주며, 가드들은 서로 바꿀 수 없습니다.

사용자별 슬롯에는 공유 상태가 필요하다

진정한 단일 활성 트랜스포트 정책에는 sshd 밖 어딘가에 보관되는 예약이 필요합니다. 입장 단계는 계정의 슬롯을 원자적으로 확보하고, 연결이 닫히면 해제하고, 클라이언트가 닫지 않고 사라지면 만료시키고, 새 시도가 거부될지 아니면 이전 것을 대체할지 결정해야 합니다. 그 마지막 결정은 활성 터널을 대체하면 누군가의 연결이 끊기기 때문에 기술적 세부가 아니라 제품 결정입니다.

예약은 계정을 받아들이는 모든 서버가 공유해야 합니다. 독립적인 로컬 카운터를 가진 두 호스트는 두 개의 별도 한도를 적용하며, 다른 게이트웨이로 다시 연결하는 가입자는 두 번째 슬롯을 무료로 얻습니다. 상태를 저장하는 무엇이든 접근할 수 없는 저장소가 모든 가입자를 잠그면 안 되기 때문에 자체적인 장애 동작이 필요합니다.

기기 하나 약속에는 등록된 기기마다 별도의 자격 증명을 발급하고 그 계층에서 등록과 폐기를 제어하세요. 복사된 개인 키는 여전히 어디서든 인증되므로, 사용자당 키 하나를 발급하는 것은 몇 대의 기기가 그것을 가졌는지에 대한 증거가 아닙니다.

두 개의 실제 연결로 정책을 확인하라

정책을 쓰기 전에 승인 테스트를 명령으로 작성하세요. 다섯 가지 경우는 첫 번째가 활성인 동안 두 번째 트랜스포트를 여는 것, 하나의 트랜스포트 안의 여러 채널, 포트만 전달하는 클라이언트, 링크가 끊긴 뒤 재연결, 같은 계정이 다른 게이트웨이에 도착하는 것입니다.

먼저 유효한 한도를 읽고, 그다음 정책이 거부해야 할 연결을 여세요. 그 테스트의 두 절반 모두 중요하며, 어느 것도 다른 것의 대체가 아닙니다.

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

두 터미널에서 터널 명령을 두 번 실행하고 포트 22에서 설정된 연결을 세세요. 정책이 하나의 활성 트랜스포트를 주장하는데 둘 다 트래픽을 나른다면, 정책은 집행이 아니라 문서입니다. 그 간극은 MaxSessions를 낮추고 두 번째 트랜스포트가 알아차리길 바라기보다 입장 계층에서 고치세요.