SSH 설정

개요

시큐어 셸(Secure SHellSSH)은 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해 주는 응용 프로그램 또는 그 프로토콜을 가리킨다. 기존의 rshrlogin텔넷 등을 대체하기 위해 설계되었으며, 강력한 인증 방법 및 안전하지 못한 네트워크에서 안전하게 통신을 할 수 있는 기능을 제공한다. 기본적으로는 22번 포트를 사용한다.

SSH는 암호화 기법을 사용하기 때문에, 통신이 노출된다고 하더라도 이해할 수 없는 암호화된 문자로 보인다.

SSL 그리고 HTTPS 의 암호화 통신방식을 이용한 쉘이다.
비대칭키 암호화 알고리즘으로 대칭키를 암호화 하여 주고받은 뒤 대칭키로 암호화 된 메시지를 주고 받는 프로토골이다.

대부분의 리눅스 시스템에 기본으로 포함되어있고, 설치된다.
ssh 서버에 접속하기 위한 클라이언트는 대부분의 linux 배포본에는 기본적으로 포함되어있고, Windows Powershell에도 포함되어있다.




사용법

linux shell / powershell 모두
ssh 계정명@hostname_또는_IP 명령으로 다른 호스트에 연결할 수 있다.
대개의 경우 Windows 에서는 putty 라는 공개 툴을 많이 사용한다.

[haedong@openstack2:~]$ssh
usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-E log_file] [-e escape_char]
           [-F configfile] [-I pkcs11] [-i identity_file]
           [-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
           [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
           [user@]hostname [command]
 # 일반적인 연결방법
 # ssh account@server_HOSTNAME_or_server_IP
[haedong@openstack2:~]$ssh haedong@192.168.113.172
haedong@192.168.113.172's password:
Last login: Thu Dec 17 13:26:54 2020 from 192.168.4.199
[haedong@openstack2:~]$
 # 저장된 ssh key를 사용하는 경우
 # ssh account@server_HOSTNAME_or_server_IP -i KEY_FILE_NAME
[haedong@openstack2:~]$ssh root@192.168.113.171 -i ~/.ssh/id_rsa
Last login: Wed Dec 16 09:31:02 2020 from openstack3
[root@openstack1:~]#
 # 접속 로그 확인을 원할 경우
[haedong@openstack2:~]$ssh root@192.168.113.171 -i ~/.ssh/id_rsa -v
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 192.168.113.171 [192.168.113.171] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/haedong/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/haedong/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.113.171:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit                               > compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit                               > compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:mLoKmt/MNoY/Il1LahMDflXKfT/c                               KSpI80vbl2m5EFM
debug1: Host '192.168.113.171' is known and matches the ECDSA host key.
debug1: Found key in /etc/ssh/ssh_known_hosts:4
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi                               c,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)

debug1: Next authentication method: publickey
debug1: Trying private key: /home/haedong/.ssh/id_rsa
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.113.171 ([192.168.113.171]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = ko_KR.UTF-8
Last login: Thu Dec 17 13:38:57 2020 from openstack2
[root@openstack1:~]#



sshd (SSH daemon : a.k.a ssh server) 설정

기본적으로 ssh 데몬의 설정파일은 /etc/ssh/sshd_config
ssh 클라이언트 설정 파일은 /etc/ssh/ssh_config
파일이다. 보통은 windows클라이언트에서 linux 서버로 접속을 하는 경우가 많다보니 ssh_config 파일을 수정하는경우는 많지 않(은것 같)다.

자주 사용하거나, 중요한 옵션만 기억하자.

 # ssh 서버 설정을 위한 값. 주석처리가 되어있는 경우 기본값으로 설정된다.
#Port 22
#ListenAddress 0.0.0.0


 # root로 로그인을 허용할 것인지 설정. no로 설정하고 sudo을 이용하는 것을 권장한다.
#PermitRootLogin yes
PermitRootLogin no

 # 로그인을 시도하는 계정/.ssh/authorized_keys 파일을 의미한다.
 # 허용할 공개키를 저장하는 파일을 가리킨다.
AuthorizedKeysFile      .ssh/authorized_keys

 # 빈 패스워드 로그인을 허용할 것인지 설정한다. 당연히 no로 설정하는 것이 '옳다'
PermitEmptyPasswords no

 # password를 이용한 로그인을 허용할 것인지 설정한다.
PasswordAuthentication yes

 # GSSAPI 사용 여부
 # 간혹 폐쇄망에서 접속 지연(ID 입력 후 지연)이 발생하년 경우 no로 변경
# GSSAPI options
GSSAPIAuthentication no
GSSAPICleanupCredentials no

 # 역시 폐쇄망 혹은 DNS 연결이 안되는 환경에서 접속 지연이 발생화면 no로 변경
UseDNS no

서비스 구동 / 재시작 / 종료

 # 서비스 구동
 # service sshd start
[haedong@openstack2:~]$ sudo systemctl start sshd.service

 # 서비스 재시작
 # service sshd restart
[haedong@openstack2:~]$ sudo systemctl restart sshd.service

 # 서비스 구동
 # service sshd stop
[haedong@openstack2:~]$ sudo systemctl stop sshd.service

사실 service sshd stop 또는 systemctl stop sshd.service 명령은 평생 내릴 일 없는 명령일지도 모른다.

ssh 키 쌍을 이용한 로그인 설정

SSL 그리고 HTTPS 포스트에서 설명한 공개키를 미리 서버에 저장해 두고 인증하는 방식이다.
이해를 위해 개념적인 절차를 기재해보면(실제 절차와는 차이가 있음)
1. 사용자가 비대칭 키 쌍 K1(공개키), K2(비밀키)를 생성.
2. 서버에 K1 을 저장
3. 사용자가 서버에 접속 시도
4. 서버는 대칭키 KS 생성
5. K1로 KS를 암호화하여 KK 생성
6. KK를 사용자에게 전달
7. 사용자는 KK를 K2를 복호화하여 KS 획득
8. KS를 KS로 암호화하여 SS 생성
9. 서버로 SS 전송
10. 서버는 KS로 SS를 복호화 하여 KS 획득.
11. 서버가 가지고 있는 KS와 사용자가 전송한 KS가 같은지 비교
가 되겠다.

보통은 보안상의 이유로 ssh key를 이용한 로그인을 강제하지만 반대로 편리한 것도 있다. 모든 서버의 키를 하나로 통일하고 passphrase를 비워두면 패스워드 입력 없이 모든 서버에 접속이 가능해 진다.(당연히 보안상 지양해야 하는 행위다)

서버에서 키를 생성하고 등록하는 과정은 다음과 같다.

 # 키를 등록할 서버에 로그인
[haedong@openstack3:~]$ssh-keygen
Generating public/private rsa key pair.
 # 키쌍이 저장될 경로 기본값은 /home/계정명/.ssh/
Enter file in which to save the key (/home/haedong/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): 비워두거나 최소5자 이상의 암호구
Enter same passphrase again: 비워두거나 최소5자 이상의 암호구
Your identification has been saved in /home/haedong/.ssh/id_rsa.
Your public key has been saved in /home/haedong/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:+rZt72JUHSrIuqEeI07ey/5MQm1pYmFxFmBukuegj8s haedong@openstack3
The key's randomart image is:
+---[RSA 2048]----+
|    +.+.         |
|   + +        .  |
|  + *  . .   o . |
| . B o .o . o .  |
|.   = =.S  o     |
| o o +o.  .      |
|. + +.oo .       |
|.= +.*....+      |
|.Eoo*oo.o+.+o    |
+----[SHA256]-----+
[haedong@openstack3:~/.ssh]$ls -lah /home/haedong/.ssh/
합계 12K
drwx------. 2 haedong haedong   57 12월 17 14:33 .
drwx------. 3 haedong haedong   95 12월 16 09:30 ..
-rw-------. 1 haedong haedong 1.8K 12월 17 14:33 id_rsa
-rw-r--r--. 1 haedong haedong  400 12월 17 14:33 id_rsa.pub
-rw-r--r--. 1 haedong haedong  188 12월 16 09:30 known_hosts
[haedong@openstack3:~/.ssh]$ls -lah /home/haedong/
합계 16K
drwx------. 3 haedong haedong  95 12월 16 09:30 .
drwxr-xr-x. 3 root    root     21 12월 14 14:27 ..
-rw-------. 1 haedong haedong  31 12월 16 10:36 .bash_history
-rw-r--r--. 1 haedong haedong  18  4월  1  2020 .bash_logout
-rw-r--r--. 1 haedong haedong 193  4월  1  2020 .bash_profile
-rw-r--r--. 1 haedong haedong 231  4월  1  2020 .bashrc
drwx------. 2 haedong haedong  57 12월 17 14:33 .ssh
# 파일 권한ㅇ르 주목하자.
 # 공개키 등록
 # 다른 곳에서 만든 키를 넣어도 된다.
 # sshd_config 파일에 설정한 파일명과 일치해야 한다.
[haedong@openstack3:~/.ssh] cp ~/.ssh/id_rsa.pub    ~/.ssh/authorized_keys

 # 또는
[haedong@openstack3:~/.ssh] cat ~/.ssh/id_rsa.pub    >>  ~/.ssh/authorized_keys
 # >를 하나만 넣게 되면 authorized_key 파일의 내용을 모두 지운다음 id_rsa.pub의 내용이 들어가게 된다.
 # >>는 읽으려는 파일의 내용을 대상 파일의 맨 끝에 붙여넣는다.
 # .ssh 디렉토리는 700 
 # .ssh 디렉토리 아래 파일들은 600 권한이어야 한다.
 # 당연한 이야기지만 소유자는 해당 키를 사용할 계정이어야 한다.
[haedong@openstack3:~/.ssh]$chmod 600 ~/.ssh/*
[haedong@openstack3:~/.ssh]$ll ~/.ssh/
합계 16
-rw-------. 1 haedong haedong  400 12월 17 14:41 authorized_keys
-rw-------. 1 haedong haedong 1766 12월 17 14:33 id_rsa
-rw-------. 1 haedong haedong  400 12월 17 14:33 id_rsa.pub
-rw-------. 1 haedong haedong  188 12월 16 09:30 known_hosts

id_rsa 파일을 클라이언트에 저장한다.
다운로드 해도 되고, 내용을 복사한뒤 일반 텍스트 파일 형식으로 저장해도 된다.
앞서 설명한 것처럼 ” ssh account@hostname -i id_rsa ” 와 같이 키 파일을 지정해주면 된다.

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,C820352F5512D184F9C6887101DBE9F2

TFynB3AwsiFRoPUxJRg3Y9vv34lOsimQB3yNEyKMP2jvt5XbJFNT6Qw9BAD1xIkl
MfL27ADniRM73OgB+4E6OxzMgDXRE88Gor6CifWUZcASMPPOn55HrontgNE+fv7F
RL1TZ285IX73N/GDifAu9rchc3mIOL2i9D8t/TWUVMNjV+jL+jmSrWI70YlMArPE
I8qVUWc39SFn7NmQYuyo/7LBMNLdSBSMr4WpavM7WbbZAAcRZIYgT51gLWmgGEJv
LrCOcjdzHbSekxIp/8kejKj3ZbJZo6cwGsTKgT9RfLvamU38f21XeBp1bxXazuGF
jiqE9zZ4on69/nNzDRw9BKxuSbiO2rD4hwfSZyH0yJO0TUFaNPr2ejQ8uvbhVIxN
WNQ8+TNX84sm2Mjs8USN8UkAq9uzCLCBeKXJVbmrQAyGvIaU4Y8p9hXjwDgg4oKv
ohiW1VtoqMEigpgpRo2xF6Ft3E6O6yuuh48QauFVNwen2FPGLmRrx2ZkD5htBjjM
mgaZv/E2wP21EmEf6/3tmMOyR4mVxnn1Am4O6zMnOjCtA4OZxv2a2jWBSIZl7/SB
8Zu6yDaHycv0SLKBMtwm3cTXYwpD4StDgX7XBUv0tpyfYh/okT/YRVCx+HP723L+
FLSuwMs9bnvYvLqRbF2GBPJSUQSG1REyoxL//gSqBTdiUSYb2275vAVxYg72Oh28
MgH4tAGhTlk6rxp5ZMflFF0GeMQAoTqjfcs1n+LjFztLZY/L/nZfk6jQEZIbDyEA
IYrZ9zL4XQhsILI0RjCpYei//8rMtf3+w2QiyOFyIcKH0PDRDJegQyFUs5CWiOIX
0j+5ZOMr1igNHbotCR8JhGsPnm2XWx0rs5+nY/Y198Re9waebE7zCKHRjC2jbRnK
mM14mngyIVsaKkKlJz1OMkN1rEnHd6Hu0t52JRTDxI+DWed+ZbUsxpUsmPq9Y68l
jH7R7b5g0emb0sqcyMvjYOEbWD9hk7VBFuKL5CnLGraW4Ag+FcZSGg0DM5nL+Iwr
OHKslt6xFMHVRr7aSJxslw9zGGUb2LG0lBEp+SKLquCFevcv2rQp0Vzprb5UAzum
pVE/TYKXXVjeQA+rQlqefDY43HjJxWA+Oai8dLUNVMt/LuSge5D9mmwK3Nkkj98d
eVDZp1AKBw1vjom1w0LS4J9kKk8FJmUPjb/nb1nbkGYMc+QGQZGvOVYOmfb3bjbI
8M8EUHTs6Sg3WVPEALWZU99yqvemeVx1/A/gf3cqP/kuEYphFN7zRchMV9lXNs7m
pE1DtAYLcAEaLK5MZDgQ6Oo9jCVLlleiYXj3kBCijJ2zK0iXh08PsiggAoaYvlgk
l21oXTS1tPl1Cpe3QaIb98LMdTPZk+Qkbq4N+9YPQbRwBgiDF2ApXJQhSTdKmVES
B9E3mYCf5OqtiYw/V9xOKA7RB/RR2vCGxXAa1pem5ntzqPLYhBLaUZ2CShOOUPFh
/oL1exNCATeOgpSLypx0ZoHqU+TJLI9IhD15HlA6IAcZmyBp+jVMayTNYjvAmWgT
br8tBxaGuTyIVO00auUJQeud84Lq85pS0mGQMM7fORHsk9B4PuZT2zjkIpiGay30
-----END RSA PRIVATE KEY-----

putty 클라이언트를 사용하는 경우

puttygen 을 실행한 다음 아래 절차를 따라 키 포맷을 변경하고 putty에서 로드하면 된다.

SSL 그리고 HTTPS

SSL (Secure Socket Layer)

전송 계층 보안(영어: Transport Layer Security, TLS, 과거 명칭: 보안 소켓 레이어/Secure Sockets Layer, SSL)는 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. 그리고 ‘트랜스포트 레이어 보안’이라는 이름은 ‘보안 소켓 레이어’가 표준화 되면서 바뀐 이름이다. 이 규약은 인터넷 같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다. 이 규약은 웹 브라우징, 전자 메일, 인스턴트 메신저, voice-over-IP (VoIP) 같은 응용 부분에 적용되고 있다. 국제 인터넷 표준화 기구(IETF)에 의해 현재 구식(deprecate)으로 간주되어 있다. 최종 갱신은 RFC 5246이고, 최종 갱신 버전은 넷스케이프에서 만든 SSL 표준을 바탕으로 했다. 위키백과 발췌
용어 사용 시 SSL과 TLS를 구분해야 할 필요는 없다. 사실 TLS보다 SSL이 더 입에 잘 붙는다.

먼저 컴퓨터의 암호화에 대해 아주 쉽게 설명하면
컴퓨터는 0과 1만 존재한다 (on, off).
즉 컴퓨터는 숫자만 존재한다.
숫자 1,000이 있다고 가정하면 이 숫자 1,000이 아닌 것처럼 보이게 한다. = 암호화

예를 들어
1,000 X 100 = 10,000
1,000은 내가 암호화 하고 싶은 원본
곱하기는 ‘암호화 알고리즘’
100은 암호화를 위한 ‘키’ 가 되겠다.

여기에서 철수가 영희에게 금고의 비밀번호를 알려주는 상황을 적용해보자.
금고의 비밀번호는 1000이다.
비밀번호는 철수만 알고 있다.
주변에 사람이 많아서 비밀번호를 그냥 말하면 금고의 비밀번호가 노출된다.
보안을 위해 100이라는 숫자를 키로 하여 곱하기 알고리즘으로 암호화한다.
철수는 영희에게 ‘비밀번호는 10000이야. 곱하기 알고리즘으로 암호화 했어’ 라고 말한다.
여기까지가 기본적인 암호화,암호화 데이터 전송 순서가 되겠다.

하지만,
철수가 미리 영희에게 키를 알려줬다면 문제가 없겠지만 만약 영희는 아직 키를 모른다면?
의 경우에 대응하기 위해서 나온 기술이 바로 SSL 되시겠다. (엄밀히 말하면 좀.. 다르지만)

공개키 암호화와 비공개키 암호화 (=비대칭키 암호화와 대칭키 암호화)

개념상 두 종류의 자물쇠가 있다고 생각하면 편하고. 하나는 ‘잠그는 열쇠, 여는 열쇠가 따로 있는 자물쇠’ = A 다른 하나는 ‘잠글 때 열 때 같은 열쇠를 사용하는 자물쇠’ = B. SSL의 중요한 개념은 여기에 있다.

자물쇠 A : 소인수분해를 통해 소수(자기 자신과 1로만 나뉘어지는 수)를 찾아 내는 것이 쉽지 않다는 것에 기인하여 만들어진 알고리즘을 이용한다.11,2,3,5,7,11… 은 소수임을 금방 알아낼 수 있지만 10,000,000,000,000,001이 소수인지는 알아내기 쉽지 않다. 아직 특정한 수가 소수인지 아닌지 알아내는 방법은 없다(고한다. 난 산수 싫다. 어렵다.) 그래서 느리다(고 한다.)
잠그는 열쇠와, 여는 열쇠가 구분 되어있다. 열쇠 하나는 잠그는 것만 가능하고 하나는 여는 것만 가능하다.
잠글 때 쓰는 열쇠와 열 때 쓰는 열쇠가 다르다 = 비대칭 키
암호화,복호화 하는데 시간이 많이 걸린다.

자물쇠 B :열쇠 하나만 있으면 열고 잠그는 것이 가능하다.
잠글 때 쓰는 열쇠와 열 때 쓰는 열쇠가 같다 = 대칭 키
암호화, 복호화 하는데 시간이 덜 걸린다. (비대칭키 암호화 알고리즘에 비해)

위에서부터 순서대로 사건이 발생한다.
철수와 영희의 모든 대화는 가운데 도둑이 들을 수 있다.

위와 같은 절차로 Kk를 주고 받는 것이 ‘키 교환’ 알고리즘이 되겠다. (개념상으로 이렇다는 것만 이해하자. 실제 키를 주고 받는데엔 다양한 방법이 존재한다. DH, RSA 등이 포함되면 키를 교환하기 위한 수단이구나 생각하면 된다.)

HTTPS
언뜻 보면 완벽해 보이지만 여기에 큰 맹점이 하나 있다. 바로 도둑이 철수인 척 하여 중간에서 데이터를 가로채는 경우이다.
1. 철수에게서 받은 K1을 받는다.
2. K1#을 만들어 영희에게 전달한다
3. 영희는 K1#으로 Kk를 암호화 하여 도둑에게 전달한다.
4. 도둑은 K2#으로 복호화하여 Kk를 획득한다.
5. K1으로 Kk를 암호화 하여 철수에게 전달한다.
이후부터는 Kk로 암호화한 데이터가 오가므로 쉽게 복호화 할 수 있다.

즉, 철수와 영희는 실제 상대방이 누구인지 확인할 수 없다는 사실이다.
우리가 사용하는 SSL-HTTPS는 이를 보완하기 위한 제 3자 증명 과정이 추가된다.