SRE/Linux Basics

리눅스 원격 접속([Telnet, Putty, OpenSSH, XRDP)

게임이 더 좋아 2022. 12. 3. 22:36
반응형
728x170

 

리눅스는 거의 모든 서버 컴퓨터에 쓰이는 OS로 다른 클라이언트에서 접속이 필요할 때가 있다.

간략하게 알아보자

 


먼저 텔넷에 대해서 알아보자

 

텔넷같은 경우는

현재는 보안 이슈로 인해서 거의 쓰지 않는다고 한다.

하지만 보안 기능을 더해서 텔넷을 쓰는 경우는 여전히 있다고 하고 기본적인 원격 접속 방법이다.

 

리눅스에서 텔넷 서버를 설치해서 사용한다.

리눅스 서버에 접속할 PC도 텔넷이 있어야 한다. 

하지만 대부분의 OS에서 텔넷을 기본적으로 가지고 있기 때문에 거의 문제가 없다.

이것이 필요한 이유는.. 원격접속을 위해서다.

다시 말해서 서버 컴퓨터를 사용하기 위함이라고 할 수 있다.

 

윈도우에서도 리눅스 서버 컴퓨터를 연결할 수 있는데 이는 다 텔넷이 깔려있기 때문이다.

 

 


다음은 PuTTY에 대해서 알아보자

텔넷과 거의 같다. 정확하게 말하면 텔넷의 기능을 쓸 수 있고 GUI가 있다.

그냥 텔넷으로 연결방식을 바꾸면 똑같다.

 


다음은 OpenSSH이다.

텔넷과 기능의 거의 같으며 다만 보안이 추가된 버전이라고 볼 수 있다.

서버와 클라이언트 사이의 데이터 송수신에서 암호화가 없어서 보안이 취약한 것인데 openssh를 사용하면 데이터 송수신 작업에서 암호화되는 과정이 추가되어 통신이 된다.

 

**일반적으로는 보안을 강화한 텔넷보다 SSH 서버를 훨씬 많이 이용한다.

 

음...? 위에 보니까 푸티에도 SSH가 있는데???

맞다.

푸티에서도 SSH로 통신이 가능하다.

 

**SSH 원리에 대해서 간략하게 알고 넘어가자

 

4. SSH 작동 원리의 핵심

SSH의 핵심은 'Key' 이다.

SSH는 키를 기반으로 통신한다고 해도 과언이 아니다.

클라이언트와 서버는 각각의 키를 보유하고 있으며,

이 키를 이용해 연결 상대를 인증하고 안전하게 데이터를 주고 받는다.

키를 생성하는 방식에는 아래의 두 가지가 있다.

[1] 비대칭키 (= 공개키, 개인키) : 접속 시도 시 클라이언트와 서버가 서로를 알아보기 위해 사용

[2] 대칭키 : 접속이 허용된 상태에서 정보를 안전하게 주고 받기 위해 사용

 

 

SSH 프로토콜은 클라이언트-서버 모델로 동작하며 대칭키 방식, 비대칭키 방식, 해시 알고리즘을 사용하여 인증 및 암호화를 수행한다.

대칭키 방식은 클라이언트-서버 간 전체 연결을 암호화에 사용되며,

비대칭키 방식은 키 교환, 클라이언트 인증, 서버 인증에 사용되고,

해시 알고리즘은 패킷의 무결성을 확인하기 위해 사용된다. (HMAC : Hash based Message Authenticated Codes)

 

 

1. 클라이언트는 서버에 원격 접속하기 위해 연결을 설정하는 프로세스를 시작한다.

 

SSH 프로토콜은 기본적(Default)으로 TCP 22번 포트를 사용하여 통신한다.

클라이언트가 서버에 원격 접속하기 위해 서버의 TCP 22번 포트로 SSH 접속 요청을 보내는 것이 SSH 연결의 첫 단계이다.

서버는 클라이언트에게 서버가 지원하는 프로토콜의 버전을 응답으로 보내준다.

클라이언트는 서버가 지원하는 프로토콜의 버전 중 자신과 일치하는 것이 있다면 연결을 지속한다. (버전 교환)

 

 

2. 서버는 자신의 공개키를 클라이언트에게 전송한다.

 

서버는 클라이언트로부터 SSH 접속 요청을 받고 자신의 공개키를 클라이언트에게 전송하고 클라이언트는 서버로부터 받은 공개키를 로컬에 저장한다.

클라이언트는 원격 접속하는 서버들의 공개키를 로컬 사용자 홈 디렉터리의 .ssh 경로 내의 known_hosts 파일에 저장하고 있다.

※ 클라이언트 사용자의 known_hosts 경로(Default)

<Linux>
일반계정  : /home/USER/.ssh/known_hosts
root 계정 : /root/.ssh/known_hosts		

<Window>
사용자    : %USERNAME%\.ssh\known_hosts

 

 

 

3. 클라이언트와 서버는 여러 Parameter들을 주고 받으며 보안 채널을 확립한다.

 

3.1 올바른 서버인지 확인(클라이언트 관점) 

 

클라이언트는 SSH로 원격 접속하려고 하는 서버가 올바른 서버인지 확인할 필요가 있다.

이를 위해 클라이언트는 known_hosts 파일에 존재하는 서버의 공개키를 통해 정상적인 서버인지 확인하는 작업을 수행한다.

확인 단계는 다음과 같다.

  1. 클라이언트에서 난수 생성, 난수 해시값 생성 및 저장
  2. 난수를 서버의 공개키로 암호화 후 서버에 전송
  3. 서버에서 서버의 개인키로 데이터를 복호화하여 난수 추출
  4. 서버에서 복호화된 난수 해시값을 생성 후 클라이언트에게 전송
  5. 클라이언트에 저장된 난수 해시값과 서버에서 받은 난수 해시값을 비교
  6. 동일할 시 올바른 서버 확인

 

3.2 암호화된 통신을 위한 세션키 생성(대칭키 생성)

 

세션키는 대칭키로 전체 세션을 암호화하는데 사용되며 모든 통신을 암호화 한다.

대칭키는 비대칭키에 비해 빠르고 컴퓨팅 파워가 더 적게 든다는 장점을 가지고 있다.

그러나 대칭키가 유출되었을 경우 공격자가 암호화된 모든 통신을 복호화할 수 있는 치명적인 문제점을 가지고 있다.

이를 해결하기 위해 클라이언트와 서버는 키 교환 알고리즘을 통해 안전하게 대칭키를 공유한다.

 

SSH에서 사용하는 대표적인 환 알고리즘인 디피-헬만(Diffie-Hellman : DH) 알고리즘은 상대방의 공개키와 나의 개인키를 통해 대칭키를 얻어는 방법이다.

이 단계에서 클라이언트와 서버는 임시 비대칭키 방식의 키 쌍을 생성하하고 공개 키를 교환한다.

DH를 통해 클라이언트와 서버는 대칭키인 세션키를 공유하게 되고 이후 모든 통신은 세션키를 통해 암호화된다.

 

[주의] 대칭키 교환에 사용되는 키 쌍은 서버와 클라이언트 인증에 사용되는 SSH 키 쌍과 다름

 

SSH가 DH를 통해 얻은 대칭키는 개별 세션에 대해 생성되며 더 이상 필요하지 않은 즉시 사라진다. 

따라서 클라이언트나 서버의 개인키가 유출되어도 이전 세션키를 통해 수행한 통신 내용을 복호화할 수 없다.

이는 TLS 세션에서도 사용되는 구성으로 인증서에 만료 날짜가 있는 경우 개인키는 중간자 공격으로 인해 유출되어도 인증서가 만료되었을 시 사용할 수 없으므로 만료 후에는 강한 보안 유지를 하지 않아도 된다.

 

※ RSA를 통해 세션키를 암호화 했을 시에는 개인키가 유출되면 세션키를 복호화하고 전체 통신을 읽을 수 있다.

   

암호화 방식이 정해지고 난 후에는 전송되는 메시지에 MAC(Message Authentication Code)가 포함되어 있어야 상대방이 패킷의 무결성을 확인할 수 있다.

MAC은 패킷의 마지막 부분에 위치하여 세션키로 암호화된 영역 바깥에서 전송되며, 일반적으로 데이터를 먼저 암호화하고 MAC을 계산하는 방법을 권장한다.

MAC은 공유 세션키와 메시지의 패킷 시퀀스 번호 및 실제 메시지 내용으로부터 계산되고 데이터의 무결성 및 통신 인증 확인 목적으로 사용된다.

 

 

3.3 서버에 접근할 수 있는 클라이언트인지 확인(서버 관점)

 

서버 또한 자신에게 접속하려는 클라이언트가 자신에게 접근할 수 있는 권한이 있는지 확인하는 단계가 필요하다.

 

가장 간단한 방법으로 패스워드 인증이 있다.

서버는 단순히 로그인하려는 계정의 암호를 묻고 클라이언트가 입력한 비밀번호는 세션키를 통해 암호화되고 전송되어 외부로부터 안전하게 보호된다.

패스워드가 암호화되지만 패스워드의 복잡성 설정의 한계가 있기 때문에 일반적으로 이 방법을 사용하지 않는 것이 좋다.

자동화된 스크립트를 통해 일반적인 길이의 패스워드는 공격에 의해 해제될 수 있다.

 

가장 많이 사용되고 권장되는 방법은 SSH 키 쌍을 사용하는 것이다.

이 방법을 사용하기 위해서는 클라이언트 측에서도 SSH 키 쌍을 생성해야 한다.

SSH 키 쌍을 통한 클라이언트 인증은 앞서 살펴본 올바를 서버인지 확인하는 과정과 비슷하다.

  1. 클라이언트는 인증할 키 쌍의 ID를 서버에 전송
  2. 서버는 클라이언트가 접속하고자 하는 계정의 .ssh/authorized_keys 파일을 확인
  3. ID에 매칭되는 공개키가 있을 시, 서버는 난수를 생성하고 클라이언트의 공개키로 암호화
  4. 서버는 클라이언트에게 암호화된 메시지 전송
  5. 클라이언트의 개인키를 통해 암호화된 메시지를 복호화하여 난수 추출
  6. 클라이언트는 난수를 세션키와 결합하여 해시값 계산 후 서버 전송
  7. 서버는 저장된 난수와 세션키를 결합하여 해시값 계산 후 비교
  8. 일치할 시 클라이언트 인증

이와 같이 비대칭키를 이용하여 클라이언트가 개인키를 가지고 있는 정상적인 클라이언트라고 증명할 수 있다.

 

 

4. 클라이언트가 서버에 원격 접속을 할 수 있다.

 

이제 세션키를 통해 클라이언트와 서버는 안전한 네트워크 통신을 수행할 수 있다.

 

더 자세히 나누자면

https://velog.io/@lehdqlsl/SSH-%EA%B3%B5%EA%B0%9C%ED%82%A4-%EC%95%94%ED%98%B8%ED%99%94-%EB%B0%A9%EC%8B%9D-%EC%A0%91%EC%86%8D-%EC%9B%90%EB%A6%AC-i7rrv4de

 

 

 


 

XRDP는 왜 나왔을까?

SSH 로 접속이 가능한 것은 알았는데... 혹시 터미널환경이 아니라 X 윈도같은 환경에서도 작업을 할 수 있나..?

즉, CLI 가 아니라 GUI 가 가능한가..? 라는 것이다.

 

실제로 위에서 말한 텔넷, SSH 서버로 작업은 가능하지만 X 윈도 환경을 지원하지는 않는다.

때문에 이 작업을 위해서는 XRDP라는 것이 필요하다.

 

다시 말해서 XRDP를 이용하면 X 윈도 환경에서 원격으로 작업이 가능하다.

 

컴퓨터를 원격으로 접속해봤다는 사람이라면

이것 많이 봤을 것이다.

 

얘는 RDC이다. Remote Desktop Connection 이다.

=> 얘로도 XRDP가 포함되어 있기에 접속할 수 있다.

 

X 윈도에서는 XRDP를 이용해서 원격접속하는 것 뿐이다.

**물론 XRDP가 클라이언트, 서버 둘다 설치되어있어야 한다.

 

 

사실 푸티는 어플리케이션일 뿐

서버 종류는 3가지를 봤다.

Telnet, SSH, XRDP

정리하자면 이렇다.

나라면.. 텔넷은.. 방화벽이 충분히 깔린 상태에서 간단하게 사용할 때 사용할 것이다.

나머지는 SSH로 쓰면 되겠다.

다만 우리가 재택근무를 하게 된다면.. XRDP를 사용하는 것이 좋겠다.

 

실무에서는 일반적으로는 SSH로 서버를 접속해 관리하는 것이고

필요한 경우에만 XRDP 서비스를 활성화하여 접속할 수 있게 한다.

서버를 구축하는데는 아래와 같이 골라서 구축하면 되겠다.

 

 

 

728x90
반응형
그리드형

'SRE > Linux Basics' 카테고리의 다른 글

FTP  (0) 2022.12.03
SSH  (0) 2022.12.03
PackageManager  (0) 2022.12.03
tar  (0) 2022.12.02
grep(작성 중)  (0) 2022.12.02