Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
USSH — USTPS 위에서 재구현된 SSH | Kitploit
도구/GitHubGitHub/x1colegal/ussh
Encryption/Decryption ToolsNetwork SecurityCryptographyUtilities & FrameworksAuthenticationRemote Access Tool
GitHubx1colegal/ussh

USSH

USTPS 위에서 재구현된 SSH

저장소 보기
31개월 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유

USSH

USSH는 USTP-Secure 기반으로 구축된 셸 프로토콜 및 클라이언트/서버 쌍입니다.

TCP 터널이 아니며 SSH를 TCP 내부에 감싸지 않습니다.

상태: Beta

라이선스: MIT

AEAD 암호 이름

  • chacha20 = CHACHA20_POLY1305
  • aes-256-gcm = AES_256_GCM
  • aes-128-gcm = AES_128_GCM
  • 기본 AEAD 암호: chacha20

기본 포트

  • 5322

서버

root@kitploit:~
python3 ussh_server.py \
  --peer-ip <CLIENT_IP_OR_DOMAIN> \
  --peer-port 0 \
  --bind-ip 0.0.0.0 \
  --bind-port 5322 \
  --cipher chacha20 \
  --congestion-control auto

--password를 생략하면 서버는 시작 시 USSH 로그인 비밀번호를 입력하라는 메시지를 표시합니다.

대화형 시작 시 서버는 스스로를 systemd 서비스로 설치할지 여부를 묻습니다. 정상적으로 실행하려면 n이라고 답하세요. 해당 질문을 건너뛰려면 --no-systemd-prompt를 사용하세요.

클라이언트

root@kitploit:~
python3 ussh_client.py \
  --peer-ip <SERVER_IP_OR_DOMAIN> \
  --peer-port 5322 \
  --bind-ip 0.0.0.0 \
  --bind-port 0 \
  --cipher chacha20 \
  --congestion-control off

클라이언트는 SSH처럼 비밀번호를 대화형으로 입력받습니다.

클라이언트는 처음 본 서버 X25519 공개 키를 ~/.ussh_known_hosts.json에 저장합니다. 나중에 해당 키가 변경되면 클라이언트는 새 키를 조용히 신뢰하는 대신 TOFU 불일치 오류와 함께 중단합니다. 서버 호스트 키를 의도적으로 교체한 경우, 대화형 확인 후 저장된 TOFU 키를 교체할 수 있도록 클라이언트를 --regen-key와 함께 실행하세요.

인터넷 드래프트

  • USSH 인터넷 드래프트: https://datatracker.ietf.org/doc/draft-x1co-ussh/

참고 사항

  • 전송 계층은 UDP 위의 USTP-Secure입니다.
  • USSH 내부에서 USTPS는 ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE: 같은 읽을 수 있는 ASCII 제어 라인과 이진 UPACK (UPAK) DATA 프레임을 사용합니다.
  • ACK 및 NACK는 디버깅을 위해 평문으로 유지되지만, 위조된 ACK/NACK 제어 공격을 방지하기 위해 세션별 HMAC 태그로 인증됩니다.
  • USSH는 UPACK DATA 페이로드당 900바이트라는 USTPS 전송 페이로드 상한을 상속합니다.
  • USSH는 USTPS 아래에 두 번째 단편화 계층을 정의하지 않습니다.
  • 전송 수준의 MTU, PMTU, nonce 동작, 중복 처리 및 오래된 패킷 처리는 USTPS에서 상속됩니다.
  • 자동 네트워크/경로 마이그레이션이 제거되었습니다.
  • 클라이언트가 네트워크를 변경하여 소스 IP:port가 변경되면 현재 USSH 세션은 종료될 것으로 예상되며 사용자는 깨끗하게 다시 연결해야 합니다.
  • 마이그레이션 구현은 실질적인 안정성 및 보안 문제를 일으켰기 때문에 제거되었습니다:
    • NAT 또는 모바일 네트워크가 경로를 빠르게 변경할 때 반복적인 마이그레이션 플러드
    • 복구된 것처럼 보이지만 터미널 데이터 전달을 중단한 세션
    • 클라이언트가 경로가 끊어졌음을 알아차리기 전의 긴 무음 기간
    • 실제 로밍 클라이언트와 기존 세션을 주장하는 스푸핑된 패킷 간의 모호성
    • 깨끗하게 다시 연결하는 대신 터미널을 멈추게 할 수 있는 복구 상태

전송 핸드셰이크

  • USSH는 USTP-Secure와 동일한 USTPS 재시도 토큰 핸드셰이크를 상속합니다.
  • 서버는 먼저 재시도 토큰과 세션 메타데이터로 클라이언트에 도전(challenge)합니다.
  • 클라이언트는 암호화된 USSH 세션이 수락되기 전에 해당 토큰을 다시 에코해야 합니다.
  • 동일한 핸드셰이크는 최종 AEAD 암호와 USTPS Congestion이 on인지 off인지도 협상합니다.
  • 재시도 토큰은 세션 생성 전의 도달 가능성 증명일 뿐입니다.
  • 세션 키도, 패킷 nonce도, 이후 파생되는 AEAD 세션 키의 대체물도 아닙니다.
도구 다운로드
  • 현재 동작은 의도적으로 더 단순합니다: 현재 IP:port에서 클라이언트를 검증하고, 세션을 해당 엔드포인트에 바인딩하고, 엔드포인트가 변경되면 다시 연결합니다.
  • USSH는 전송 계층에서 선택적 USTPS Congestion을 상속합니다.
  • 서버 측: --congestion-control auto|on|off
  • 클라이언트 측: --congestion-control on|off
  • 서버가 auto이면 USSH는 클라이언트 요청을 따릅니다. 서버가 on 또는 off이면 서버가 최종 모드를 강제합니다.
  • USTP-Secure 자체는 순서가 없는 상태로 유지됩니다.
  • USSH는 전송 계층을 TCP와 같은 순서 보장 채널로 만들지 않습니다.
  • USSH는 터미널에 쓰기 전에 논리적 stdout 바이트 스트림만 재조립합니다.
  • USSH는 PTY가 일관된 바이트 스트림 동작을 기대하는 셸 입력/출력 청크에 대해 애플리케이션 수준 순서도 유지할 수 있습니다.
  • 이러한 재조립이 존재하는 이유는 대화형 셸 출력이 연속적인 바이트 스트림이며, 터미널 바이트를 원시 도착 순서로 렌더링하면 ls, find 또는 컴파일러 로그와 같은 대용량 출력이 손상될 수 있기 때문입니다.
  • 즉, USTP-Secure는 여전히 전송 수준의 HOL(Head-of-Line) 블로킹을 피하면서, USSH는 터미널 렌더링에 필요한 애플리케이션 수준 순서만 복원합니다.
  • 페이로드는 패킷별로 AEAD로 암호화됩니다.
  • 정적 PSK는 사용되지 않습니다.
  • 각 클라이언트는 X25519를 통해 별도의 임시 AEAD 세션 키를 받습니다.
  • 비밀번호는 보안 세션이 수립된 후 USSH 인증에 사용됩니다.
  • 서버는 ussh_server.py를 실행하는 머신에서 실제 PTY 기반 셸을 실행합니다.
  • 클라이언트는 stdin 바이트를 보내고 stdout 바이트를 렌더링합니다.
  • 서버는 클라이언트당 하나의 셸/세션으로 여러 클라이언트를 지원합니다.
  • 서버에서 --cipher를 설정하면 서버는 해당 정확한 암호를 사용합니다.
  • --cipher를 생략하거나 auto로 설정하면 서버는 클라이언트가 요청한 암호를 사용합니다.
  • 클라이언트는 예기치 않은 암호 협상을 거부합니다.
  • 첫 연결 후 예기치 않은 서버 키 변경을 감지하기 위해 클라이언트에서 TOFU(Trust On First Use)가 활성화됩니다.
  • 서버는 기본적으로 ~/.ussh_host_key에 영구 X25519 호스트 키를 유지하므로 재연결과 재시작에도 TOFU가 안정적으로 유지됩니다.
  • 일반적인 서버 재시작은 호스트 키를 변경하지 않습니다.
  • 해당 호스트 키를 의도적으로 교체하려는 경우에만 서버에서 --regen-key를 사용하세요.
  • TOFU 항목은 <peer-ip-or-domain>:<peer-port> 단위로 저장되므로 다른 주소/포트의 다른 서버는 다른 호스트 ID로 취급됩니다.