5 posts tagged with "ssh"

AWS, Azure 등을 사용하면서 로그 확인중에 누군가가 지속적으로 SSH 로그인 시도를 하는 것을 확인했다. IP를 확인해보니 대부분은 중국이었는데 개중엔 네팔도 있더라. 다른 계정은 알기가 어려우니 당연한 거겠지만 항상 root 계정으로 로그인을 시도했는데 그냥 두어도 무슨 문제가 있겠냐 싶었지만 뒤돌아서면 찜찜한게 마음에 걸려서 아래의 방법을 사용해보기로 했다.

 

1. ACL 설정​

ACL에 특정 IP와 subnet을 등록해서 접근을 제어하는 방식을 일반적으로 많이 사용하는 것 같다. 원격지 또는 클라우드 환경에서 중요한 보안을 강화할 수 있는 간단하면서도 확실한 방법이라는 생각을 한다. 현재 사용하는 Azure에서는 설정이 매우 간단하다. 사실 복잡할 이유도 없다. 리스트에 넣기만 하면 되는거니까. Azure에서는 AWS와 달리 Endpoints 항목에서 열어놓을 port를 설정하는데 (AWS는 Security group 이라는 이름으로 관리한다) 현재 문제가 되는 서비스가 SSH라서 SSH에 대한 ACL만 설정했다.

위 그림처럼 모든 IP에 대해서는 접근을 거부하고 특정 subnet에 대해서만 허용하도록 했는데 subnet이 다른 환경에서 접근이 필요한경우 ACL에 추가 설정을 해야 하겠다는 생각이 들었다. 집이나 카페에서 접속하는 경우도 있고 때에 따라서는 테더링으로 연결하는 경우도 있는데, 또 나 혼자만 SSH로 접속할게 아니지 않는가. 이렇게 환경이 변경될 때마다 리스트를 추가하는건 귀찮은 일이 아닐 수 없다. 그래서 다른 방법을 생각해야만 했다.

 

2. VPN​

ACL에서 관리할 리스트를 최소로 줄이기 위해서는 Azure에 접근하는 경로를 최소한으로 줄이면 된다. 하지만 실제는 여러 경로이기 때문에 여러 경로를 최소한으로 줄일 수 있는 방법을 찾으면 되는 건데, 여러 방법이 있을 수 있지만 우선은 VPN을 구성해 보기로 했다. (RDP로 특정 서버에 접속해서 할 수도 있겠다는 생각을 하는데 VPN에 비해 상대적으로 귀찮을 것 같다) 구성하면 아래와 같은 그림이 된다.

난 VPN server를 구축하면 되고 SSH 접속이 필요한 사용자들은 VPN에 연결한 후 SSH를 사용하면 된다. VPN server의 IP에 대해서만 접근을 허용하도록 ACL에 subnet을 추가하면 불편함도 좀 덜고 동시에 SSH 로그인 시도는 막을 수 있다.

 

3. VPN 구성​

공유기에도 VPN server 기능을 할 수 있는게 있다는 것 같은데 불행히도 가지고 있는 공유기들은 지원하지 않았다. 그래서 그냥 ubuntu 12.04에 설정하기로 했는데 2가지 방법을 시도해봤다. 많이 사용한다는 OpenVPN을 (이름도 마음에 든다) 우선 적용해봤는데 설정이 약간 복잡하고 몇가지 문제가 있었다. 가장 큰 걸림돌 중 하나가 OS X이나 Windows에 기본으로 사용 가능한 VPN 연결 기능에서 프로토콜을 지원하지 않는 것이었다. 별도의 client tool을 사용해야만 하는 것 같은데 VPN 연결마저도 귀찮을 수 있는데 따로 툴을 설치해야 한다는건 더 귀찮을 것 같았다. 그래서 pptpd를 사용하기로 했다. Ubuntu에 사용되는 pptpd는 OpenVPN에 비해 설정도 상대적으로 간단했다. 설정했던 내용은

(1) apt-get으로 pptpd 설치

(2) VPN에 연결하는 client에 분배할 IP 대역 설정 (/etc/pptpd.conf)

(3) 네임서버 설정 (/etc/ppp/pptpd-options)

(4) VPN 계정 및 허용 IP 설정 (/etc/ppp/chap-secrets)

(5) IP forwarding 설정 (/etc/sysctl.conf)

(6) iptables masquerade 설정

 

VPN 구성하다보니 네트웍 부분에 대해 더 깊게 알아야겠다는 생각이 든다.

처음 자동화 업무를 시작하면서부터 ssh를 본격적으로 사용하기 시작했다.

그 당시에도 ssh가 제대로 지원되지 않는 환경인 경우 (거의 임베디드 리눅스 환경) 제대로 지원될 수 있도록 기능이나 기타 필요한 내용들을 관련 개발부서에 요청하곤 했었다. ssh를 사용하면 할수록 자동화에 필수적이라는 생각이 드는 이유는

1. 매우 간단하다

어차피 command의 형태로 되어있고 형식이 간단하고 linux와 os x의 경우 기본으로 포함되어 있기 때문에 특별히 뭘 구현하지 않아도 된다.

2. 인증여부를 묻지 않게 할 수 있다

간단하게 장비간 key만 교환하고 등록하면 인증시 계정의 패스워드가 아니라 key의 패스워드를 묻게 되는데 key 생성시 패스워드 없이 생성이 가능하기 때문에 인증여부를 묻지 않는 것처럼 보일 수 있다. 장비에 대한 제어를 자동으로 해야 하는데 인증여부 등을 묻거나 하면 해결하기가 어렵다. 물론 제어 가능하도록 무언가를 구현해서 사용해도 된다. 하지만 구석에 박혀있는 작은 기능이 필요할 때 이전에 구현된 거대한 덩어리들을 수정하지 않아도 되니 꽤 유용하다.

3. 권한만 있다면 해당 OS의 거의 모든 기능을 사용할 수 있다

ssh도 shell 이므로 shell에서 할 수 있는 기능들은 거의 사용 가능하다. 단 한번에 수행되어야 하는 작업이 많은 경우 문제가 생기기도 하고 command가 복잡해져서 나의 경우엔 복잡한 작업을 수행하는 script를 하나 따로 만들어서 ssh로는 그 작업을 하는 script만 호출하는 식으로 처리하곤 한다.

4. 파일 전송이 간단하다

ssh와 시리즈로 사용하는 scp로 파일 전송을 하곤 하는데, ftp를 별도로 서비스하거나 mount 같은 걸 하지 않아도 되니 아쉬울 때 쓰기 좋다.

 

하지만 ssh로 도배를 해보니 몇가지 아쉬운 점이 있었는데

1. 귀찮은 키교환

자동화에 사용하는 장비 수가 늘어날수록 키를 서로 교환하고 등록하는 과정이 무척 귀찮아진다. 이 과정 마저도 어느정도 자동화를 할 수도 있지만 신규 장비에 접속해서 키는 생성해야 하니 짜증스럽다. 예를 들어 한번에 장비가 10대만 늘었다고 하더라도 반복작업이 수십회는 된다. 장비간 키교환이 귀찮아 아예 키를 통째로 전송해서 같은 키를 사용하기도 하는데 이 경우 보안문제도 신경쓰인다.

2. 늘어나는 script

ssh가 간편하기도 하고 간단한 기능을 쉽게 땜질하는게 가능하지만 땜질이 늘어날수록 script가 늘어나게 된다. 한 번은 script가 수십개가 되었던 적도 있었는데 아무리 작명을 잘해도 어떤게 어떤건지 내용을 열어보거나 실행해봐야 아는 상태에 이르렀다. 게다가 특정 장비간 기능이 달랐기 때문에 script도 퍼져있어서 관리하기가 쉽지 않았다.

3. Known host 문제

장비의 IP가 변경되는 경우 서로 키를 교환하고 있는 상태이기 때문에 인증에는 문제가 없다고 하더라도 변경된 IP로 접속한 기록이 없기 때문에 최초 접속시 known host로 등록할거냐고 묻는다. 이게 자동화에 방해가 되므로 IP 변경시 한번씩은 접속을 해주거나 known host로 등록을 해줘야 하는 번거로움이 발생한다. 물론 sshd 설정에 아예 known host 여부를 따지지 않게 하는 부분이 있긴 하지만 자동화 이외의 다른 용도로 사용되거나 하면 그런 설정을 하기가 꺼려진다.

 

그래서 적합한 방안이라고 생각하는 것들은 이렇다.

1. Script의 공용화

Script는 가능한 적게 만드는게 좋을 것 같다. 그리고 여러 장비에서 사용해야 하는 script 라면 script는 장비 하나에만 두고 공통으로 사용할 수 있는 방안을 마련하는게 좋을 것 같다. 처음엔 한 곳에 script를 두고 필요할 때 마다 다른 장비에 복사해서 호출하게 하곤 했었는데 영 지저분하고 특정 상황에서는 script를 복사하면 안되는 경우도 있어서, 아예 script가 있는 경로를 각 장비에서 mount 해서 사용해보고 있는데 아직은 괜찮은 것 같지만 좀 더 지나봐야 알겠다.

2. 기능의 구조화 및 정리

단편적인 기능들을 간단하게 추가만 하다가 어느 시점이 되면 기능들을 모아서 별도의 모듈로 개발하는게 좋겠다는 생각을 한다. 물론 공수가 들어가는 문제이지만...

3. 별도의 인증과정

무작정 키를 장비 한대에서 등록하고 관리하고 교환하고 할 게 아니라 인증 기능을 담당하는 장비나 서비스를 별도로 분리하는게 좋을 것 같다. 난 이 작업을 진행하는 것 자체가 꽤 재미있을 것 같다. 이미 나와있는 것들도 많겠지만.

이리저리 하다보니 ssh에서 사용할 key를 여러쌍 생성하게 되었다. 이 때 필요에 따라 key를 선택해서 사용해야 한다. (매번 새로 생성하고 복원하고 할 수는 없으니까) 단순히 ssh command를 사용해도 되는 상황이라면 i 옵션을 사용한다. (identity file) 예를 들어 /home/id_dsa 라는 경로와 이름으로 private key가 존재하고 있고, test 계정으로 example.com 서버에 접속하려 한다면, [bash] ssh -i /home/id_dsa -l test example.com [/bash]

이렇게 key를 선택적으로 사용하지만 고정적으로 사용해야 할 때, 예를 들어서 GIT 저장소에 접근할 때 ssh로 해야 하고 일반적이지 않은 key(~/.ssh/id_rsa가 아닌)를 사용해야 한다면 ~/.ssh/config 파일을 수정해서 이용할 수도 있다. config 파일에 아래와 같은 내용을 추가한다. [bash] Host example.com IdentityFile /home/id_dsa [/bash]

끝.

Gerrit을 처음부터 설정해 사용하면서 느끼는 문제점들이 몇가지 있다.

 

1. 사용자 추가​

Gerrit 설정시 로그인과 관련해서 지원하는 몇 가지 방법이 있다.

그 중 OpenID와 LDAP을 가장 많이 쓸 것이라고 생각하는데 우리네 환경에서는 OpenID를 사용하기가 힘들다. (보안 이슈)

그래서 AD 서버와 LDAP으로 연결해서 쓰고는 있는데 이것 이외에 UI 조작으로 사용자 계정 추가를 할 수 있는 방법이 없다.

Command line 으로는 사용자 계정을 추가할 수 있는데 이것도 문제가 좀 많다. (뒤에 언급)

 

2. 사용자 삭제​

UI 상에 사용자 계정 추가가 없기 때문에 삭제 역시 없다.

 

3. Command Line Interface​

먼저 계정 생성 command인 create-account.​

생성은 된다. 하지만 생성이 제대로 되었는지 response가 없다.

무반응이면 제대로 되었나보다 생각하면 되는데 password 설정이 안된다.

http-password 라는 옵션이 있어서 거기에 password를 넣으면 되나 싶었는데 로그인하면 되질 않는다. (이것은 로그를 충분히 확인해볼 필요가 있겠다 싶은데 아직은 로그 확인 전)

create-account의 옵션 중에 있는 group은 공백을 인식하지 못하는 것으로 보인다.

큰따옴표로도 묶어봤으나 여전히 인식이 안된다.

add-ssh-key 옵션이 있는데 인자로 파일명을 주면 안된다.

지금까지 확인한 바로는 stdin만 먹는 것으로 보인다.

 

멋진 사용자 계정 삭제 command.​

유감스럽게도 없다.

여기저기 찾아보면 inactive로 만들라고 권고하는 것 같은데 inactive는 로그인만 못하게 막는 것이지 계정을 지우는게 아니기 때문에 만약 짜증나는 계정 foo를 삭제하고 다시 만들려고 해도 안된다. foo2 등의 이름으로 다시 만들 수 밖에.

 

이해 안되는 set-account.​

계정 삭제가 안되니 이리저리 다시 세팅해서 계정을 쓰려고 했는데 재미있는 사실을 발견했다.

바로 add-ssh-key와 delete-ssh-key 옵션에서 문제를 발견했는데 이미 추가한 ssh-key를 지우려고 편하게 delete-ssh-key ALL (ALL은 제공하는 값이다. 해당 계정의 모든 ssh key를 지우라는)을 입력했는데 역시나 response 없이 command가 실행되었다. 그래서 문제없겠거니 생각하고 add-ssh-key로 새로운 ssh key를 추가했는데 역시나 no response. 제대로 설정 되었는지 확인하려고 ssh key 삭제 전에 잘 되던 저장소 clone을 해봤더니 public key 문제로 불가. ssh key를 다시 만들고 별 쇼를 다 해봐도 안된다. 또 다른 계정 xxx2 등으로 또 만들어서 쓸 수 밖에.

 

4. 관리자 계정​

왜 그런건지 모르겠지만 갑자기 오늘 오전부터 관리자로 설정되어 있던 내 계정이 관리자가 아닌 걸로 인식을 하고 있었다.

도저히 알 수가 없어서 db를 다시 만들어서 설정했다.

 

결론​

현재까지의 상태들을 종합하면 gerrit은 계정관리 부분이 취약하다. 뭔가 대단히 불편한데, 불편한 건 이해하고 넘어가더라도 원인을 파악할 수 있는 수단이 거의 없어서 해결할 방법을 찾기가 힘들다.

참고로 이 모든 현상이 만들어지고 있는 gerrit의 버전은 무려 2.5.1이다. 1.0도 아니고 1.5도 아니다.

구글 내부적으로 쓰는거라 그런건지도 모르겠지만, made by Google 이라고 맹신해서는 안된다는 걸 느낀다.

 개발되는 코드를 git으로 관리하기로 결정하면서 git public repository 설정 중.

리눅스 서버에서 구축해야 하나 여러가지 이유로 윈도우에서 확인하고 있다. ssh로 인증하게 되어있어서 몇가지 문제점이 있었으나 인증 문제는 해결되었다. 지금 남아있는 문제는 문자열 길이가 맞지 않는다는 오류 메세지인데 추측되는 원인은 있으나 아직 조치하지 못하고 있음.

내일은 완전히 해결할 수 있기를...아니 해결한다!