2026 클라우드 Mac SSH MaxStartups·소스별 스로틀링: 공유 Apple Silicon을 지키되 팀을 밖으로 내몰지 않기

한 대의 임대 Apple Silicon 클라우드 Mac에 수많은 외주 인력과 자동화가 올라타면 「연결 재설정」 티켓의 상당수는 네트워크 장애가 아니라 sshd 승인 제어가 과하거나 반대로 무방비인 경우입니다.이 런북의 결론: 동시 연결 피크를 측정하고 MaxStartups와 PerSourceMaxStartups에 명시적 숫자 목표를 두며 sudo sshd -t로 검증하고, 롤백 해시를 CMDB 리스 ID와 같은 티켓에 남깁니다.지시문 비교표, 예시 기준(10:30:100 형식 MaxStartups 곡선), macOS launchd에 맞춘 9단계, CI/NAT 주의사항, 홍콩·도쿄·서울·싱가포르·미국 MacLogin 리전 FAQ를 담았습니다. 스로틀링은 관측 지표와 묶일 때만 운영적으로 버틸 수 있습니다.

유휴 세션이 폭풍으로 보이지 않도록 SSH keepalive·끊김 가이드와 함께 읽고, 인수인계는 공유 SSH 세션 거버넌스 체크리스트로 정리하며, 브루트포스 잡음은 키 순환·2FA 가이드로 먼저 줄입니다. 연결 기초는 MacLogin 도움말, 요금·규모는 가격 페이지를 참고하세요. 사무실 NAT 뒤 셀프호스트 러너가 같은 출구를 쓰면 PerSource를 인원만으로 정할 때 릴리스 주에 매트릭스 잡만 떨어지는 패턴이 자주 납니다.

신뢰할 수 있는 CI 출구 CIDR을 알면 전역 기본값보다 앞에 Match Address로 관대한 PerSource를 두어 보안 감사에서도 「의도된 예외」로 설명하기 쉽습니다. 반대로 전역만 넓히고 소스 제한이 없으면 단일 IP의 미인증 핸드셰이크로 CPU와 로그 파이프가 압박받습니다. 본문은 그 균형을 숫자와 절차로 고정하는 것을 목표로 합니다.

임대 클라우드 Mac에서 MaxStartups를 문서화해야 할 팀

하나의 공인 IPv4로 사람과 자동화가 함께 쓰는 빌드 호스트라면 승인 상한은 운영 자산이 되어야 합니다. 목표가 없으면 공격자의 병렬 비밀번호 시도로 CPU가 포화되거나, 플랫폼 엔지니어가 PerSource를 지나치게 낮춰 회사 NAT 뒤 GitHub Actions만 조용히 실패합니다.

• 외주 비중이 큰 iOS 조직: 릴리스 주에 ssh, scp, rsync가 동시에 돕니다.
• SecOps 검토: 연결 홍수에서 공정성을 어떻게 증명할지——스로틀 설정과 로그가 내러티브를 뒷받침합니다.
• FinOps: 미인증 핸드셰이크가 쌓이면 인증 실패 후에도 steal time이 치솟습니다.

Wi-Fi 탓하기 전에 MaxStartups를 의심할 증상

1. 근무 시간대 무작위 「원격 호스트가 연결을 닫음」: RTT는 안정적인데 새 TCP만 버려지는 전형적 패턴입니다.
2. 부하 스파이크: 인증된 세션은 적은데 sshd가 상위——핸드셰이크 폭풍이 CPU를 태웁니다.
3. CI 깜빡임: 같은 출구 IP의 잡만 실패하고 노트북 사용자는 성공——PerSource 추정 부족일 수 있습니다.
4. 감사의 「병렬 SSH 상한은?」: 컴플라이언스는 감이 아니라 숫자를 원합니다.

지시문 비교: 각 손잡이가 무엇을 제한하는가

지시문	제한 대상	흔한 실수	잘 맞는 조합
MaxStartups	전역 미인증 SSH 연결(핸드셰이크 대기열)	전역 최대만 두고 IP별 공정성 누락	PerSourceMaxStartups와 방화벽 속도 제한
PerSourceMaxStartups	한 클라이언트 IP의 병렬 핸드셰이크	사무실 NAT 기본값을 CI 버스트에 그대로 적용	신뢰 CIDR은 Match로 별도 상한
MaxSessions	TCP 연결당 다중화 세션	모든 클라이언트 총 세션과 혼동	내부 위키에 ControlMaster 정책 명시
MaxAuthTries	연결당 비밀번호 시도	분산 스프레이까지 막을 것으로 기대	키 전용 정책과 SIEM 중앙 로그

소규모 공유 리스를 위한 예시 기준(법률 자문 아님)

표는 10~25명 규모 엔지니어와 경량 CI를 가정합니다. 반드시 자사 히스토그램으로 검증하세요.

프로필	MaxStartups	PerSourceMaxStartups	MaxSessions	요약
인간만	10:30:60	8	10	VPN 재연결 핸드셰이크 버스트 완화
인간+CI NAT	20:50:200	32	20	매트릭스 러너 허용, 단일 IP 홍수에는 페널티
고보안	5:15:40	4	6	오탐 증가——바스천과 병행

MacLogin 클라우드 Mac용 9단계

1. 스냅샷:/etc/ssh/sshd_config와 sshd_config.d/*.conf를 설정 저장소에 복사, 티켓 SSH-THROTTLE-2026.
2. 측정:근무일 15분마다 ps -ax | grep sshd | wc -l 샘플.
3. Match 초안:CI 출구 CIDR을 알면 전역 기본보다 앞에 Match Address로 관대한 PerSource 배치.
4. 편집:MaxStartups/PerSourceMaxStartups/MaxSessions 조정, 이전 값은 감사용 주석으로 유지.
5. 구문:sudo sshd -t 종료 코드 0.
6. 카나리아:리로드 중 예비 인증 세션 1개 유지——단일 창만 믿지 마세요.
7. 리로드:공지된 창에서 sudo launchctl kickstart -k system/com.openssh.sshd.
8. 소킹:노트북과 CI 두 IP에서 각 20병렬 연결, TCP 핸드셰이크가 3초 넘게 멈추지 않는지 확인.
9. 종료:전후 스탠자, UTC 타임스탬프, 저장 tarball을 가리키는 원라인 롤백 첨부.

단순 PerSource 상한을 깨는 CI·바스첨·NAT

GitHub 호스트 러너 IP는 자주 바뀌지만 기업 NAT 뒤 셀프호스트는 50개 병렬 잡도 대외적으로는 한 주소로 보일 수 있습니다. 전역 MaxStartups를 엄격히 유지하려면 자동화 전용 바스첨에 별도 Match를 두거나 MacLogin 리스를 둘로 나눠 핸드셰이프 예산을 합산하세요.

엔지니어가 VNC로 GUI 디버깅을 해도 화면 공유는 sshd 승인 로그를 대체하지 않습니다——sshd 종료 사유는 SIEM에서 계속 파싱해야 합니다.

FAQ

고객 포털에 sshd 각 줄을 노출해야 하나요? IaC로 관리하고 고객에게는 지연·가용성 같은 결과 지표를 보여 주는 편이 현실적입니다.

WAF를 대체하나요?아니요. SSH 스로틀링은 데몬 층이고 WAF는 HTTP 프런트를 보호합니다.

재검토 주기는?분기마다, 또는 외주 증원이 30%를 넘은 직후.

MaxStartups를 낮추면 브루트포스가 멈추나요?완화에는 도움이 되나 키·FW·fail2ban 유형 정책을 대체하지는 않습니다. MaxAuthTries와 승인된 잠금 정책과 함께 쓰세요.

PerSource가 너무 낮으면 CI는?같은 NAT의 매트릭스가 단일 소스로 보일 수 있습니다. 러너 서브넷 피크 동시 연결을 먼저 측정하세요.

sshd_config 위치는?대개 /etc/ssh/sshd_config와 /etc/ssh/sshd_config.d/. 리로드 전 sudo sshd -t, macOS에서는 launchctl 우선.

MacLogin에서 Mac mini M4로 스로틀 실험이 더 재현 가능한 이유

Apple Silicon Mac mini는 코어당 암호 핸드셰이크 성능이 예측 가능해 MaxStartups 실험 그래프가 x86 터보 변동에 덜 지저분합니다. 홍콩·도쿄·서울·싱가포르·미국 도시권에 걸친 MacLogin에서는 리스를 CI 출구에 가까운 리전에 두면 RTT 분산이 줄어, 실제 원인이 빡센 PerSource인데도 타임아웃을 WAN 탓으로 돌리는 오진을 줄입니다. 임대 모델이면 sshd 템플릿을 지역 간 복제하고 리로드 순서를 리허설하며, 핸드셰이크 상한이 「티켓이 있는 설계」였음을 감사에 보여 주기 쉽고 책상 아래 일회성 머신에 의존하지 않습니다.

공격적인 스로틀 검증용 격리가 필요하면 가격 페이지에서 노드를 추가하고 지표가 14일 연속 안정된 뒤 프로덕션 등급으로 승격하세요.