[AWS] EC2 접속용 SSH 키페어 분실 또는 손상 시 키 재생성 방법

현재 운영 중인 EC2 인스턴스를 SSH로 접속하는 용도로 SSH Key-pair를 사용합니다. 서버에 public-key를 저장해놓고 private-key는 로컬에 보관하여 사용합니다. 일반적으로 PEM 키를 사용합니다.

사용 중인 맥북을 공장초기화하면서 로컬에 있던 개인키(private-key)가 안전하게 i-Cloud에 저장되어있을 것이라 생각했습니다. 생각대로 공장초기화 후 i-Cloud를 통해 개인키를 다운받았고 EC2 인스턴스를 SSH로 접속해봤습니다. 그런데 접속이 되질 않습니다.

Permission denied (publickey).

개인키 퍼미션도 600으로 낮춰놨고 아무런 문제가 없었지만 계속 저 메세지만 출력되었습니다. 끝내 i-Cloud로 복원된 개인키가 손상되었다는 결론을 내게 되었고 키페어를 새로 생성하기로 했습니다.

키 페어 새로 생성하여 적용하는 방법

1. 우선 SSH를 접속할 로컬 환경에서 키를 새로 생성한다. 아래 명령을 입력한뒤 엔터 연타

$ ssh-keyhen -m PEM

2. 생성된 개인키의 공개키(public-key)를 출력하여 복사한다.

$ ssh-keygen -y -f {개인키 파일 경로}

3. AWS EC2 콘솔 -> 해당 인스턴스 중지 -> 인스턴스 우클릭 -> Instance Settings -> Edit user data -> 아래 스크립트 입력

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [users-groups, once]
users:
  - name: ec2-user
    ssh-authorized-keys: 
    - {위에서 복사한 공개키}

4. 저장 후 인스턴스 시작

5. SSH 접속 테스트

$ ssh -i {개인키 경로} ec2-user@{접속 호스트}

6. 잘 되면 성공. 이제 3번에서 저장했던 스크립트를 삭제해야한다. 저 스크립트는 EC2 서버에서 .ssh/authorized_keys 파일에 공개키를 넣어주는 역할이다. 즉, 한번 실행되고 나면 역할을 다하는데다 콘솔에 공개키를 포함한 스크립트가 존재하는 것은 보안상 리스크가 있기 때문에 삭제 해주는 것이 좋다. 인스턴스를 다시 중지한 후 3번 Edit user data 화면에서 저장한 스크립트를 삭제 -> 저장 후 인스턴스를 다시 시작한다.

7. 최종 접속 확인. 5번 접속 테스트를 다시 한번 해보고 접속이 잘된다면 키페이 교체는 완료된 것이다.

[AWS] ElasticLoadBalancer(ELB) 적용된 ElasticBeansTalk(EB) Instance SSH 접속 방법

ElasticBeanstalk로 구성된 서비스에 https를 사용하려면 ELB를 구성하여 발급된 SSL인증서를 적용해야 합니다. 여기서 ELB는 인프라에 앞단에서 https(443 포트) 접근을 받아 ElasticBeanstalk(이하 EB)에 넘기는 역할을 합니다.

위 처럼 구성된 경우 EB 인스턴스의 SSH 접근이 EB public DNS를 통해 되지 않게 됩니다. 이 경우 EB에 해당하는 EC2 인스턴스의 Public IP 또는 Public DNS로 SSH 접속이 가능합니다. Public IP/Public DNS는 EC2 인스턴스 재시작 시 변경됩니다. IP가 변경되지 않도록 하려면 ElasticIP를 이용해 고정 IP를 할당받아야 합니다.

그 전에 EC2 Key-pair 생성(pem키 발급) 또는 등록이 필요하고 해당 EC2 인스턴스의 보안 그룹(SecurityGroup)에서 SSH 22번 포트 Inbound 설정이 필요합니다. 설정이 완료되었다면 아래와 같이 접근이 가능합니다.

$ ssh -i {개인키 경로} ec2-user@{EC2 PublicIP or PublicDNS}

[OS X] 맥 기본 터미널로 AWS EC2 터미널 접속하는 방법

맥 환경에서의 첫 포스팅입니다. (드디어 맥북을 장만했습니다.) 덕분에 앞으로 OS X 에 관련한 포스팅도 하게 될 듯합니다.

OS X에서 EC2를 접속하기 위한 준비물은 이렇습니다.

  1. 터미널 프로그램 (기본 터미널 : command + space -> ter -> 엔터)
  2. EC2 키파일(.pem)

준비 되었다면 아래와 같이 세팅합니다.

키파일을 원하는 위치에 복사하고 퍼미션을 400으로 조정합니다. (저는 ~/Desktop/key/로 정했습니다.)

터미널에서 키파일 옵션을 추가한 명령으로 ssh 접속

 

아래는 참고 사항입니다.

  1. pem 파일이 아닌 ppk를 키파일로 사용하는 경우 : SSH 키 비밀번호를 입력을 요구하면서 인증 에러 발생
  2. ssh접속 시 도메인에 아이디를 붙이지 않는 경우 : Permission denied (publickey) 에러 발생

[SSH] 공개키, 개인키 설정에 관한 간단한 정리

ssh-keygen 명령 : 자신의 개인키(id_rsa)와 공개키(id_rsa.pub)을 쌍으로 생성

~/.ssh/authorized_keys : 원격 서버에서 접속을 허용할 클라이언트의 공개키(id_rsa.pub) 내용을 저장

~/.ssh/known_host : 원격 서버에 접속을 하는 경우 클라이언트와 원격 서버와의 키교환 정보를 캐시로 저장. 따라서 원격 서버의 정보가 변경(IP 또는 키정보) 된 경우 새로운 정보를 갱신하기 위해 캐시 내용을 삭제해야 함.

 

* 원격 서버는 공개키(id_rsa.pub) 정보를 가지고 있어야 하며 개인키(id_rsa)는 클라이언트가 원격으로 접속 시 인증에 사용함.

* Windows 계열에서 Git 클라이언트를 설치하면 제공되는 Bash 쉘(Git-Bash)에서도 ssh-keygen을 사용하여 리눅스와 동일한 방법으로 공개키/개인키를 생성 가능. (생성 시 저장되는 경로는 C:\Users\계정명\.ssh)

[Git] SSH 공개키로 비밀번호 없이 Push/Pull 하도록 설정

Git 원격 저장소를 이용할때 Push나 Pull을 할때 매번 패스워드를 묻게 되는데 이 과정을 SSH 공개키를 생성하여 생략할 수 있습니다.

GitHub가 아닌 별도 원격 Git 저장소 서버를 운영하고 있다는 가정하에 작성된 포스트이며,

최대한 간단하게 설명하도록 하겠습니다.

 

1. 공개키/개인키 생성하기 (Git 원격저장소 서버)

키이름을 정할지와 키 비밀번호를 지정할지를 묻는데 모두 Enter로 지나갑니다.
만약 키이름이 id_rsa가 아닌 다른 이름으로 생성할 경우 git 인증 시점에서 키파일을 읽지 못합니다.
성공적으로 생성되었다면 id_rsa(개인키)와 id_rsa.pub(공개키)가 존재할 것 입니다.

 

2. 공개키 인증 파일(authorized_keys)에 등록

 

3. 키 파일 저장 디렉토리(~/.ssh) 퍼미션 설정

키 파일은 보안에 취약한 설정을 한 경우 사용자 인증이 무력화되는 치명적인 문제를 낳기 때문에 적절한 퍼미션을 설정해주셔야 합니다. 원칙적으로 키파일은 쓰기와 실행 권한을 주지 않습니다.

개인키(id_rsa)의 경우 키 내용을 읽게 되면 인증 정보가 공개되는 것이나 마찬가지이기 때문에 읽기 권한도 주어서는 안됩니다.

 

4. 개인키 획득(다운로드)

개인키(id_rsa) 파일을 본인 PC에 다운로드 받습니다. 이 파일은 자물쇠(공개키)의 열쇠 역할이 되므로 분실되거나 유출되지 않도록 관리해야 합니다.

 

5. SSH 클라이언트로 접속

SSH 접속용 클라이언트는 종류가 많고 각각 방법이 다르기에 자세하게 설명은 어렵습니다. 하지만 공통적인 부분은 접속시 아이디 인증이 아닌 키 인증을 선택하여 비밀키를 불러와 패스워드 대신 개인키로 접속을 하는 것입니다.

개인키를 통해 접속을 한 경우 Git Push 또는 Pull 명령 실행시 키인증 정보를 읽어 패스워드를 더 이상 묻지 않도 자동으로 인증하게 됩니다.

SVN 자동 로그인 (매번 로그인 하지 않도록 하는 방법)

간단한 내용이지만 매번 개발 환경을 세팅할 때마다 검색하는 수고를 덜기 위해 메모성으로 포스팅합니다.

이 포스트의 내용은 svn을 사용해본 경험이 있으신 분들은 모두 알고 있는 내용이라 생각하여 세세한 설명은 넘어가도록 하겠습니다.

방법은 두가지가 있습니다.

 

plink.exe 를 이용하는 방법 (TortoiseSVN 사용 시 기준입니다.)

TortoiseSVN Setting 을 실행 > Network 선택 > SSH Client에 아래 내용 입력
“C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe” -l [SVN 아이디] -pw [SVN 비번]

 

시스템 환경 변수를 이용하는 방법

1. 제어판 > 모든 제어판 항목 > 시스템 > 고급 시스템 설정 > 환경 변수 클릭 > 시스템 변수에 아래 내용 추가
변수 이름 : SVN_SSH
변수 값 : C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe -l [SVN 아이디] -pw [SVN 비번]
2. C:\Users\사용자계정\AppData\Roaming\Subversion 이동
3. config 파일 편집
4. ssh = $SVN_SSH ssh -q 앞 부분 주석(#) 제거

 

TortoiseSVN 만을 사용한다면 첫 번째 방법이 간단합니다. 하지만 다른 프로그램에서 svn을 사용한다면 두 번째 방법을 사용하시는걸 추천합니다.

[Linux] SSH 접속 Root 계정 제한하는 방법

서버의 보안에서 모든 권한을 가진 계정을 직접 사용할 수 없게 하는 기본 중 기본으로 아직까지 많은 서버들이 처리를 하지 않아 피해를 보는 경우가 있습니다.

그 중 SSH 접속 제한을 하는 조치는 가장 기본이라 할 수 있습니다. 아무리 소규모로 운영되는 서버라도 외부에서 대놓고 SSH 봇 공격시도를 해옵니다. 이를 방어하는 방법은 아주 간단하지만 또 간단하기에 쉬쉬하는 경향이 있습니다.

SSH 원격 접속은 보통 일반 사용자 계정으로 접속 뒤 필요한 경우 su로 root권한을 취득한 후에 시스템을 컨트롤하는 것이 기본입니다. 직접적으로 root로 접근하는 것을 막는 것이죠.

SSH의 root 접속을 막기위한 방법은 아래와 같습니다.

1. # vi /etc/ssh/sshd_config 로 ssh 설정 파일을 엽니다.
2. 주석처리 된 PermitRootLogin 옵션의 주석을 풀고 yes에서 no로 값을 변경합니다.
3. 파일을 저장하고 # service sshd restart로 ssh 데몬을 재시작 합니다.

그 외에도 접속을 제한하기 위한 방법은 여러 가지가 있습니다. 특정 유저나 그룹을 제한하거나 허용하는 방법 등 더 상세한 내용은 다음 포스팅에서 다루겠습니다.