SSH 보안 모범 사례: 서버 및 클라이언트 강화

SSH 보안 모범 사례가 중요한 이유는 SSH가 종종 서버의 정문 역할을 하기 때문입니다. 취약한 SSH 설정은 추측된 비밀번호 하나, 도난당한 키 또는 신뢰하는 호스트 실수 하나로 전체 셸 액세스를 허용할 수 있습니다.

SSH를 효과적으로 강화하기 위해 특별한 설정이 필요하지 않습니다. 키 기반 로그인, 제한된 사용자, 직접 루트 로그인 금지, 신중한 클라이언트 동작, 그리고 문제가 발생했을 때 알려주는 로그부터 시작하세요.

서버 측 보안 강화

SSH 서버 구성(sshd_config)은 클라이언트가 연결하고 인증하는 방법에 대한 규칙을 설정합니다.

1. 비밀번호 인증 비활성화

비밀번호 인증은 본질적으로 무차별 대입 공격에 취약합니다. SSH 키 기반 인증으로 대체하는 것은 할 수 있는 가장 효과적인 보안 강화 중 하나입니다.

이유: SSH 키는 비밀번호보다 훨씬 복잡하며 무차별 대입 방법을 통해 쉽게 추측되거나 크랙될 수 없습니다. 훨씬 강력한 인증 형태를 제공합니다.
방법: sshd_config 파일(일반적으로 /etc/ssh/sshd_config에 위치)을 편집하고 PasswordAuthentication no로 설정합니다. 변경 후 SSH 서비스를 다시 시작하십시오:
```
sudo sshd -t
sudo systemctl reload sshd
```
중요: 비밀번호 인증을 비활성화하기 전에 SSH 키 기반 인증을 성공적으로 설정하고 테스트하여 잠기는 것을 방지하십시오.

일부 배포판에서는 서비스 이름이 sshd가 아닌 ssh입니다. 시스템에서 제공하는 서비스 이름을 사용하고, 새 로그인을 테스트하는 동안 기존 세션을 열어 두십시오.

2. 포트 변경을 노이즈 감소로 간주

기본 SSH 포트를 22에서 변경하면 자동화된 스캔 노이즈를 줄일 수 있습니다. 키, 패치 및 액세스 제어를 대체하는 것은 아닙니다.

방법: sshd_config에서 Port 지시문을 변경합니다. 예를 들어 포트 2222를 사용하려면:
```
Port 2222
```
새 포트의 트래픽을 허용하도록 방화벽 규칙을 업데이트하고 클라이언트에서 연결할 때 포트를 지정하는 것을 잊지 마십시오:
```
ssh -p 2222 user@your_server_ip
```

3. 사용자 및 그룹 액세스 제한

SSH를 통해 로그인할 수 있는 사용자와 그룹을 제어합니다.

AllowUsers 및 AllowGroups: sshd_config에서 이러한 지시문을 사용하여 연결할 수 있는 사람을 명시적으로 지정합니다.
```
AllowUsers admin user1
AllowGroups sshusers
```
DenyUsers 및 DenyGroups: 또는 이를 사용하여 특정 사용자 또는 그룹을 차단합니다.

4. 루트 로그인 비활성화

SSH를 통한 직접 루트 로그인은 공격자가 즉시 가장 강력한 계정을 대상으로 삼는 것을 방지하기 위해 비활성화해야 합니다. 대신 사용자는 자신의 계정으로 로그인하고 관리 작업을 위해 sudo를 사용해야 합니다.

방법: sshd_config에서 PermitRootLogin no로 설정합니다.

5. 유휴 시간 초과 및 연결 유지 구성

무인 상태의 활성 SSH 세션이 무기한 열려 있는 것을 방지합니다.

ClientAliveInterval 및 ClientAliveCountMax: 이러한 서버 측 설정은 정기적으로 클라이언트에 널 패킷을 보내 연결이 여전히 활성 상태인지 확인합니다. ClientAliveCountMax 시도 후 클라이언트가 응답하지 않으면 서버가 세션을 끊습니다.
```
ClientAliveInterval 300  # 5분마다 패킷 전송
ClientAliveCountMax 2    # 2번의 응답 없음 후 연결 끊기 (10분)
```

6. 호스트 키 강화

서버의 호스트 키가 보호되고 적절하게 관리되는지 확인합니다.

권한: 호스트 키 파일(예: /etc/ssh/ssh_host_rsa_key)의 권한이 제한적이고(예: 600) 루트가 소유자인지 확인합니다.
알고리즘: 클라이언트가 지원하는 경우 Ed25519와 같은 최신 호스트 키를 선호합니다. 계획 없이 기존 호스트 키를 삭제하지 마십시오. 클라이언트는 이를 호스트 ID 변경으로 간주하기 때문입니다.
교체: 의도적으로 호스트 키를 교체하고 신뢰할 수 있는 채널을 통해 새 지문을 알리십시오.

클라이언트 측 보안 모범 사례

클라이언트 시스템과 SSH 키를 보호하는 것은 서버 측 강화만큼 중요합니다.

1. 개인 키 보호

개인 SSH 키는 서버로의 관문입니다. 최대한 주의하여 취급하십시오.

권한: 개인 키 파일(예: ~/.ssh/id_rsa)의 권한이 엄격하게(예: 600 또는 400) 설정되어 본인만 읽을 수 있도록 하십시오.
```
chmod 600 ~/.ssh/id_rsa
```
암호: 항상 강력한 암호를 사용하여 개인 키를 암호화하십시오. 이는 키 파일이 손상되더라도 암호를 요구하여 추가 보안 계층을 제공합니다.
복사 방지: 개인 키를 누구와도 공유하거나 안전하지 않은 위치에 저장하지 마십시오.

2. SSH 에이전트 전달 신중하게 사용

SSH 에이전트 전달을 사용하면 개인 키를 원격 서버에 복사하지 않고 로컬 SSH 키를 사용하여 원격 서버에 인증할 수 있습니다. 편리하지만 원격 서버가 손상된 경우 보안 위험이 될 수 있습니다.

활성화: ssh -A user@your_server_ip
모범 사례: 기본적으로 에이전트 전달을 비활성화하십시오. 신뢰하는 호스트에만 사용하고, 워크플로에 맞는 경우 배포 키, 배스천 ProxyJump 또는 단기 자격 증명과 같은 대안을 선호하십시오.

3. 호스트 키 지문 확인

처음으로 SSH 서버에 연결할 때 클라이언트는 서버의 호스트 키 지문을 확인하라는 메시지를 표시합니다. 이는 중간자 공격을 방지하는 데 도움이 됩니다.

방법: 항상 클라우드 콘솔, 프로비저닝 로그 또는 관리자와 같은 신뢰할 수 있는 출처와 지문을 확인하십시오. 지문이 예기치 않게 변경되면 수락하기 전에 중지하고 조사하십시오.

4. SSH 클라이언트 소프트웨어 업데이트 유지

SSH 클라이언트 소프트웨어(OpenSSH, PuTTY 등)를 최신 상태로 유지하여 최신 보안 패치 및 기능의 혜택을 받으십시오.

고급 보안 조치

기본 단계 외에도 다음 고급 기술을 고려하십시오:

1. 다중 요소 인증

환경이 지원하는 경우 사람의 SSH 액세스에 MFA를 추가하십시오. 이는 일반적으로 SSH 키와 일회용 코드, 푸시 승인 또는 하드웨어 기반 인증을 결합합니다.

도구: PAM 모듈, Duo, 인증 앱 및 하드웨어 보안 키는 모두 SSH MFA 설계의 일부가 될 수 있습니다.

2. Fail2ban

Fail2ban은 로그에서 반복된 실패한 인증 시도를 스캔하고 소스 IP에 대한 임시 방화벽 차단을 추가할 수 있습니다. 로그 경로는 배포판에 따라 다릅니다. Debian 및 Ubuntu는 일반적으로 /var/log/auth.log를 사용하는 반면, 많은 RHEL 계열 시스템은 journald 또는 /var/log/secure를 통해 로그를 기록합니다.

설치: 일반적으로 패키지 관리자를 통해 사용 가능합니다(sudo apt install fail2ban 또는 sudo yum install fail2ban).
구성: /etc/fail2ban/jail.local에서 감옥을 구성하여 SSH 로그를 모니터링하고 차단 시간 및 임계값을 정의합니다.

3. 방화벽 구성

방화벽(ufw, firewalld 또는 iptables 등)을 사용하여 SSH 포트(기본값 또는 사용자 정의)에 대한 액세스를 신뢰할 수 있는 IP 주소 또는 범위로만 제한하십시오.

예시 (ufw):

sudo ufw allow from trusted_ip to any port 22
sudo ufw enable

요점

SSH 보안은 지속적인 습관입니다. 키 기반 인증을 사용하고, 직접 루트 로그인을 비활성화하고, 연결할 수 있는 사람을 제한하고, 개인 키를 보호하고, 호스트 지문을 확인하십시오. 그런 다음 위험이 추가 설정을 정당화하는 곳에 방화벽 제한, MFA 및 무차별 대입 방지를 추가하십시오.