SSH 키를 사용하는 몇 명의 사용자로 CentOS 8 서버를 설정했는데 며칠 전 현재 어떤 사용자와도 로그인하는 데 문제가 없었습니다. (루트 로그인과 마찬가지로 비밀번호 확인도 비활성화됩니다.)
오늘 PuTTY와 WinSCP를 사용하여 로그인했는데 소름이 돋았습니다.
서버가 우리 키를 거부했습니다
이는 모든 사용자에게 발생합니다. sshd키를 거부하는 지점에 이르렀으므로 분명히 작동하는 것 같습니다. 로그를 자세히 살펴보면 다음과 같은 내용이 표시됩니다.
서버는 publickey, gssapi-keyex, gssapi-with-mic 인증 방법을 제공합니다.
sshd이는 정상적으로 작동하고 있음을 나타냅니다 .
Pageant에 로드된 키를 사용하여 로그인을 시도했고, Pageant를 우회하고 PuTTY 및 WinSCP에서 직접 키를 로드하려고 시도했지만 키가 여전히 거부되었습니다. 예, 올바른 키이며 변경되지 않았습니다.
우연히 백업 응용 프로그램을 실행하고 있었기 때문에 서버의 파일에 어떤 변경 사항이 발생했는지 확인할 수 있었습니다. 이 .ssh/authorized_keys파일은 수정되지 않았 음을 확인할 수 있습니다 . 아니요 sshd_config, 저도 다운로드해서 확인해 봤습니다.
마지막으로 로그인한 것은 며칠 전이었고 하나를 만들었는데 dnf update이것이 어떤 영향을 미칠지는 모르겠습니다.
이 문제의 원인은 무엇입니까?
답변1
문제는 /home권한입니다. 나는 은밀한 의심을 품었지만 어떻게 문제가 발생할 수 있는지 이해하지 못했기 때문에 그 아이디어를 고려하기를 거부했습니다. 제 기억으로는 디렉토리 항목을 처리하는 동안 잘못된 명령을 입력한 기억이 어렴풋이 있습니다 setfacl. ACL실수로 하나를 만들었는데, 이로 인해 필요한 setfacl -Rn [...] /home권한이 엉망이 되었습니다.sshd$home/.ssh/authorized_keys
이는 모든 사용자가 잠겨 있음을 의미합니다. PasswordAuthentication로 설정하면 No서버에 들어갈 수 없습니다. 그럼 어떻게 해결했나요? 백업해 주신 Acronis에게 감사드립니다. sshd_config몇 달 전 으로 PasswordAuthentication설정되어 post 명령으로 Yes추가되었을 때로 되돌아 갔습니다 . reboot그런 다음 서버를 다시 시작한 후 비밀번호로 로그인하고 setfacl -b올바른 위치에서 ACL을 삭제하면 모든 것이 정상으로 돌아왔습니다.
운이 좋았지만 몇 가지 재해 시나리오를 위해 특별히 구성된 백업이 있는데, 그 중 하나에는 오래 전의 파일이 필요합니다.
PS: 친절한 조언입니다. 지금 백업 전략을 다시 확인하고 안정적인 솔루션에 투자하세요. 엔터프라이즈급 백업이 없으면 서버의 하드 드라이브를 새 서버로 이동하고 웹 애플리케이션을 복원하거나 복구 모드로 부팅하거나 기타 지루하고 불확실한 방법을 시도하는 데 며칠 동안 갇혀 있을 수 있습니다.