SSH와 TELNET을 사용하면 네트워크로 연결된 원격 컴퓨터에 연결하여 마치 컴퓨터 앞에 앉아 있는 것처럼 사용할 수 있습니다. 그렇다면 이 두 가지 유서 깊은 프로토콜의 차이점은 무엇이며 TELNET을 통해 SSH를 사용하는 것이 항상 이점이 있습니까?
TELNET 및 SSH: 기원 이야기
필요는 발명의 어머니입니다. 시스템 관리자는 물리적으로 다른 곳에 있는 컴퓨터에 액세스하고 관리할 수 있는 방법이 필요했습니다. 관리자가 컴퓨터 앞에 위치하는 것이 비실용적이거나 불편한 경우 원격 컴퓨터에 액세스하여 마치 해당 컴퓨터에 명령을 입력하는 것처럼 명령을 실행할 수 있는 방법이 필요했습니다.
TELNET, 줄임말 전화에타이핑하다 그물작업 프로토콜은 그 문제에 대한 해답으로 1969년에 개발되었습니다. 원격 컴퓨터가 네트워크에 액세스할 수 있는 한 관리자 또는 기타 권한이 있는 사람은 원격 키보드의 키를 물리적으로 누르는 것처럼 원격 컴퓨터에 연결하여 사용할 수 있습니다.
SSH는 1995년에 Telnet 및 기타 유사한 솔루션에 대한 직접적인 응답으로 만들어졌습니다. 이번에 필요한 것은 보안이었습니다. 그 시대의 TELNET, rlogin, FTP 및 기타 프로토콜은 보안에 대한 고려나 필요성 인식 없이 설계되었습니다.
SSH는 에스안전한 쉿보안이 처음부터 기본 원칙이었다는 것을 알 수 있습니다. 요즘 SSH는 TELNET을 거의 완전히 대체했습니다.
TELNET은 일반 텍스트 보안 악몽입니다
TELNET의 큰 문제는 일반 텍스트를 사용한다는 것입니다. 사용자 이름과 암호를 포함하여 트래픽을 암호화하지 않습니다. 네트워크를 따라 전송하는 모든 내용은 패킷 스니핑으로 캡처하고 가장 쉽게 읽을 수 있습니다. 유일한 사용자가 아닌 이상 로컬 네트워크에서도 보안 위험이 있습니다. 모든 사용자는 TELNET 트래픽을 가로채서 권한이 없는 로그인 자격 증명을 얻을 수 있습니다.
원격 컴퓨터가 오프 사이트에 있고 인터넷을 통해 연결해야 하는 경우 문제는 헤아릴 수 없을 정도로 확대됩니다. TELNET은 그 시대의 산물이었고 그들에게 공평하게 말하면 저자는 거의 확실하게 사람들이 50년이 지난 후 오늘날의 매우 다른 IT 환경에서 그것을 잘 사용할 것이라고 기대하지 않았습니다.
TELNET은 우리가 오늘날 있는 곳으로 집합적으로 도움을 준 중요한 프로그램 목록에 들어갈 자격이 있지만 오늘날의 세계에서 여전히 사용해야 하는 것은 아닙니다.
SSH는 TELNET과 어떻게 다른가요?
겉으로 보기에 TELNET과 SSH는 동일한 문제에 대한 두 가지 해답입니다. 둘 다 원격 컴퓨터의 터미널 창에 액세스하고 명령을 내릴 수 있게 해줍니다. 그러나 SSH는 TELNET보다 훨씬 늦게 개발되었기 때문에 문제가 더 철저하게 이해되었고 답이 더 잘 설계되었습니다.
TELNET은 다음과 같이 설계되었습니다. 사적인 네트워크를 염두에 두고 있지만 SSH는 공공의 데이터를 전송하고 원격 연결을 할 때 개인 정보 보호 및 보안을 유지해야 할 필요성.
TELNET은 포트 23을 사용하며 해당 포트 번호는 변경할 수 없습니다. 기본적으로 SSH는 포트 22를 사용하지만 이를 구성하고 변경할 수 있습니다. 명확하지 않은 포트 번호를 사용하도록 SSH를 구성하면 공격자가 SSH 포트를 식별하기가 더 어려워집니다. SSH 포트를 식별할 수 있는 경우 자동화된 소프트웨어를 통해 데이터 유출에서 수집한 수천 개의 암호를 차례로 시도하는 무차별 대입 공격을 수행하는 것은 사소한 문제입니다.
더 좋은 점은 SSH는 암호를 완전히 생략할 수 있다는 것입니다. 공개 키 암호화를 사용하여 원격 컴퓨터에 인증할 수 있습니다. 암호는 원격 컴퓨터로 보낼 필요가 없기 때문에 전혀 전송되지 않습니다. 데이터 암호화 및 SSH 키 인증은 SSH가 인터넷과 같은 안전하지 않은 네트워크를 통해 보안 연결 및 통신을 제공할 수 있음을 의미합니다.
실제로 SSH는 SSH 서버를 실행하는 원격 컴퓨터뿐만 아니라 다른 서비스로 인증하는 데 사용할 수 있습니다. 예를 들어 암호 대신 SSH를 사용하여 GitHub, GitLab 및 BitBucket 호스팅 Git 리포지토리에 액세스할 수 있습니다.
TELNET을 통한 SSH 사용의 또 다른 이점은 SSH가 역방향 SSH 터널링을 수행할 수 있다는 것입니다. 이를 위해서는 서버가 클라이언트 컴퓨터와 연결을 설정해야 합니다. 로컬 사용자가 서버에 연결하기 전까지는 연결이 무시됩니다.
클라이언트가 서버에 연결하려는 경우 사용자는 자신의 컴퓨터에 SSH 연결을 설정합니다. SSH는 이미 설정된 연결을 통해 서버로 연결을 보냅니다. 이것은 서버에서 클라이언트로의 이미 암호화된 연결 내부에 개인 터널을 제공합니다.
TELNET의 유일한 장점은 더 적은 대역폭을 사용한다는 것입니다. 그러나 지금은 대역폭이 부족한 1969년이 아니며 SSH도 정확하게 대역폭을 잡아먹는 것은 아닙니다.
SSH에도 문제가 있습니다.
SSH는 보안 측면에서 TELNET을 능가하지만 여전히 소프트웨어이며 소프트웨어에 버그가 있을 수 있음을 기억해야 합니다. 이러한 버그는 사이버 범죄자가 악용할 수 있는 취약점으로 이어질 수 있습니다. 또한 암호화 표준 및 알고리즘은 시간이 지남에 따라 변경되고 대체됩니다. 모든 암호화 기반 소프트웨어와 마찬가지로 이전 버전의 SSH는 노후화됨에 따라 보안 수준이 낮아질 수 있습니다. 그렇기 때문에 최신 SSH 릴리스를 사용하고 있는지 확인하는 것이 중요합니다.
대부분의 Linux 컴퓨터에서 사용되는 SSH 버전은 OpenSSL 도구 키트 및 라이브러리를 기반으로 하는 SSH 구현인 OpenSSH입니다. 2012년에 OpenSSL 라이브러리는 실수로 공격자가 SSL 서버에서 응답을 요청하고 응답에 포함할 데이터의 양을 지정할 수 있는 버그를 도입했습니다.
실제 응답에 64바이트 이상이 필요하지 않은 경우 64KB의 응답을 요청할 수 있습니다. 해당 데이터의 첫 번째 바이트 시퀀스는 예상되는 실제 응답이고, 그 다음에는 OpenSSL에서 최근에 사용한 메모리에 있었던 모든 것이 뒤따릅니다. 해당 데이터에 포함된 것은 행운이었지만 세션 쿠키 및 암호와 같은 민감한 정보 또는 공격자가 개인 키를 획득할 수 있는 기타 정보를 포함할 수 있습니다.
2014년에 발견된 취약점은 Heartbleed로 알려졌습니다. 소프트웨어에서 빠르게 수정되었습니다. 그러나 취약점은 그 시점에서 사라지지 않습니다. 이 취약점은 취약한 소프트웨어를 실행하는 모든 컴퓨터에 고정 버전이 설치된 경우에만 완전히 무효화됩니다. 다시 말해, 컴퓨터가 패치. 많은 관리자가 반응이 느렸기 때문에 고정 소프트웨어의 활용도 느렸습니다.
또한 우려되는 점은 버그가 도입된 2012년부터 버그가 발견되어 해결된 2014년 사이의 2년입니다. 그 2년 동안 취약한 버전의 OpenSSL을 실행하는 모든 SSH 서버가 위험에 노출되었습니다.
공정하게 말하면, 그것은 거의 10년 전에 일어났고 그 이후로 많은 릴리스, 개선, 버그 수정 및 코드 검토가 있었습니다.
관련된: SSH 서버를 보호하는 가장 좋은 방법
SSH 또는 TELNET을 사용해야 합니까?
오늘날 TELNET을 사용해야 하는 이유를 생각하기는 어렵습니다. 그것은 TELNET을 사용하는 것이 안전한 시나리오가 있다고 말하는 것과는 다릅니다. 외부 세계에 연결되지 않은 자체 포함 네트워크에서 아무도 트래픽을 패킷 스니핑하지 않을 것이라고 확신하면 TELNET을 사용할 수 있습니다. 하지만 그럴 이유가 없습니다. 보안 절충은 정당화될 수 없습니다.
SSH는 보다 안전하고 유연합니다. 이것이 TELNET을 통해 SSH를 사용하는 이점입니다. OpenSSH 구현은 상업용을 포함한 모든 용도에 대해 무료이며 널리 사용되는 모든 운영 체제에서 사용할 수 있습니다.
관련된: Windows, macOS 또는 Linux에서 SSH 서버에 연결하는 방법
