나는 데비안에 SSH를 사용하여 공개 키 로그인만 허용하는 일반적인 관행을 따랐고, 어떻게든 실수로 ~/.ssh/ 폴더의 권한을 변경했습니다(루트가 소유한 것 같습니다). 그 후 openSSH가 로그인을 거부했습니다! (그리고 서버는 원격/KVM 콘솔 없이 다른 국가에 있었습니다)
나는 이 설정이 매우 취약하다고 생각합니다. 이를 방지할 수 있는 방법이 있나요? 아니면 다음 로그인 시 경고 메시지를 표시할 수 있나요?
해결책이 없다면 다른 사람들이 뭐라고 하든 백업용으로 강력한 로그인 비밀번호를 설정해야 합니다.
유사한 잠금 질문을 찾았지만 iptable/구성 변경이 근본 원인이었습니다. SSH 및 iptables 구성 시 잠김 방지 구성을 변경하지 않았으므로 잠금이 예상되지 않았습니다.
답변1
호스트를 복구하려면 대체 액세스 방법이 필요합니다. 인터넷을 통한 ssh를 사용하려면 네트워크 액세스, 방화벽 허용 규칙, sshd 실행 및 구성, 보안 키 파일 등이 정상적으로 작동해야 합니다. 이러한 중단 중 하나라도 들어갈 수 없습니다. 가장 안정적인 대역 외 액세스는 작동하는 호스트의 IP 네트워킹에 의존하지 않습니다.
VM인 경우 종료하고 디스크를 작동 중인 다른 인스턴스에 연결하여 복구할 수 있습니다. 이상적이지는 않지만 디스크에 대한 액세스 권한만 필요합니다.
데이터의 오프호스트 백업을 통해 새로운 교체 호스트를 생성할 수 있습니다. SSH 액세스가 손실되었기 때문에 파괴하고 재구축하는 것이 어리석은 것처럼 보일 수 있지만 여전히 복구 옵션으로 남아 있습니다.
우선 문제를 방지하기 위해 sshd 구성( sshd -T -fOpenSSH의 경우) 구문 검사로 모든 것을 포착할 수는 없습니다. 포트 번호만 제외하고 모든 것이 동일하게 다른 포트에서 다른 SSHD를 시작하여 엔드투엔드 테스트를 수행할 수 있습니다. 원격으로 연결하여 제대로 작동하는지 테스트하세요. 불행하게도 이러한 주의를 기울여도 실수로 SSH 파일을 보안 해제하게 만드는 홈 디렉터리의 권한 변경과 같은 의도하지 않은 일을 포착할 수는 없습니다. 또는 키워드 ssh_config로 인해 효과가 변경될 수 있는 IP 변경 Match.
비밀번호는 여전히 끔찍한 인증 메커니즘입니다.