변경점 비교

## RSA 키 페어 생성

```bash
ssh-keygen -t rsa -b 4096 -C USERNAME@HOSTNAME
```

- *-C* 옵션으로 키에 주석을 추가할 수 있다. 원하는 주석 포맷으로 입력하여 생성할 수 있는데 키를 구분하기 위해 `사용자명@호스트명`이 일반적으로 사용된다.
- *-b* 옵션으로 키페어의 비트 사이를 설정할 수 있다. 글 작성일 기준 4096이 권장된다.

## 키 등록

키를 생성하면 `$HOME/.ssh` 경로에 개인키~id_rsa~, 공개키~id_rsa.pub~ 파일이 두개 생성된다. 공개키를 접속하려는 장치에 설치해두면 이후부터는 `ssh client`와 `ssh server`가 자동으로 서로의 키를 확인하여 비밀번호 입력없이 바로 접속이 가능해진다.

```bash
ssh-copy-id SSH_USERNAME@SSH_SERVER_HOST
```

*SSH_USERNAME*~설치 대상 호스트 로그인 유저명~, *SSH_SERVER_HOST*~설치 대상 호스트~ 각각 자신에게 맞는 값으로 변경하여 실행하면 해당 호스트에 생성한 키 설치를 진행한다. 공개키를 설치할 때에도 ssh를 통해 원격 호스트에 설치하는 것이므로 비밀번호 한 번 입력해야한다. 명령이 실행된 후 다시 접속해보면 비밀번호 입력없이 바로 접속되는 것을 확인할 수 있다.

로그인에 실패할 경우 sshd 설정을 확인해봐야 한다. `/etc/ssh/sshd_config`에서 `RSAAuthentication` 옵션과 `PubkeyAuthentication` 옵션이 올바르게 설정되었는지 확인해야한다. `RSAAuthentication`옵션의 경우 현재~확인버전 1:9.2p1-2+deb12u2~ 삭제되었기 때문에 `PubkeyAuthentication`만 확인하면 된다.

```text
PubkeyAuthentication   yes
```

## 키 전용 접속

아마존 ec2 인스턴스의 경우, 비밀번호 입력없이 무조건 `identity_file`을 통한 접속만 허용한다. 비밀번호를 시도해보는 기회조차 주지 않고 오직 약속된 키만 허용하는 방식으로 보안상 더 이점이 있다. 그러나 아마존처럼 거대한 프로젝트가 아니라면 배보다 배꼽이 더 커지기 때문에 규모와 중요도에 따라서 결정해야한다.

처음 설정할 때 `ssh-keygen`을 여러번 테스트 해야 할 탠데 이때 의도치 않게 공개키가 새로 덮어 씌워지게되면 ssh 접속을 할 수 없는 상황이 발생한다. 직접 터미널로 접속할 수 없거나 플랫폼이 제공해주는 `콘솔접속`과 같은 기능이 없는 환경이라면 신중히 설정해야 한다.

1. 클라이언트: 키페어 생성 후 대상 서버에 공개키 설치
2. 서버: 공개키 인증방식: 활성화
3. 서버: 비밀번호 입력방식: 비활성화
4. 서버: ChallengeResponseAuthentication: 비활성화
   * PAM방식 사용을 활성화한다면 비활성화하여야함.

```text
PubkeyAuthentication   yes
PasswordAuthentication no
ChallengeResponseAuthentication    no
```

!!!각별히 주의  
!!!다음을 진행한 후에는 비밀번호를 통한 ssh 접속시도를 할 수 없습니다.

설정 후 ssh 데몬을 재시작하면 새로운 설정으로 동작하게 된다. 서버에 설치된 개인키 파일~$HOME/.ssh/id_rsa~을 클라이언트 장치에 복사하고 -i 옵션을 통한 접속이 올바르게 동작하는지 확인할 수 있다.

## 한계점

진행하면서 눈치챘겠지만 1:n 구조에서는 키 파일을 관리하기가 매우 힘들다. 매번 새로운 클라이언트에 서버의 키 파일을 복사해야 하므로 복사를 위해서 미리 키 파일을 들고 있어야 하기도 한다. 이를 위하여 웹상에 공개할 수도 없는 노릇이며 전용 USB라도 하나 들고 다녀야 하는 상황을 만나게 된다. 이를 위해서 키 서버와 같은 부가적인 서버가 존재해야지만 관리 포인트를 줄일 수 있을 것이다.

그나마 가볍게 사용할 수 있는 개인용 서버가 넉넉하다면 조금 더 편리해질 수 있겠지만 여전히 부수적인 작업들이 따라오게 된다. 또한, 주로 사용하게 될 집이나 사무실의 네트워크 환경도 문제이다. 방화벽이 없다면 괜찮지만 보통은 그렇지 않기 때문에 꽤나 귀찮은 일이 될 수도 있다.

매번 비밀번호를 치는 게 귀찮게 느껴져 AWS처럼 접속할 수 있도록 구성하고 보안과 편의를 모두 가져가 보려 했지만 개인 수준의 소규모 서버에서는 잘 조합된 강력한 비밀번호와 방화벽을 잘 구성하고 IP 밴과 같은 부가기능을 설정 것이 훨씬 더 비용 효율적이며 안전하고 편리한 방안이다.