반응형
SSH
목표
SSH와 ssh key관리, 로직 대해 이해하고 직접 사용해봄.
SSH란?
SSH는 Secure Shell Protocol의 약자로 원격지 host에 접속하기 위해 사용되는 프로토콜임.
출시일은 1995년도임.
Telnet의 경우 암호화가 이루어지지 않아서 통신 중 정보를 탈취당할 위험이 높지만
ssh의 경우 telnet의 단점을 보완하여 암호화 기능을 지원함.
ssh는 암호화 가능을 사용하기 때문에 통신이 유출되더라도 데이터가 암호문으로 보임.
SSH 사용 용도
[원격지 제어]
원격지 host의 shell로 접속할 수 있기 때문에
기본적으로 CLI환경에서 작업을 진행할 수 있음.
예를 들자면 AWS와 같은 public cloud의 ec2에 접속해서 해당 instance에 명령을 내리는 것 등이 있음.
[데이터 전송]
예를 들자면 대표적으로 Github으로 코드를 push할 때
ssh 프로토콜을 사용함.
ssh 프로토콜을 사용하기 때문에 data를 보호하면서 push할 수 있음.
SSH default port
22
SSH Server, SSH Client
SSH 프로토콜을 통해 Client가 명령을 내리고
Server가 명령을 받아 host를 제어함.
Server : 접속 대상(remote 서버)
Client : Server에 접속하려고 하는 host
[SSH와 OS]
|
|
Linux
|
Windows
|
Mac
|
|
SSH Client
|
default로 ssh client가
설치되어 있음
|
Xshell, PuTTY
를 사용
|
default로 ssh client가
설치되어 있음
|
|
SSH Server
|
OpenSSH를
많이 사용함
|
일반적으로 Windows는 ssh로 제어하지 않음
|
OpenSSH가
default로 설치되어있음
|
SSH1과 SSH2 차이점
SSH 프로토콜은 SSH1과 SSH2 두 가지 버전이 있음.
현재는 SSH2가 default로 제공됨.
해당 두가지 version은 서로 호환되지 않음.
ex) ssh1 server , ss2 client 연결이 안됨. 반드시 ssh2 server, ssh2 client가 되야함.
왜 서로 호환이 안되고 update가 되었는지 version1, 2의 차이점을 알아보도록함.
SSH1 (Secure Shell 버전 1)
SSH version 1은 최초의 ssh version으로 1995 년에 만들어짐.
SSH-TRANS, SSH-USERAUTH, SSH-CONNECT라는 세 가지 주요 protocol로 구성되어있음.
Client와 Server연결 과정은 다음과 같음
[SSH client] - [TCP/IP] - [SSH-TRANS] - [SSH-USERAUTH] - [SSH-CONNECT] - [SSH Server]
[SSH-TRANS]
기본적으로 서버 인증, 기밀성 및 무결성을 제공하는 전송 계층 protocol.
[SSH-USERAUTH]
통신 구축시 사용자 인증에 사용되는 protocol
해당 protocol은 ssh server에서 ssh client를 인증함.
이 protocol은 SSH-TRANS 계층에서도 실행됩니다.
[SSH-CONNECT]
암호화 된 데이터를 일부 논리 스트림으로 다중화하는 연결 protocol.
이 protocol은 SSH-USERAUTH 프로토콜 위에서 실행됨.
ssh1 protocol에 대한 자세한 설명은 아래 링크에 있음
하지만 해당 SSH1에서 몇가지 취약점이 발견됨.
1. 암호화 된 데이터 스트림 중간에 무단 데이터 삽입이 가능하여 데이터 보안에 높은 위험을 초래할 수 있음.
2. 인증도 권한이 없는 사용자가 접근할 수 있는 치명적은 문제가 발견됨.
이러한 문제점을 해결하기 위해 SSH2가 udpate됨.
SSH2 (Secure Shell 버전 2)
SSH version 2는 2006 년에 update됨.
SSH1의 개선 사항이지만 SSH2는 SSH1과 호환되지 않음.
SSH2는 SSH1의 취약점을 해결하기 위해 더 많은 방어 메커니즘을 추가됨.
SSH1 차이점 SSH2
|
|
SSH2
|
SSH1
|
|
사용자 인증 방법
|
공개키 : DAS/RSA/OpenPGP
호스트 기반
Password
|
공개키 : RSA
호스트 RSA
Password
TLS
Kerberos
|
|
무결성 검사
|
강력한 암호화 무결성 검사
|
약한 CRC-32 무결성 검사
|
|
server key
|
Diffie-Hellman 키 계약을 사용하면 서버 키가 필요하지 않음.
|
세션 키의 순방향 보안에 사용되는 서버 키
|
|
공개 키 인증서 방식
|
지원
|
미지원
|
|
인증 형식
|
사용자 인증 교환은 보다 유연하며 액세스를 위해 여러 형식의 인증을 요구할 수 있음
|
세션당 정확히 하나의 인증 형식을 허용
|
|
세션 채널 수
|
무제한
|
연결당 정확히 하나의 세션 채녈
|
SSH 인증 방식
일반적으로 사용하는 SSH2의 인증 방식은
Password 방식, 공개키 인증 방식
2가지 방식이 지원됨.
Password 인증 방식
ssh client에서 ssh server로 원격 제어를 요청하는 할 때
Linux의 경우 ssh username@IPAddress 와 같은 명령어를 통해서
SSH 연결을 시작한 다음 Password 입력을 진행하는 방식이 있음.
또 windows의 경우 ssh client 프로그램인 putty 를 사용해서
ssh server에 원격 접속을 시도하면 아래 그림과 같이 id/password를 요구함.
이러한 인증 방식이 SSH의 Password 인증 방식에 해당함.
연결 시도 할 때 마다 id/password를 입력해줘야함.
User는 일반적으로 root로 진행됨.
하지만 설정에 따라 root 접속을 허용하지 않을 수 있음.
[Password 인증 방식의 단점]
비밀번호가 네트워크를 통해 교환된다는 치명적인 문제점을 가지고 있음.
그리고 Brute-force Attact(무차별 대입공격)에 의해서 뚫릴 수도 있는 취약점을 가지고 잇음.
공개키 인증 방식
SSH의 경우 일반적으로 사용하는 Password를 통한 접속이 아니라
공개키 인증 방식을 사용한 방식으로 접속을 함.
해당 방식을 사용하면 Password를 입력하지 않고 접속할 수 있음.
해당 방식을 추천하는 이유는 보안상으로 더 강력하기 때문임.
Password가 아무리 길거나 복잡하더라도 SSH 공개키가 제공하는 암호화 강도가 훨씬 강력함.
인증 방식 설정 방법
CentOS 7.5 환경을 기준으로 설명함.
[SSH 설정 파일 경로]
/etc/ssh/sshd_config
[인증 방식 설정]
PubkeyAuthentication yes = 공개키 인증 방식을 활성화 함. (주석 처리 시 default로 활성화 되어있음)
PasswordAuthentication yes = Password 인증 방식을 활성화 함. (주석 처리 시 default로 활성화 되어있음)
default 상태는 위 그림과 같이 PasswordAuthentication 설정이 활성화 되어있음
공개키 인증(PubkeyAuthentication)을 켜고
암호 기반 인증(PasswordAuthentication)을 끄면
공개키 방식으로만 인증하므로 훨씬 보안이 강화됨.
[ssh config 파일의 다양한 설정은 아래 링크 참고]
SSH 공개키 인증 방식
동작 원리
자세한 공개키 인증 방식 설명은 생략하겠음.
SSH Server : 접속 대상(remote 서버)
SSH Client : Server에 접속하려고 하는 host
1. SSH Client에서 Private Key, Public key를 생성
2. SSH Client에서 접속 하고자 하는 SSH Server에 생성했던 Public key를 전송함.
3. SSH Client에서 SSH Server로 SSH 접속시도
4. SSH Server는 256Bits 랜덤값 생성
5. SSH Server는 생성한 랜덤값으로 Hash값을 만들어서 저장하고 있음.
6. SSH Server는 생성한 랜덤값을 받았던 Public key로 암호화 함.
7. 암호화 된 data를 SSH Client로 전달함.
8. SSH Client는 암호화 된 data를 받아서 자신의 Private key로 복호화 함.
9. SSH Client는 복호화 한 data로 Hash값 생성.
10. Hash값을 SSH Server로 전달.
11. SSH Server는 이전에 만들어서 저장하고 있던 Hash값 비교.
12. SSH Server의 Hash값과 SSH Client가 전달해준 Hash 값이 일치하면 Channel이 형성되어 원격제어/데이터 전송 가능.
SSH key 생성 방법
OpenSSH를 사용하는 방법으로 진행
[test환경]
SSH Server : CentOS 7.5
SSH Client : CentOS 7.5
Private key, Public key 생성
[명령어]
ssh-keygen
예제에서는 모든항목을 enter로 넘어감.
[결과]
Private key : id_rsa
Public key : id_rsa.pub
[default 생성 경로]
생성되는 파일 경로를 입력하지 않으면
default로 계정의 ".ssh/" Directory에 생성됨.
파일 명은 id_rsa로 생성됨.
[passphrase]
passphrase는 Key를 암호화 시에 salt처럼 사용하는 값.
Prviate key가 노출되는 것을 대비할 수 있음.
Public key를 SSH Server로 전달하는 방법
[scp를 사용하는 방법]
scp [이동할 파일] [계정]@[IP]:[경로]
ex) scp id_rsa.pub root@10.0.2.4:~/temp/
(주의)
접속 하고자 하는 server의 root password를 알아야함
public key를 복사한 다음에는 SSH Server의
~/.ssh directory의 authorized_keys 파일 명으로 저장해줘야함.
~/.ssh 의 권한 설정은
chmod 700 ~./.ssh
chmod 600 ~./.ssh/authorized_keys
로 해줘야함
[ssh-copy-id를 사용하는 방법]
ssh-copy-id -i [public key] [ssh server ip]
ex) ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.2.4
public key를 복사하면
ssh server의 ~/.ssh/authorized_key 파일에
public key data가 추가됨.
(주의)
접속 하고자 하는 server의 root password를 알아야함
SSH Client에서 SSH Server로 접속해보기
password 입력없이 정상적으로 접속 가능.
참고
sshd_config 옵션 정리
ssh1, ssh2 차이점
ssh protocol
ssh인증 방식
ssh key 생성방법
반응형
'Tool 사용법 > SSH' 카테고리의 다른 글
| SSH authorized_keys 파일 설정 (0) | 2022.04.15 |
|---|---|
| HashiCorp Vault Container로 실행 (0) | 2022.04.07 |
| HashiCorp Vault를 이용한 SSH 공개키 인증 (0) | 2022.02.05 |
| AWS EC2 SSH (0) | 2022.01.27 |