요약

  • SSH_MSG_CHANNEL_WINDOW_ADJUST는 SSH 채널에서 더 많은 바이트를 보낼 수 있는 권한을 부여할 뿐, 원격 명령이 그 바이트를 소비했거나 완료했다는 뜻이 아닙니다.
  • exec요청에 대한 응답, 선택적 exit status, close 핸드셰이크는 서로 다른 시점을 기술합니다. 그 어느 것도 애플리케이션의 영속적 결과를 조용히 대신해서는 안 됩니다.
  • 결과가 중대한 자동화에는 작업 식별자와 원격 사후조건을 조회할 수 있는 경로가 필요하며, 그래야 SSH 세션이 중단되더라도 무작정 재시도를 강요받지 않습니다.

하나의 초록 불 뒤에 숨은 네 가지 상태

원격 명령 소프트웨어는 흔히 하나의 답을 원합니다: 잘 됐는가? RFC 4254는 그보다 작은 질문들에 여러 답을 제공합니다. 채널이 열렸는가? 서버가exec요청을 수락했는가? 송신자가 채널에 더 많은 바이트를 넣어도 되는가? 원격 프로세스가 exit status를 보고했는가? 양쪽 피어가 채널 상태를 닫았는가?

이 관찰들은 서로 같은 관찰이 아니기 때문에 오히려 유용합니다. 요청은 수락된 뒤 실패할 수 있습니다. 프로세스가 아직 실행 중인 동안에도 입력은 이동할 수 있습니다. 프로세스는 작업을 다른 서비스에 넘긴 뒤 종료할 수 있습니다. 클라이언트가 마지막 메시지를 받기 전에 채널이 사라질 수 있습니다. 이 모든 것을 하나의 불리언으로 압축하면 계층화된 프로토콜이 우연히 만들어진 비즈니스 트랜잭션 시스템으로 변합니다.

더 안전한 모델은 네 개의 분리된 상태를 둡니다: 요청 수용, 채널 흐름 크레딧, 프로세스 종료, 영속적 애플리케이션 결과. 앞의 셋은 SSH를 통해 관찰할 수 있습니다. 네 번째는 조작 대상인 프로그램이나 서비스의 몫입니다.

채널 윈도우가 실제로 부여하는 것

RFC 4254의 5.2절은 윈도우를 바이트 단위로 정의합니다. 윈도우는 상대방이 대기 전에 보낼 수 있는 채널 데이터의 양을 제한합니다.SSH_MSG_CHANNEL_WINDOW_ADJUST는 수신자 채널 번호와 더할 바이트 수를 전달합니다. 이 메시지가 도착하면 피어는 이전 허용량보다 그만큼 더 보낼 수 있습니다. 일반 데이터와 표준 오류 같은 확장 데이터는 동일한 윈도우를 소비합니다.

이것은 흐름 제어 계약입니다. 그 어휘는 권한, 수량, 채널입니다. 이 메시지에는 명령 식별자, 애플리케이션 상태, 영속성 표식, 결과 다이제스트가 없습니다. 명세는 또한 하나의 내부 버퍼링 이벤트가 윈도우 조정에 앞서야 한다고 요구하지 않습니다. 구현은 윈도우 관리를 자체 메모리 및 스케줄링 설계에 연결할 수 있습니다.

따라서 피어가 추가 채널 트래픽에 대비하고 있다고 추론하는 것은 합리적입니다. 그러나 특정 바이트가 SSH 스택, 운영체제, 호출된 프로세스, 그리고 그 프로세스가 호출할 수 있는 시스템 사이의 모든 경계를 통과했다고 추론하는 것은 합리적이지 않습니다. 윈도우는 송신자가 합의된 채널 용량을 초과하지 않도록 막을 뿐입니다. 확인 장부가 아닙니다.

수용은 완료가 아니다

RFC 4254는 채널별 요청을 위한 별도의 메커니즘을 마련합니다. 요청은want reply를 설정할 수 있고, 그러면 수신자가 채널 성공, 채널 실패 또는 요청별 연속 응답으로 답합니다.exec의 경우 요청은 서버에 제공된 명령의 실행을 시작해 달라고 청하는 것이며, RFC는 응답을 요청하고 확인할 것을 권고합니다.

그 응답이 중요합니다. 이 응답은 시작 요청을 수락한 서버와 그것을 거부했거나 지원하지 않는 서버를 구분합니다. 그러나 명령은 이제 막 자신의 수명 주기에 들어선 것입니다. 채널 성공에는 명령의 이후 exit code나 애플리케이션이 만들 수 있는 영속적 객체가 담겨 있지 않습니다.

이 구분은 “ready”, “sent”, “success” 같은 콜백을 프로토콜 계층을 보이지 않은 채 노출하는 라이브러리에서 잃기 쉽습니다. 이름은 결론적인 것처럼 들리면서 실제로는 요청 수용만을 기술할 수 있습니다. 운영자는 그 이벤트가 실제로 무엇을 증명하는지, 그리고 세션과 명령을 묶는 식별자가 무엇인지 기록해야 합니다.

Exit status는 더 강한 증거—그러나 여전히 한계가 있다

RFC 4254는 반대쪽 명령이 종료된 이후 시점을 위한exit-status메시지를 제공합니다. 이를 반환하는 것은 권고사항이지 의무가 아닙니다. 그 메시지에 대한 확인 응답은 전송되지 않으며, 클라이언트는 이를 무시할 수 있습니다. 명세는 0이 보통 성공적인 종료를 의미한다고 말합니다.

따라서 exit status는 채널 흐름보다 강한 증거입니다. 바이트 예산이 아니라 명령 수명 주기에서 나오는 것이기 때문입니다. “요청된 변경을 완료한 뒤 0으로 종료한다”는 계약을 가진 전형적인 동기식 프로그램이라면, 이것이 옳은 결과 신호일 수 있습니다.

그러나 “보통”이라는 표현과 애플리케이션 계약은 여전히 중요합니다. 래퍼는 작업을 큐에 넣은 뒤 0을 반환할 수 있습니다. 서비스 관리자는 건강 상태가 회복되기 전에 재시작 요청을 수락할 수 있습니다. 배포 명령은 컨트롤 플레인을 갱신하고 레플리카 수렴은 나중에 일어날 수 있습니다. SSH는 프로세스 결과를 올바르게 전달합니다. 실행되는 프로그램의 의미론을 만들어 낼 수는 없습니다.

Close는 채널 상태를 끝내지, 모호함을 끝내지 않는다

EOF와 close도 의도적으로 좁습니다. EOF는 한쪽이 더 이상 데이터를 보내지 않겠다는 뜻이며, 명시적 응답이 없고 반대 방향을 닫지도 않습니다. 어느 쪽이든 EOF를 먼저 보내거나 받지 않고 close를 보낼 수 있습니다. 한쪽은 close를 보내고 받은 뒤에야 채널이 닫혔다고 간주하며, 이전 데이터는 가능하면 목적지에 전달되어야 합니다.

이것은 질서 있는 자원 수명 주기 관리입니다. 모든 이전 바이트가 애플리케이션 효과를 일으켰다는 보장이 아니며, 마지막 메시지가 없다고 해서 효과가 일어나지 않았다는 증명도 아닙니다. 잘못된 순간의 네트워크 단절은 전형적인 불확실한 결과를 남길 수 있습니다: 원격 프로그램은 변경을 커밋했지만 클라이언트는 그 증거를 결코 받지 못했습니다.

최악의 대응은 불확실성을 자동 실패로 변환하고, 반복이 안전한지 알지 못한 채 명령을 다시 실행하는 것입니다.

보안 보장은 결과 보장이 되지 않는다

RFC 4254를 둘러싼 아키텍처가 이 분리를 강화합니다. RFC 4251은 SSH를 전송, 사용자 인증, 연결 프로토콜로 나눕니다. RFC 4253은 암호화, 서버 인증, 무결성으로 전송을 보호합니다. RFC 4252는 클라이언트 측 사용자를 인증합니다. 연결 프로토콜은 이 기반 위에 논리적 채널을 멀티플렉싱합니다.

이 성질들은 결정적인 질문에 답합니다: 반대쪽 끝은 어떤 호스트인가, 어떤 사용자가 인증되었는가, 데이터가 전송 중 보호되었는가. 그러나 패키지 설치가 사후조건에 도달했는가, 데이터베이스 마이그레이션이 커밋되었는가, 원격 API가 위임된 요청을 수락했는가에는 답하지 않습니다. 강한 인증은 증거를 귀속 가능하게 만듭니다. 증거가 말하는 범위를 넓히지는 않습니다.

작업에 세션 밖의 수명을 부여하라

돌이킬 수 없거나 비용이 큰 작업의 경우, 애플리케이션 수준의 작업은 SSH 연결보다 오래 사는 식별자를 가져야 합니다. 원격 측은 인증된 주체, 대상, 명령 또는 요청 지문, 수용 시각, 현재 상태, 최종 결과, 그리고 영속적 객체 ID를 기록할 수 있습니다. 호출자는 재접속 후 그 기록을 조회할 경로가 필요합니다.

이것이 새로운 SSH 확장일 필요는 없습니다. 명령줄 계약이면 충분합니다: 멱등성 키를 제출하고, 작업 ID를 받고, 애플리케이션이 종단 상태에 도달할 때까지 그 ID를 조회합니다. 단순한 로컬 명령은 확인된 exit status 이상을 필요로 하지 않을 수 있습니다. 더 강한 패턴은 반복된 작업이 자금 이동을 복제하거나, 자격 증명을 두 번 교체하거나, 플릿을 중단시키거나, 두 개의 자원을 만들 수 있는 곳에 속합니다.

지배적 규칙은 소박합니다: 각 신호를 제 이름으로 부르십시오. 윈도우 조정은 바이트 크레딧입니다. 요청 성공은 수용입니다. exit status는 프로세스 증거입니다. 채널 close는 연결 계층의 종결입니다. 비즈니스 완료는 비즈니스 작업이 제공해야 합니다.

출처