SSH 보안에는 광범위한 가능한 기술이 포함되지만 모든 기술이 모든 환경에 동일하게 실용적인 것은 아닙니다. 이 기사의 권장 사항은 구현의 용이성과 강력한 보호의 균형을 이루는 널리 인정되고 영향력 있는 방법입니다. 이러한 권장 사항은 NIST, CERT 및 OpenSSH 프로젝트와 같은 조직에서 설정한 표준에서 가져온 것이며 SSL.com이 디지털 인증서 보안에 적용하는 핵심 원칙(키 보호, 강력한 암호화 사용 및 권한 있는 액세스 제한)을 반영합니다.
이러한 기본적인 모범 사례를 설정한 후에는 필요에 따라 인증서 기반 SSH, 포트 노킹, VPN을 통한 SSH와 같은 더욱 고급 전략을 탐색할 수 있습니다.
1. 비밀번호 대신 키 기반 인증 사용
무엇이다 :
비밀번호 로그인을 암호화된 공개/비공개 키 쌍으로 대체합니다. 공개 키는 서버에 저장되고, 개인 키는 로컬 머신에 저장됩니다.
더 안전한 이유:
- 비밀번호는 무차별 대입 공격에 취약합니다.
- 공격자는 비밀번호를 추측하는 것보다 훨씬 더 어려운 물리적으로 개인 키를 얻어야 침입할 수 있습니다.
구현 방법:
키 쌍 생성
Linux 또는 macOS에서는 터미널을 열고 다음을 실행합니다.
ssh-keygen -t ed25519
ssh-keygen -t RSA -b 4096
공개 키를 서버에 복사하세요
ssh-copy-id 명령(Linux/macOS)을 사용하면 공개 키를 쉽게 전송할 수 있습니다.
ssh-copy-id 사용자@서버_주소
ssh-copy-id를 사용할 수 없는 경우 id_ed25519.pub(또는 id_rsa.pub) 파일의 내용을 수동으로 서버의 ~/.ssh/authorized_keys 파일에 추가하세요.
비밀번호 인증 비활성화
/etc/ssh/sshd_config에서 다음을 설정합니다.
비밀번호 인증 번호
SSH 서비스를 다시 시작합니다.
sudo는 systemctl 다시 시작 SSH
디지털 인증서를 관리하는 것처럼 SSH 키 기반 인증은 올바른 개인 키를 가진 사람만 연결을 설정할 수 있도록 보장합니다.
2. 루트 로그인 비활성화
무엇이다 :
루트 사용자가 SSH를 통해 직접 로그인하는 것을 방지합니다.
더 안전한 이유:
- 루트 계정은 무제한 권한을 보유하고 있어 공격자에게 매력적인 대상입니다.
- 직접 루트 액세스를 비활성화하면 공격자는 키나 비밀번호뿐만 아니라 유효한 사용자 이름도 추측해야 합니다.
구현 방법:
/etc/ssh/sshd_config에서 다음을 찾거나 추가하세요.
PermitRootLogin 아니요
SSH 다시 시작:
sudo는 systemctl 다시 시작 SSH
이 단계는 가장 강력한 계정에 쉽게 접근할 수 없도록 하여 공격 표면을 효과적으로 좁힙니다.
3. 강력한 암호화 및 MAC 알고리즘 적용
무엇이다 :
SSH를 사용하면 데이터 암호화 및 데이터 무결성 확인에 사용할 암호 및 MAC(메시지 인증 코드)를 지정할 수 있습니다.
더 안전한 이유:
- 오래되거나 취약한 알고리즘(예: DES, RC4)은 암호화 공격에 취약할 수 있습니다.
- 최신 암호(AES-256 등) 및 강력한 MAC(HMAC-SHA2 등)을 사용하면 세션 데이터를 기밀로 유지하고 변조 방지할 수 있습니다.
구현 방법:
/etc/ssh/sshd_config에서 암호/MAC 목록을 추가하거나 업데이트하세요.
암호 aes256-ctr, aes192-ctr, aes128-ctr
MAC hmac-sha2-256,hmac-sha2-512
SSH 다시 시작:
sudo는 systemctl 다시 시작 SSH
SSH에 대한 암호화를 최신 상태로 유지하는 것은 보안 프로토콜과 암호가 사용되는 것을 보장하는 것만큼 중요합니다. TLS.
4. SSH(및 시스템)를 최신 상태로 유지하세요
무엇이다 :
OpenSSH를 비롯한 운영 체제에 정기적인 보안 패치를 적용하세요.
더 안전한 이유:
- 오래된 소프트웨어에는 알려진 취약점이 포함되어 있는 경우가 많습니다.
- 공격자는 종종 패치되지 않은 악용을 통해 이전 버전을 표적으로 삼습니다.
구현 방법:
Debian 또는 Ubuntu 기반 시스템의 경우:
sudo는 apt-get 업데이트 && sudo는 apt-get 업그레이드
CentOS, Fedora 또는 RHEL 기반 시스템의 경우:
sudo는 YUM 업데이트
네트워크 어플라이언스나 다른 하드웨어에서 SSH를 실행하는 경우 펌웨어 업데이트도 확인하세요.
5. 2단계 또는 다중 요소 인증(XNUMXFA/MFA) 구현
무엇이다 :
비밀번호나 키 외에 다른 것(예: 휴대전화의 일회용 코드)을 요구함으로써 보안을 한 단계 더 강화합니다.
더 안전한 이유:
- 공격자가 SSH 키를 얻었더라도 로그인하려면 여전히 두 번째 요소가 필요합니다.
- 신원 정보 도난으로부터 방어하는 데 도움이 됩니다.
구현 방법:
MFA 도구 설치 및 구성
예를 들어, Linux 서버에 설치하고 PAM(Pluggable Authentication Modules) 모듈로 설정할 수 있습니다. 배포판에 맞는 설치 지침을 따르세요.
/etc/pam.d/sshd 및 /etc/ssh/sshd_config를 편집합니다.
- Google Authenticator 또는 다른 MFA 모듈 활성화
- ChallengeResponseAuthentication을 yes로 설정하고 AuthenticationMethods를 publickey,keyboard-interactive로 설정합니다(또는 환경에 맞는 조합).
SSH 다시 시작:
sudo는 systemctl 다시 시작 SSH
6. 로깅 및 모니터링 활성화
무엇이다 :
SSH 로그인 이벤트를 캡처하고, 의심스러운 활동을 추적하며, 문제가 발생하면 알림을 받습니다.
더 안전한 이유:
- 침입 시도는 반복적인 로그인 실패나 무단 작업으로 로그에 표시되는 경우가 많습니다.
- 조기 감지를 통해 손상이 발생하기 전에 IP를 차단하거나 구성을 변경하여 신속하게 대응할 수 있습니다.
구현 방법:
로그의 자세한 정도 증가
/etc/ssh/sshd_config에서 다음을 설정합니다.
LogLevel VERBOSE
집계 로그
- 같은 도구 , 및 로그 수집 및 중앙화에 도움
- A 고급 분석 및 경고를 제공할 수 있습니다
침입 방지 도구 사용
로그 파일을 검사하고 비밀번호 오류가 너무 많은 등 악의적인 징후가 나타나는 IP를 차단합니다.
7. 액세스 제어 및 제한 구현
무엇이다 :
SSH에 누가, 어디서 연결할 수 있는지 제한하여 승인되지 않은 또는 과도한 인바운드 요청을 방지합니다.
이를 수행하는 방법:
방화벽 제한
알려진 또는 신뢰할 수 있는 IP 주소에서만 SSH를 허용합니다. 예를 들어, ufw가 있는 Linux에서:
sudo는 ufw에서 허용 192.168.1.0/24 모든 포트로 22
포트 구성
비표준 포트(예: 2222)에서 SSH를 실행하면 자동 스캐닝 시도를 줄일 수 있습니다. 실제 보안 조치를 대체하는 것은 아니지만 노이즈를 줄일 수 있습니다.
사용자/그룹 제한
/etc/ssh/sshd_config에서 다음을 지정하세요.
AllowUsers 앨리스 밥
or
AllowGroups sshadmins
8. SSH 키 암호문구 및 보안 키 저장소 사용
무엇이다 :
개인 키를 암호문구로 암호화하면 컴퓨터가 손상되더라도 키 자체는 바로 사용할 수 없습니다.
더 안전한 이유:
- 암호가 없는 도난당한 키 파일은 즉각적인 액세스를 허용할 수 있습니다.
- 암호문구는 로컬 키에 대한 추가 암호화 계층 역할을 합니다.
구현 방법:
키 생성 중 암호 문구 설정
ssh-keygen -t ed25519
(암호를 입력하라는 메시지가 표시됩니다.)
키 파일을 보호하세요
.ssh 폴더와 키 파일에 대한 권한을 제한합니다.
chmod를 700 ~ / .ssh
chmod를 600 ~/.ssh/id_ed25519
하드웨어 보안 모듈(HSM) 또는 토큰을 고려하세요
대규모 조직의 경우 키 저장을 위한 전용 하드웨어를 사용하면 소프트웨어 기반 도난이나 맬웨어의 위험을 완화할 수 있습니다.
결론
SSH 보안은 보호 계층으로 요약됩니다. 키 기반 인증을 구현하고, 직접 루트 액세스를 비활성화하고, 강력한 암호화를 사용하고, 최신 상태를 유지하고, 다중 요소 인증을 요구하고, 로그를 모니터링하고, 액세스를 제한하고, 암호로 키를 보호하면 가장 일반적인(그리고 가장 심각한) 위험을 다룰 수 있습니다.
