Ansible(이하 앤서블)의 환경 구성, 기초 사용법

출처: https://blog.naver.com/alice_k106/221333208746

 

1. 들어가기 전.

 

앤서블은 여러 개의 서버를 효율적으로 관리하기 위해 고안된 환경 구성 자동화 도구이다. 앤서블은 2012년에 출시되었으며, 2013년에 버전 1이 출시된 이후, 레드햇에 인수되어 개발되고 있다. 앤서블은 셰프(chef), 퍼펫(Puppet) 등과 같은 구성 관리 도구의 일종이라고 볼 수 있으나, 사용성 또는 확장성 측면에서 셰프 또는 퍼펫에 비해 더욱 많은 사람들에게 사랑받고 있는걸로 보인다. (적어도 내 주변에 앤서블을 사용한다는 사람은 봤어도, 셰프나 퍼펫을 쓰는 사람은 본 적이 없다) 실제로, 최근에 개발되고 있는 환경 자동화 툴 (ex. kubespray) 등은 셰프나 퍼펫이 아닌 앤서블을 택하고 있다.

 

 

1.1 앤서블의 역할

 

사용법을 설명하기에 앞서, 앤서블의 역할, 정확히 말하자면 환경 구성 자동화 도구의 역할을 정확히 정의할 필요가 있다. 리눅스에서 동일한 환경을 구성하기 위해서 사용하는 가장 기초적인 방법은 Bash 쉘 스크립트이다. 많은 개발자들은 각종 패키지의 설치, 설정 파일의 수정 등을 위해 일괄 처리 목록을 쉘 스크립트에 나열하고 이를 실행해 본 경험이 있을 것이다. 그러나 클러스터에 존재하는 많은 서버들에 동시에, 동일한 환경을 배포해야 하는 상황에서 Bash 쉘 스크립트는 분명 한계점을 가진다. (물론 사용할 수도 있지만 Bash 쉘 스크립트는 그러한 목적을 위해서 존재하는 것은 아니며, 여러 서버를 제어하는 규격화된 양식이 존재하지 않아 설령 그러한 기능을 구현하더라도 개개인 모두가 다른 템플릿을 정의해 사용하게 될지도 모른다)

 

이를 위해 고안된 것이 Infrastructure as a Code라는 개념이며, 이는 환경의 배포와 구성을 규격화된 코드로 정의해 사용하는 것을 의미한다. 즉, Infrastructure as a Code의 개념을 내포하는 각종 환경 자동화 도구는 인프라의 상태를 코드로 선언하고 이를 모든 서버에 배포함으로써 특정 환경을 동일하게 유지할 수 있도록 돕는다. 그러한 환경 자동화 도구의 대표적인 예시가 앤서블이며, 앤서블은 환경의 배포뿐만 아니라 서버 클러스터의 체계적인 관리, 확장 가능한 모듈의 사용 등 다양한 측면에서 사용될 수 있는 도구로서 많은 개발자들에게 사랑받고 있다. 

 

 

1.2 연구실 서버 클러스터에 앤서블을 도입하고 나서..

 

앤서블의 간단한 활용 예시를 들어보자. 나는 연구실에서 서버실을 관리하고 있으며, 약 10대의 서버를 동시에 동일한 환경을 구성하는 임무를 맡게 되었다. 이 때 가장 먼저 수행해야 하는 것은 무엇일까? (물론 모든 서버는 포맷 및 IP 세팅은 완료되었다고 가정한다)

 

1. root가 아닌 새로운 계정을 생성하고, 해당 계정에 sudo 권한을 부여한다.
2. 모든 서버에 SSH root 접근 권한을 차단하고, SSH 접근 포트를 22번이 아닌 다른 포트로 변경한다.
3. 방화벽에서 변경된 SSH 포트를 허용한다.
4. SSH 데몬을 재시작한다.

 

상당히 간단해 보이는 작업이지만, 실제로 10대에 모두 동일한 환경을 구성할 때는 약 10단계 이상의 작업을 수행한다(!). 나는 서버 클러스터 관리에 앤서블을 도입하고 난 뒤 위와 같은 서버 기초 세팅 작업은 물론, 더욱 고도화된 요구사항 또한 손쉽게 제어할 수 있게 되었다. 연구실 프로젝트에서 도출되는 요구사항에 따라 클러스터의 일부만 상태를 변경해야 할 때도 있고, Ubuntu와 CentOS가 뒤섞인 클러스터를 관리해야할 때도 있으며, 심지어 그래픽카드만 장착되어 있는 서버만 별도로 구성해야 할 때도 있는데, 이러한 상황에도 환경 및 설정을 손쉽게 저장하고 변경할 수 있게 되었다. 클라우드 개발자라면 무엇이 되었든지간에 자동화가 답이란 것을 느끼고 있다.

 

어쨌든. 앤서블의 사용 방법은 대략적으로라도 알아두면 손해는 없다. 이전보다 나아졌으면 나아졌지, 악화되지는 않았다.

 

 

2. 앤서블 시작하기

 

2.1 앤서블 사용 환경 준비

 

모든 애플리케이션이 그러하듯이, 앤서블 또한 서버와 클라이언트 구조로 되어있다. 그러나 셰프나 퍼펫과는 다르게 앤서블은 에이전트가 없는 구조이기 때문에 별도의 에이전트 설치가 필요 없다는 장점이 있다. 기존의 에이전트 역할을 SSH 데몬이 대체하기 때문에 SSH 접속만 가능한 서버라면 앤서블의 제어 대상이 될 수 있다.1

 

 

 

마음같아서는 연구실에서 운용하고 있는 실제 서버 클러스터를 예시로 들고 싶지만, IP를 블로그 포스트에 적어두면 어떤 일이 생길지 모르기 때문에(.....) VM에서 수행하는 것을 가정한다. 간단한 환경은 아래와 같다. 한 VM에서 앤서블 커맨드를 실행하고, 다른 VM이 SSH 데몬을 통해 제어되는 구조이다.

 

1. CentOS 7.2를 사용하는 두 개의 VM을 생성하였다.
2. 두 VM은 Virtual Box의 호스트 전용 브릿지를 이용해 상호 통신이 가능한 상태이다.
3. 두 VM은 SSH 데몬이 실행중이며 SSH로 접속 가능한 상태이다.

 

앤서블을 사용하려는 VM (이하 앤서블 실행 VM) 에서 앤서블 커맨드라인을 설치한다. 

pip install ansible 을 수행해 간단히 설치할 수 있다. 

 

1 2 3 4 5 6

[root@controller ansible-blog-post]# pip3.6 install ansible .... Requirement already satisfied: cffi>=1.7; platform_python_implementation != "PyPy" in /usr/lib64/python3.6/site-packages (from cryptography->ansible) Requirement already satisfied: pycparser in /usr/lib/python3.6/site-packages (from cffi>=1.7; platform_python_implementation != "PyPy"->cryptography->ansible) You are using pip version 9.0.1, however version 18.0 is available. You should consider upgrading via the 'pip install --upgrade pip' command. Colored by Color Scripter

cs

 

앤서블의 제어 대상이 될 VM (이하 앤서블 작업 대상 VM) 에서, SSH로 접근하기 위한 앤서블 전용 사용자를 생성하고 비밀번호를 설정한다.

 

1 2 3 4 5 6 7

[root@ansible-target home]# adduser ansible-alicek106   [root@ansible-target home]# passwd ansible-alicek106 ansible-alicek106 사용자의 비밀 번호 변경 중 새  암호: 새  암호 재입력: passwd: 모든 인증 토큰이 성공적으로 업데이트 되었습니다.

cs

 

앤서블 전용 사용자가 sudo 권한을 비밀번호 없이 사용할 수 있도록 설정한다.

 

1 2 3 4 5 6 7

[root@ansible-target home]# visudo   .... ## Allow root to run any commands anywhere root    ALL=(ALL)       ALL ansible-alicek106 ALL=(ALL)     NOPASSWD:ALL .... Colored by Color Scripter

cs

 

 

 

Tip : 위에선 이해를 돕기 위해 앤서블 전용 사용자를 생성하지만, 기존에 존재하던 사용자를 사용해도 무관하다. root 계정을 그대로 사용해 앤서블 제어(SSH 접속)에 사용해도 되지만, 추후에 설명할 become 옵션의 설명을 위해 앤서블 전용 사용자를 생성하였다.

다음으로, 앤서블 실행 VM에서 앤서블 작업 대상 VM으로 비밀번호 없이 접근할 수 있도록 SSH 키를 복사한다. 기존에 사용하던 SSH 키가 없다면, ssh-keygen 명령어를 통해 생성할 수 있다. 

 

1 2 3 4 5 6 7 8 9 10

[root@controller ansible-blog-post]# ssh-copy-id ansible-alicek106@192.168.1.100   /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys ansible-alicek106@192.168.1.100's password:   Number of ky(s) added: 1   Now try logging into the machine, with:   "ssh 'ansible-alicek106@192.168.1.100'" and check to make sure that only the key(s) you wanted were added. Colored by Color Scripter

cs

 

앤서블 실행 VM에서 아래의 내용을 hosts.ini로 작성한다.

 

1 2 3

[root@controller ansible-blog-post]# vim hosts.ini   ansible-target-host ansible_host=192.168.1.100 ansible_user=ansible-alicek106

cs

*  ansible-target-host: 서버의 이름

* 해당 서버의 SSH에 접근하기 위한 Endpoint: 192.168.1.100

* 리눅스 사용자: ansible-alicek106

* ansible_port: SSH 포트(추가사항) 

 

마지막으로, 앤서블이 정상적으로 잘 동작하는지를 테스트한다. 

 

 

 

여기까지 됬다면, 최소한의 앤서블 환경 세팅은 끝이 난다.

 

 

2.2 앤서블의 기본 개념

 

앤서블에는 크게 3가지 요소가 있다. 인벤터리, 플레이북, 모듈이 그것이다. 이는 각각 (1) 어디서, (2) 무엇을, (3) 어떻게 수행할지를 정의한다. (엄밀히 말하면 모듈이 플레이북에서 사용되지만, 이해를 위해 구분해 설명한다)

 

2.2.1 인벤터리 (inventory)

인벤터리는 앤서블에 의해 제어되어 Infrastructure as a Code의 대상이 될 서버들의 목록을 정의하는 파일이다. 일반적으로 hosts.ini 파일에 정의해 사용하는 듯 하며, 위 예시에서 작성했던 hosts.ini 파일이 바로 그것이다. 인벤터리에는 여러 서버들의 접속 정보 (SSH 접근 IP, 포트, 리눅스 사용자) 등을 정의한다. 위에서 사용했던 hosts.ini 파일을 다시 들여다보자.

 

1 2 3

[root@controller ansible-blog-post]# vim hosts.ini   ansible-target-host ansible_host=192.168.1.100 ansible_user=ansible-alicek106

cs

 

기본적으로, 호스트의 정보를 정의할 때는 서버의 이름을 가장 앞에 쓰고 (ansible-target-host) 그 다음 차례대로 해당 서버의 정보(앤서블 변수)를 나열한다. 즉, 인벤터리 파일에서 해당 서버를 고유하게 식별할 수 있는 이름이 ansible-target-host 이며, 해당 서버의 SSH에 접근하기 위해서는 192.168.1.100이라는 Endpoint를 사용하고, ansible-alicek106 이라는 리눅스 사용자를 통해 SSH로 접근한다는 것을 의미한다. 물론, SSH 포트 등과 같은 옵션 또한 정의할 수 있다 (ansible_port). 

 

(뒤에서 다시 이야기하겠지만, 인벤터리에서 명시된 값들은 모두 앤서블 호스트 변수(variable)로 적용된다)

 

 

hosts_group.ini 파일 예시

 

인벤터리에서는 여러 개의 호스트를 그룹화해 사용할 수 있다. 예를 들어 3개의 서버를 앤서블로 제어하려고 할 때, 1개는 Ubuntu이고 2개는 CentOS라면 위와 같이 그룹화해 정의할 수 있다. 이는 호스트의 특징에 따라 서버를 분류함으로써 구분하기 쉽게 할 뿐만 아니라, 추후에 앤서블로 서버를 제어할 때 원하는 그룹만을 식별해 원하는 명령을 내릴 수 있도록 하는 기능을 제공한다. 

 

예를 들어, 위의 인벤터리 파일(hosts_group.ini)를 이용해 CentOS 서버에만 명령을 내리고 싶다면 아래와 같이 사용할 수 있다. -i 인자를 사용해 인벤터리 파일을 명시한다.

 

1

[root@controller ansible-blog-post]# ansible -m ping -i hosts_group.ini centos-servers

cs

 

실제 사용 시에는 플레이북을 사용하기 때문에 ansible-playbook 명령어를 주로 사용하며, 위와 같은 예시는 테스트 시에만 사용한다.

 

 

2.2.2 플레이북 (playbook)

플레이북은 yaml 포맷으로 되어 있는 파일로서, 인벤터리 파일에서 정의된 서버들에서 무엇을 해야할지를 정의한다. 일반적으로 앤서블을 사용한다고 하면 플레이북을 사용한다는 것을 의미하며, 플레이북 단독으로 사용되는 것이 아닌 플레이북 + 인벤터리의 조합으로 사용하게 된다. 즉, 인벤터리를 통해 어디에서(where) 작업을 수행할지를 명시하고, 플레이북을 통해 무엇을(what) 할지를 정의한다. (위에서 사용했던 예시는 플레이북을 사용하지 않았는데, 인벤터리에서 명시된 서버들에 정상적으로 접속할 수 있는지 단순히 테스트(ping) 하는 용도였기 때문이다)

 

nginx.yaml 예시

 

간단한 플레이북의 예시를 들어보면 위와 같다. 위 플레이북의 이름은 lets nginx install 이고, 인벤터리 파일에서 모든 호스트를 대상으로 (hosts: all) 수행함을 명시하고 있다. become: true는 인벤터리의 접속한 리눅스 사용자가 sudo 권한으로 수행할지를 의미한다.

 

그 아래에 정의된 tasks 가 실제로 플레이북에서 실행되는 작업들을 나열한 것이며, 플레이북에서 가장 중요한 부분이다. tasks의 하위 항목에는 task를 나열할 수 있고, 위 예시에서는 1개의 task만이 정의되어 있다. 해당 task의 이름은 nginx package install 이고, yum을 통해 nginx를 (name: nginx) 설치해라 (state: installed) 라는 의미를 갖고 있다. 물론, "설치해라" 대신 "삭제해라" (state: removed) 라는 명령 또한 가능하다.

 

플레이북은 ansible-playbook 이라는 명령어를 통해 실행할 수 있으며, 가장 마지막 인자로 플레이북 파일의 이름을 입력한다.

 

1

[root@controller ansible-blog-post]# ansible-playbook -i hosts.ini nginx.yaml

cs

 

보통 튜토리얼에서는 이해를 돕기 위해 1개의 플레이북만을 사용하지만, 실제로는 롤(role) 이라는 앤서블의 요소를 사용해 여러 개의 플레이북을 정의해 사용한다. 롤에 대한 설명은 추후 포스팅할 예정이다.

 

Tip : yaml 파일은 일반적으로 ---로 시작하는데, 이는 yaml 파일임을 명시하기 위한 목적으로 쓰인다.2 또한, yaml에서 - name: nginx 와 같이 - 로 시작하는 항목은 리스트 (또는 배열) 로 사용됨을 나타낸다.

 

 

2.2.3 모듈 (module)

모듈은 플레이북에서 task가 어떻게(how) 수행될지를 나타내는 요소이다. 예를 들어 yum 명령어를 통해 패키지를 설치할 떄에는 yum 모듈을 사용할 수 있다. 위의 nginx.yaml 예시에서는 yum 모듈을 사용하였으며, task의 이름 (- name: nginx package install) 바로 밑에 모듈의 이름인 yum을 명시하였다.

 

 

당연하지만, yum으로 패키지를 설치하려면 어떤 패키지를 설치할 것인지, 해당 패키지를 삭제할지 설치할지 업데이트할지 등을 명시해야 한다. 따라서 yum 모듈은 어떤 패키지를 (name: nginx) 설치할지 삭제할지 (state: installed)에 대한 옵션을 명시해야만 한다. 여기서 한 가지 알 수 있는 것은, 모듈마다 요구하는 옵션이 모두 다르기 때문에 사용하려는 모듈의 옵션 사용 방법을 미리 숙지해야만 한다는 점이다. 

 

다른 예시를 들어보자. debug 모듈은 인벤터리에 정의된 서버에서 디버깅을 위한 각종 값 또는 변수의 출력에 쓰이는 모듈이다.

 

 

 

debug 모듈은 yum 모듈과 다르게 어떠한 내용을 출력할지에 대한 명시가 있어야 하기 때문에 msg: 라고 하는 옵션을 명시해줘야만 한다. 이와 같이 각 모듈은 사용하는 방법이 모두 제각각이기때문에, 사용하기 전 반드시 구글링을 통해 사용 방법을 숙지해야만 한다. 앤서블은 약 500개의 모듈을 제공하고 있다고는 하지만, 자주 쓰이는 모듈은 사실상 한정되어 있으며 그러한 모듈의 사용 방법은 구글링하면 stack overflow나 server fault 등에서 쉽게 찾을 수 있기 때문에 크게 걱정하지 않아도 된다.

 

참고로, 위 debug 모듈의 결과값은 아래와 같다. debug 모듈은 꽤 자주 쓰이기 때문에 알아두면 편리하다.

 

 

 

 

3. 앤서블과 멱등성

 

일반적으로, 앤서블은 멱등성 (idempotence) 를 제공하는 환경 자동화 도구라고 언급된다. 멱등성이란 수학에서 쓰이는 용어로, 동일한 작업을 수행해도 변화가 없음을 뜻한다. 예를 들어 100에 1을 곱해도 이는 여전히 100이기 때문에 멱등성의 예시로 쓰일 수 있다. 이와 같이, 똑같은 작업을 몇번을 수행해도 동일한 결과를 얻을 수 있다면 이를 멱등성이라고 칭한다.

 

앤서블 및 셰프, 퍼펫과 같은 환경 배포 자동화 도구는 멱등성을 제공하는 것을 지침으로 한다. 앤서블의 플레이북에서는 모듈 실행 시 결과를 상태 (state) 로 정의함으로써 최종적으로 존재해야 하는 환경을 명시한다. 해당 상태가 만족된다면 앤서블은 다른 작업을 하지 않고 task를 종료하는데, 이는 플레이북을 몇번이라도 실행하더라도 동일하게 수행된다. 따라서 앤서블은 플레이북에서 정의된 바람직한 상태를 만족하도록 수행하기 때문에 동일한 플레이북을 몇 번이고 실행해도 동일한 최종 결과값을 얻을 수 있는, 이른바 멱등성의 성질을 띠게 된다.

 

앤서블이 제공하고 있는 모듈의 대부분은 멱등성을 제공하는 것을 원칙으로 하기 때문에 모듈의 옵션 또한 멱등성을 고려하여 명시하도록 되어 있다. 따라서 한 번 성공적으로 수행된 플레이북은 다시 재실행하더라도 서버에 전혀 영향을 끼치지 않게 된다. 이미 플레이북이 원하던 상태(state)에 도달하였기 때문에 더 이상 작업을 수행하지 않는 멱등성을 준수하게 되는 것이다. 예를 들어 yum 모듈을 통해 state: installed 로 명시된 플레이북이 실행될 때, 해당 패키지가 이미 설치되어 있다면 해당 task는 아무런 동작도 하지 않고 success로 처리된 뒤 종료된다. 

 

 

 

쓰다보니 너무 길어져서 2편으로 나눠야겠음.

끝.

 

[참고1] 오류 대응

 

/usr/bin/ssh-copy-id: ERROR: No identities found

목차

• 1 문제상황
• 2 확인
• 3 해결방법
• 4 같이 보기
• 5 참고

•  

1 문제상황

[testuser@zetawiki1 ~]$ ssh-copy-id testuser@zetawiki2
/usr/bin/ssh-copy-id: ERROR: No identities found

2 확인

[testuser@zetawiki01 ~]$ ll ~/.ssh/id*
-rw------- 1 testuser testuser 1675 Dec  2 15:46 /home/testuser/.ssh/id_rsa
-rw-r--r-- 1 testuser testuser  404 Dec  2 15:46 /home/testuser/.ssh/id_rsa.pub

[testuser@zetawiki01 ~]$ sshpass -pP@ssw0rd ssh testuser@zetawiki02
Last login: Wed Dec  2 15:40:23 2015 from zetawiki01

[testuser@zetawiki02 ~]$ exit
logout
Connection to zetawiki02 closed.
[testuser@zetawiki01 ~]$

[testuser@zetawiki01 ~]$ sshpass -pP@ssw0rd ssh-copy-id testuser@zetawiki02
/usr/bin/ssh-copy-id: ERROR: No identities found

3 해결방법

• -i 옵션 추가

[testuser@zetawiki01 ~]$ sshpass -pP@ssw0rd ssh-copy-id -i ~/.ssh/id_rsa.pub testuser@zetawiki02
31
Now try logging into the machine, with "ssh 'testuser@zetawiki02'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

 

[testuser@zetawiki01 ~]$ ssh zetawiki02
Last login: Wed Dec  2 15:55:50 2015 from zetawiki01
[testuser@zetawiki02 ~]$

4 같이 보기

• 리눅스 SSH 패스워드 없이 자동 로그인
• 리눅스 ssh-copy-id
• .ssh/authorized_keys

5 참고

• http://stackoverflow.com/questions/22530886/ssh-copy-id-no-identities-found-error

ssh-copy-id no identities found error

 

[참고2] ssh 사용법

SSH 기본개념

SSH는 무엇이고 어떻게 사용하며 어떤 부분이 편리한지에 대해 알아본다.

• SSH 에 대한 더 많은 정보는 링크를 참고하자.
• 아래 내용은 macOS환경에 대해서만 다룬다. 일반적인 개발서버는 리눅스환경이기 때문에 조금 더 많은 설정(open-ssh 설치를 포함)이 필요할 수 있다. 하지만 맥락은 크게 다르지 않다.

SSH 소개

SSH(Secure Shell)는 원격지 호스트 컴퓨터에 접속하기 위해 사용되는 인터넷 프로토콜이다. 뜻 그대로 보안 셸이다. 기존의 유닉스 시스템 셸에 원격 접속하기 위해 사용하던 텔넷은 암호화가 이루어지지 않아 계정 정보가 탈취될 위험이 높으므로, 여기에 암호화 기능을 추가하여 1995년에 나온 프로토콜이다.(SSH는 암호화 기법을 사용하기 때문에, 통신이 노출된다고 하더라도 이해할 수 없는 암호화된 문자로 보인다.) 셸로 원격 접속을 하는 것이므로 기본적으로 CLI 상에서 작업을 하게 된다. 기본 포트는 22번이다.

SSH 키(key)

서버에 접속할때 비밀번호 대신 key를 제출하는 방식이다. 비밀번호보다 높은 수준의 보안요건을 필요로 할때 사용된다.

동작하는 방식

SSH 키(Key)는 공개키(public key)와 비공개키(private key)로 이루어지는데 이 두개의 관계를 이해하는 것이 SSH Key를 이해하는데 핵심이다. 키를 생성하면 공개키와 비공개키가 만들어진다. 이 중에 비공개키는 로컬 머신에 위치해야 하고, 공개키는 리모트 머신에 위치해야 한다.(로컬 머신은 SSH Client, 원격 머신은 SSH Server가 설치된 컴퓨터를 의미한다) SSH 접속을 시도하면 SSH Client가 로컬 머신의 비공개키와 원격 머신의 비공개키를 비교해서 둘이 일치하는지를 확인한다.

주요 기능

SSH의 주요 기능은 다음과 같다.

• 보안 접속을 통한 rsh, rcp, rlogin, rexec, telnet, ftp 등을 제공.
• IP spoofing (IP스푸핑, 아이피 위/변조 기법중 하나)을 방지하기 위한 기능을 제공.
• X11 패킷 포워딩 및 일반적인 TCP/IP 패킷 포워딩을 제공.

사용방법

SSH Key 만들기

macOS는 유닉스개열의 운영체제로 OpenSSH를 기본으로 포함하고 있기 대문에 ssh-keygen을 사용해 간단히 key 를 생성할 수 있다.

$ ssh-keygen -t rsa
# -t옵션으로 어떤 타입의 암호화 방식을 사용할 것인지 지정할 수 있다.(default가 rsa)

이제 어디에 key를 생성하여 저장할지를 묻는다. 엔터를 누르면 기본경로에 저장된다. 다른 경로를 원한다면 입력해주면 된다.

Generating public/private rsa key pair.
Enter file in which to save the key (기본경로):

다음은 ssh를 사용할때 비밀번호를 사용할지를 묻는다. 당연히 비밀번호를 설정하면 설정하지 않는것 보단 더 안전하다. 이 과정이 끝나면 key가 생성된다.

Created directory '경로'
Enter passphrase (empty for no passphrase):

key를 확인하고 싶다면 저장한 경로로 이동하면 된다.

$ ls -al /경로/

total 16
drwx------   4 user  staff   128  6  7 15:07 .
drwxr-xr-x+ 31 user  staff   992  6  7 15:05 ..
-rw-------   1 user  staff  1876  6  7 15:07 id_rsa
-rw-r--r--   1 user  staff   403  6  7 15:07 id_rsa.pub

이떄 id_rsa가 개인키 id_rsa.pub가 공개키이다. 권한을 보면 개인키는 사용자만이 읽고 쓸 수 있고(600), 공개키는 다른 사용자도 읽을 수 있는 권한(644)을 가지고있다. 접속하고자 하는 컴퓨터에 공개키을 등록해 놓으면, 이후 SSH로 접근할때 개인키와 비교하여 인증한다.

# scp를 통해 원격컴퓨터에 공개키를 전송(다른방법도 상관없다)
$ scp [경로]/id_rsa.pub user@sever_ip:id_rsa.pub

macOS는 기본적으로 SSH Server가 설치되어있다. macOS를 서버로 사용하고싶다면 시스템환경 > 공유 에서 원격로그인을 체크하면 외부에서 SSH를 통해 접근 가능하다.

이제 원격컴퓨터에서는 전달받은 id_rsa.pub를 authorized_keys파일에 등록한다. 만약 .ssh폴더가 없다면 새로 만들고 chmod 700로 설정해준다. (중요한 정보가 저장되어있기 때문에 소유자 외에 접근이 불가능하게 해줘야한다)

# 원격컴퓨터에 authorized_keys에 리다이렉션(추가) 해준다.
$ cat $HOME/id_rsa.pub >> $HOME/.ssh/authorized_keys

이제 SSH를 통해 접속 가능하다.

$ ssh user@sever_ip
# -v 옵션을 사용하면 디버그 모드로 접속과정의 로그를 확인할 수 있다. 

-p 옵션을 사용하면 포트번호를 지정할 수 있다.

$ ssh -p [포트] user@server_ip
# 예
$ ssh -p 2220 bandit0@bandit.labs.overthewire.org

만약 개인키(id_rsa)의 위치를 변경한다면, -i 옵션으로 접속하면 된다.

$ ssh -i [변경된 경로] user@sever_ip

Github에서 SSH사용하기

github에 ssh로 연결해두면 비밀번호 없이 연동할 수 있다. 물론 ssh키에 비밀번호(passphrase)를 설정한 경우에는 입력해야한다. 미리 만들어둔 공개키를 github 계정에 추가해주면 된다. 위 개념을 익혔다면 별도의 가이드 없이도 손쉽게 가능할것이다.

참고