sshd공개적으로 사용 가능한 시스템에서 실행하는 것은 맛있는 공격 벡터이므로 최대한 보호해야 한다는 것은 상식입니다 . " PermitRootLogin설정 " 및 "공개 키 인증으로 전환" 과 같은 명백한 조언 외에도 no다음으로 무장한 스크립트 키디의 컴퓨터에 대한 액세스를 제한하는 다음 방법을 찾았습니다 nmap.
- 포트를 22가 아닌 다른 것으로 변경하십시오. 앞서 언급한 내용은 실제로 도움이 되지 않습니다
nmap. - 포트 22를 열어두고 거기에 오는 모든 것을 삭제하고 대신 다음을 사용하여 다른 포트에서 SSH 연결을 수락하십시오.이 목발. 이전 방법보다 낫지만 여전히 방해가 될 뿐입니다.
- 포트 노킹을 설정합니다. 번거롭고아직"노크" 트래픽이 차단될 수 있으므로 완벽하게 안전하지는 않습니다.
내 컴퓨터에 원격으로 액세스할 수 있는 시스템을 설계한다면 다음과 같을 것입니다.
- 임의의 비밀을 생성합니다.
- 연결되어야 하는 두 기계에 수동으로 복사합니다(항문 보존성을 최대화하기 위해 플래시 드라이브를 사용하여 수행할 수도 있음).
- 그만큼첫 번째 패킷(즉, SSH 핸드셰이크 시작) 클라이언트 시스템이 서버로 보내는 것은이미이 비밀로 암호화되었습니다.
- 서버가 이 비밀로 올바르게 암호화되지 않은 패킷을 받으면 자동으로 TCP 연결을 닫습니다.
결과는 그렇군요물리적으로 불가능공격자는 SSH 서비스가 서버에서 실행되고 있다는 사실까지 알아낼 수 있습니다. 내 헤드캐넌에서는이것정확히 "사전 공유 키"가 의미하는 것입니다.
대신 "ssh with pre-shared key"를 검색하려고 하면 에서 로 마이그레이션하는 방법에 대한 기사 링크만 얻을 수 PasswordAuthentication있습니다 PubkeyAuthentication.
답변1
아니요, 그렇지 않습니다. 프로토콜 수준에서 모든 표준 SSHv2 연결은 항상 1) 일반 ASCII의 프로토콜 버전 "배너", 2) 지원되는 모든 암호 및 키 교환 방법을 나열하는 암호화되지 않은 패킷으로 시작됩니다.
3단계부터 시작하면~할 수 있었다PSK와 관련된 사용자 정의 키 교환 방법을 구현합니다(이상적으로는게다가일반적인 동적 DH 키 교환). 그러나 이를 위해서는 사용자 정의 클라이언트뿐만 아니라 사용자 정의된 sshd 데몬도 필요합니다. 현재 OpenSSH, PuTTY, Bitvise WinSSHD 또는 제가 지금까지 사용해 본 다른 SSHv2 구현에는 이러한 기능이 없습니다.
가장 간단한 대안은 VPN 시스템을 사용하는 것입니다. PSK를 자주 지원하기 때문입니다(그러나 초기 키 교환을 보호하기 위한 HMAC 키로 더 일반적입니다. 실제 데이터 채널을 암호화하기 위한 AES 키가 아니라 "순방향 보안"을 잃게 됩니다). " 특징). VPN 서비스가 실행되면 직접 SSH 연결을 완전히 비활성화할 수 있습니다. 말 그대로 더 이상 수신하지 않는 SSHD를 누구도 발견할 수 없습니다.
예를 들어, 널리 사용되는 것 중 WireGuard와 OpenVPN은 사전 공유된 MAC 키를 사용하여 모든 연결 시도를 인증하도록 지원합니다. 둘 다 초기 협상에 UDP를 사용하므로 단순히 응답하지 않습니다.조금도확인할 수 없는 패킷으로 처리하여 서비스를 검색할 수 없도록 만듭니다. (WireGuard는 PSK 모드 없이도 이미 그렇게 하고 있다고 생각하지만...) OpenVPN은 이 기능을 "tls-auth" 모드라고 부릅니다. 이를 "정적 키" 모드와 혼동하지 마십시오.
여기에서 IPsec AH를 사용할 수도 있습니다. 완전히 정적 인증 키만 필요한 경우 동적 IKE 핸드셰이크가 전혀 필요 없이 명령만으로 양쪽 끝에서 수동으로 SA를 구성할 수 있습니다 ip xfrm. 하지만 짜증날 수 있습니다.
또 다른 대안으로 일부 운영 체제는 다음을 지원합니다.TCP 수준TCP-MD5(RFC1321) 또는 TCP-AO(RFC5925)를 사용한 사전 공유 키 인증. 이는 단일 소켓만 필요하기 때문에 SSH 소프트웨어를 해킹하기 쉬울 것입니다. 그러나 이는 다시 사용자 정의 클라이언트 영역에 들어가게 됩니다. 또한 OS 수준 지원은 열악합니다. 사람들이 BGP와 함께 사용하기를 원하기 때문에 TCP-MD5는 여전히 지원되지만 TCP-AO에 대한 지원은 사실상 존재하지 않을 수 있습니다.