TechCodeview

SSH: 보안 셸

SSH는 Secure Shell을 의미합니다. 보안 소켓 셸이라고도 합니다. 보안되지 않은 네트워크에서 네트워크 서비스를 안전하게 운영하기 위해 SSH(Secure Shell)라는 암호화 네트워크 프로토콜이 사용됩니다. 클라이언트 서버 아키텍처는 SSH 클라이언트 인스턴스를 SSH 서버와 연결하는 SSH 애플리케이션의 기초입니다.

Telnet과 Berkeley Remote Shell(rsh) 및 관련 rlogin 및 rexec 프로토콜과 같은 안전하지 않은 원격 Unix 쉘 프로토콜의 후속 제품인 SSH는 안전하지 않은 일반 텍스트 인증 토큰 통신을 사용하는 Unix 계열 운영 체제용으로 만들어졌습니다.

정의

SSH를 여러 가지 방법으로 적용할 수 있습니다. 가장 간단한 구현은 통신 채널과 네트워크 연결의 양쪽 끝에서 자동으로 생성된 공개-개인 키 쌍을 사용하여 데이터를 암호화합니다. 그런 다음 비밀번호를 사용하여 사용자를 인증합니다. 사용자가 공개-개인 키 쌍을 수동으로 생성하는 경우 키 쌍이 설정되면 인증이 가상으로 완료되므로 비밀번호 프롬프트 없이 즉시 세션을 시작할 수 있습니다.

마두리가 어서 오라고 했어

이 경우 소유자는 해당 개인 키를 비밀로 유지하고 공개 키는 소유자에게 액세스 권한을 부여해야 하는 모든 시스템에 설치됩니다. 개인 키는 인증의 기초 역할을 하지만 인증을 수행할 때 키는 네트워크를 통해 전송되지 않습니다. SSH는 공개 키 제공자가 해당 개인 키도 보유하고 있음을 확인합니다.

모든 버전의 SSH에서 알 수 없는 공개 키를 알려진 개인 키와 연결하는 것은 이를 ID가 있는 합법적인 공개 키로 받아들이기 전에 중요합니다. 유효성을 검사하지 않고 공격자로부터 공개 키를 수락하면 신뢰할 수 없는 공격자를 합법적인 사용자로 수락하게 됩니다.

창조

핀란드의 컴퓨터 과학자인 Tatu Ylönen은 1995년에 처음으로 SSH를 만들었습니다. 프로토콜 제품군의 추가 개발은 많은 개발자 그룹에서 이루어졌으며 다양한 구현 반복으로 이어졌습니다. 임베디드 시스템을 포함하여 널리 사용되는 모든 운영 체제에 사용할 수 있는 구현이 있습니다. OpenBSD 개발자가 1999년에 오픈 소스 소프트웨어로 제공한 OpenSSH는 가장 자주 사용되는 소프트웨어 스택입니다.

인증을 위한 OpenSSH 키 관리

승인된 공개 키 목록은 일반적으로 Unix 계열 시스템에서 원격 로그인 권한이 있는 사용자 홈 디렉터리의 ~/.ssh/authorized 키 파일에 보관됩니다. SSH는 소유자와 루트 이외의 다른 사람이 수정할 수 없는 경우에만 이 파일을 존중합니다. 원격 끝의 공개 키와 로컬 끝의 일치하는 개인 키가 모두 있으면 비밀번호가 더 이상 필요하지 않습니다. 그러나 훨씬 더 많은 보호를 위해 암호를 사용하여 개인 키를 잠글 수도 있습니다. 또한 일반적인 위치에서 비밀 코드를 검색할 수 있으며 명령줄 옵션을 사용하여 전체 경로를 제공할 수 있습니다(ssh의 경우 -i 옵션).

SSH는 자동화된 키 생성으로 암호화된 비밀번호 기반 인증을 추가로 제공합니다. 이 시나리오의 공격자는 신뢰할 수 있는 서버 측을 가장하여 암호를 요청하고 이를 얻을 수 있습니다(중간자 공격). 서버 측에서는 비밀번호 인증을 끌 수 있습니다.

사용

SSH는 클라이언트-서버 패러다임을 사용합니다. 일반적으로 SSH는 로깅에 사용됩니다. 또한 TCP 포트를 터널링하고, X11 연결을 전달하고, 원격 시스템에서 명령을 실행할 수 있습니다. 일반적으로 원격 연결을 허용하는 SSH 데몬에 대한 연결은 SSH 클라이언트 애플리케이션을 사용하여 이루어집니다. 둘 다 macOS, Linux 배포판, OpenBSD, FreeBSD, NetBSD, Solaris 및 OpenVMS와 같은 대부분의 최신 운영 체제에서 흔히 발견됩니다. 일부 버전은 다양한 수준의 복잡성과 포괄성을 갖춘 독점, 프리웨어 및 오픈 소스입니다(예: PuTTY 및 Cygwin 및 OpenSSH에 포함된 OpenSSH 버전). 특히 SSH는 Windows 10 버전 1709까지 Windows 버전에 기본적으로 포함되지 않습니다.

유사한 파일 관리(동기화, 복사 및 원격 삭제) 기능은 PuTTY를 백엔드로 사용하는 무료 오픈 소스 Windows 애플리케이션 WinSCP에서 제공됩니다. 클라이언트 컴퓨터에 설치할 필요 없이 WinSCP 및 PuTTY는 USB 드라이브에서 직접 작동할 수 있도록 제공됩니다. Windows에서 SSH 서버를 설정하려면 설정 앱에서 기능을 활성화해야 하는 경우가 많습니다.

연결 문제를 처리하고 클라우드 기반 가상 머신을 인터넷에 직접 노출하는 데 따른 보안 위험을 방지하려면 클라우드 컴퓨팅에서 SSH가 매우 중요합니다. 방화벽을 통한 SSH 터널 가상 컴퓨터를 통해 인터넷을 통한 보안 연결이 가능합니다. 이 프로토콜의 경우 IANA는 TCP 포트 22, UDP 포트 22 및 SCTP 포트 22를 지정했습니다.

2001년 초에 IANA는 SSH 서버의 기본 TCP 포트 22를 잘 알려진 포트 중 하나로 분류했습니다. 연결 지향 전송 계층 프로토콜 SCTP는 TCP 대신 SSH를 실행하는 데 사용될 수 있습니다.

역사적 발전

반복 1

핀란드 헬싱키 공과대학의 연구원인 Tatu Ylönen은 자신의 기관 네트워크에 대한 비밀번호 스니핑 공격에 영감을 받아 1995년에 프로토콜(현재 SSH-1로 알려짐)의 초기 반복을 만들었습니다.

SSH는 rlogin, TELNET, FTP, rsh 등 강력한 인증과 비밀 보장이 부족한 이전 프로토콜의 역할을 수행하도록 설계되었습니다. Ylönen은 자신의 애플리케이션을 프리웨어로 제공했습니다. 1995년 7월에 이 장치는 급속히 인기를 얻었습니다. 1995년 말에는 50개국에 걸쳐 20,000명의 SSH 사용자가 있었습니다.

SSH를 홍보하고 발전시키기 위해 Ylönen은 1995년 12월 SSH Communications Security를 ​​설립했습니다. GNU libgmp를 포함한 다양한 무료 소프트웨어 구성 요소가 SSH 프로그램의 첫 번째 릴리스에서 활용되었지만 이후 SSH Communications Security에서 제공하는 반복은 점점 더 독점 소프트웨어로 성장했습니다. 추산에 따르면 2000년에는 사용자가 200만 명에 달했습니다.

반복 2

IETF(Internet Engineering Task Force)는 공식 문서에서 SSH 프로토콜 버전 2를 생성하는 작업 그룹을 'Secsh'로 지정했습니다.

향상된 프로토콜 반복인 SSH-2는 2006년에 표준이 되었습니다. SSH-1은 이 버전과 호환되지 않습니다. SSH-2는 SSH-1에 비해 기능 및 보안 업그레이드를 제공합니다. 예를 들어, Diffie-Hellman 키 교환과 메시지 인증 코드를 통한 강력한 무결성 확인은 더 높은 보안을 제공합니다. 단일 SSH 연결을 통해 무제한의 셸 세션을 운영할 수 있는 기능은 SSH-2의 새로운 기능 중 하나입니다. SSH-2는 SSH-1보다 더 발전되고 널리 사용되기 때문에 libssh(v0.8.0+), Lsh 및 Dropbear와 같은 특정 구현에서는 SSH-2만 지원합니다.

반복 1.99

RFC 4253에서는 2.0 및 이전 버전을 지원하는 SSH 서버가 버전 2.1이 개발된 후인 2006년 1월에 프로토콜 버전을 1.99로 표시해야 한다고 요구했습니다. 이 버전 번호는 이전 소프트웨어 개정판을 나타내기보다는 이전 버전과의 호환성을 나타내는 데 사용됩니다.

퀵소트

OSSH 및 OpenSSH

원래 SSH 프로그램의 마지막 버전인 버전 1.2.12가 1999년에 오픈 소스 라이선스로 배포된 이후 개발자들은 무료 소프트웨어 버전을 개발해 왔습니다. 이는 Björn Grönvall의 OSSH 프로그램의 기초로 사용되었습니다. 얼마 지나지 않아 OpenBSD 팀은 Grönvall의 작업을 복제하여 OpenBSD 릴리스 2.6에 포함된 OpenSSH를 생성했습니다. OpenSSH를 다른 운영 체제로 전송하기 위해 이 버전에서 '이식성' 분기를 만들었습니다.

2005년 현재 가장 널리 사용되는 SSH 구현은 많은 운영 체제 배포판의 기본 버전인 OpenSSH였습니다. OpenSSH 7.6 릴리스의 코드베이스에서 SSH-1 지원을 제거한 후에도 OpenSSH는 계속 업데이트되고 있으며 SSH-2 프로토콜을 지원합니다. 한편 OSSH는 더 이상 관련이 없습니다.

용도

SSH를 통해 X11 프로그램을 터널링하는 예로 사용자 'josh'는 로컬 컴퓨터 'foo Fighter'에서 원격 컴퓨터 'tengwar'로 'SSHed'하여 xeyes를 실행했습니다. 사람들은 Windows SSH 클라이언트 PuTTY를 사용하여 OpenWrt에 액세스합니다.

SSH는 Microsoft Windows 및 대부분의 Unix 변형(Linux, Apple의 macOS를 포함한 BSD 및 Solaris)을 포함한 많은 시스템에서 작동하는 프로토콜입니다. 다음 앱에는 특정 SSH 클라이언트 또는 서버에만 사용되거나 호환되는 기능이 필요할 수 있습니다. 예를 들어, 현재 OpenSSH 서버와 SSH 프로토콜의 클라이언트 구현을 사용하여 VPN을 구성하는 것만 가능합니다.

• 원격 호스트의 쉘에 액세스하려면(Telnet 및 rlogin 대체)
• 원격 호스트에서 단독 명령을 수행하는 경우(rsh 대체)
• 원격 서버의 자동(비밀번호 없는) 로그인 구성(예: OpenSSH 사용)
• 완전한 기능을 갖춘 암호화된 VPN으로서 OpenSSH 클라이언트와 서버만이 이 기능을 지원한다는 점을 명심하세요.
• 먼 호스트에서 X를 전송하는 경우(여러 중간 호스트를 통해 가능)
• 암호화된 프록시 연결을 통해 인터넷을 탐색하기 위해 SOCKS 프로토콜을 지원하는 SSH 클라이언트를 사용합니다.
• SSHFS를 사용하는 로컬 시스템의 파일 시스템으로 원격 서버의 디렉토리를 안전하게 마운트합니다.
• 자동 원격 서버 모니터링 및 관리를 위해 위에 언급된 하나 이상의 기술을 통해.
• SSH 호환 모바일 또는 임베디드 장치 개발용.
• 파일 전송 메커니즘을 보호합니다.

파일 전송 방법

여러 파일 전송 시스템은 다음과 같은 Secure Shell 프로토콜을 사용합니다.

문자열 json객체

• SSH를 통해 SCP(Secure Copy)가 RCP 프로토콜에서 개발되었습니다.
• SCP보다 효과적일 것으로 예상되는 rsync는 SSH 연결을 통해 작동되는 경우가 많습니다.
• 안전한 FTP의 대안은 SSH 파일 전송 프로토콜(SFTP)입니다(FTP over SSH 또는 FTPS와 혼동하지 마십시오).
• FISH, 즉 쉘 프로토콜을 통해 전송된 파일은 1998년에 도입되었으며 Unix 쉘 지침을 통한 SSH에서 개발되었습니다.
• FASP(Fast and Secure Protocol)라고도 알려진 Aspera는 명령과 데이터 전송, UDP 포트에 SSH를 사용합니다.

건축학

SSH 프로토콜의 계층화된 아키텍처를 구성하는 세 가지 고유한 구성 요소는 다음과 같습니다.

• TCP/IP의 TCP(전송 제어 프로토콜)는 일반적으로 전송 계층(RFC 4253)에서 사용되며 포트 번호 22는 서버 수신 포트로 따로 설정되어 있습니다. 이 계층은 암호화, 압축, 무결성 검사, 초기 키 교환 및 서버 인증을 구현합니다. 각 구현에서는 더 많은 기능을 허용할 수 있지만 각각 최대 32,768바이트의 일반 텍스트 패킷을 전송 및 수신하기 위한 인터페이스를 상위 계층에 노출합니다. 일반적으로 1GB의 데이터가 전송된 후 또는 1시간이 지난 후(둘 중 먼저 도래하는 시점) 전송 계층에서 키 재교환을 준비합니다.
  
• 클라이언트 인증은 여러 인증 기술을 제공하는 사용자 인증 계층(RFC 4252)을 통해 처리됩니다. 클라이언트 기반 인증은 서버가 아닌 SSH 클라이언트가 사용자에게 비밀번호를 요청할 수 있음을 의미합니다. 클라이언트의 인증 요청만 서버로부터 응답을 받습니다. 다음과 같은 사용자 인증 기술이 자주 사용됩니다.
  비밀번호, 비밀번호 수정 기능을 포함하는 간단한 비밀번호 인증 기술입니다. 모든 소프트웨어가 이 기술을 사용하는 것은 아닙니다.
• 일반적으로 최소한 DSA, ECDSA 또는 RSA 키 쌍을 지원합니다. 공개 키 공개키 기반 인증 기술이다. 다른 구현에서는 X.509 인증서를 추가로 허용합니다.
키보드 상호작용(RFC 4256)은 서버가 정보 입력을 위한 하나 이상의 프롬프트를 제공하고 클라이언트가 이를 표시한 다음 클라이언트가 입력한 답변을 다시 보내는 유연한 기술입니다. 일부 OpenSSH 설정에서 PAM 시 비밀번호 인증을 효과적으로 제공하기 위해 사용됩니다. 간단한 비밀번호 인증 기술만 지원하는 클라이언트로의 로그인을 때때로 방해할 수 있는 기본 호스트 인증 공급자입니다.
• SSH 세션에 대한 Single Sign-On 기능은 다음을 통해 제공됩니다. GSSAPI Kerberos 5 또는 NTLM과 같은 외부 메커니즘을 사용하여 SSH 인증을 처리할 수 있는 확장 가능한 시스템을 제공하는 인증 기술입니다. OpenSSH에는 기능적인 GSSAPI 구현이 있지만 상용 SSH 구현에서는 회사에서 사용하기 위해 이러한 기술을 통합하는 경우가 많습니다.
• 제공되는 SSH 서비스를 정의하는 채널의 개념은 연결 계층(RFC 4254)에 의해 정의됩니다. 단일 연결에서 여러 SSH 연결을 다중화할 수 있습니다. 둘 다 양방향으로 데이터를 전송합니다. 채널 요청은 서버 측 프로세스의 종료 코드 또는 터미널 창의 크기 변경과 같은 특정 채널에 대한 대역 외 데이터를 전송합니다. 또한 수신 창 크기를 사용하여 각 채널이 해당 흐름을 제어합니다. SSH 클라이언트는 서버 측 포트를 전달하기 위해 전역 요청을 수행합니다. 일반적인 채널 유형은 다음과 같습니다.
  • SFTP용 셸, exec 및 터미널 셸(SCP 전송 포함)
  • 클라이언트에서 서버로 전달되는 연결을 위한 Direct-TCPIP입니다.
  • 전달된 tcpip를 사용하여 서버에서 클라이언트로 전달된 연결
  • 호스트의 적법성을 확인하기 위해 SSHFP DNS 레코드(RFC 4255)는 공개 호스트 키 지문을 제공합니다.

개방형 설계로 인해 쉘 보안 외에도 다양한 작업에 SSH를 사용할 수 있으므로 다양성이 뛰어납니다.

취약점

SSH-1

이 프로토콜 버전에서 CRC-32가 제공하는 부적절한 데이터 무결성 보호로 인해 SSH 1.5의 취약점은 1998년에 암호화된 SSH 스트림에 자료의 무단 삽입을 허용하는 것으로 확인되었습니다. 대부분의 구현에서는 SSH Compensation Attack Detector라는 패치를 추가했습니다. 이러한 수정된 구현 중 일부에는 새로운 정수 오버플로 결함이 포함되어 있어 공격자가 루트 또는 SSH 데몬의 기능을 사용하여 임의 코드를 실행할 수 있습니다.

공격자가 IDEA 암호화 세션의 마지막 블록을 변경할 수 있는 결함이 2001년 1월에 발견되었습니다. 악성 서버가 클라이언트 로그인을 다른 서버에 전달할 수 있는 또 다른 결함이 같은 달에 발견되었습니다.

본질적인 취약점으로 인해 SSH-1은 일반적으로 오래된 것으로 간주되며 SSH-1 대체를 명시적으로 제거하여 피해야 합니다. 대부분의 최신 서버와 클라이언트는 SSH-2를 지원합니다.

CBC에 대한 일반 텍스트 복구

당시의 표준 암호화 방법인 CBC를 사용하여 암호화된 암호문 블록에서 최대 32비트의 일반 텍스트를 검색할 수 있는 이론적 취약점이 2008년 11월 모든 SSH 버전에서 발견되었습니다. 가장 간단한 해결 방법은 CTR, 카운터로 전환하는 것입니다. CBC 모드 대신 SSH를 공격으로부터 면역시키는 모드입니다.

NSA가 암호 해독을 의심함

Edward Snowden이 2014년 12월 28일 Der Spiegel에 민감한 문서를 공개한 것은 국가 안보국(National Security Agency)이 특정 SSH 통신을 잠재적으로 해독할 수 있음을 의미합니다.