서버 Y에서 사용자 A는 서버 X로 SSH를 시도하고 연결이 거부되었습니다. 서버 Y에서 사용자 B는 서버 X로 SSH를 시도하고 통과가 허용됩니다. 서버 Y에서 루트는 ssh를 시도하고 연결이 거부되었습니다. 문제는 100% 반복 가능하고 100% 일관성이 있습니다.
처음 두 개는 ACL에 문제가 있음을 시사하지만 볼 수 있는 권한은 없지만 두 사용자 모두에 대한 설정이 동일하다고 들었습니다. 또한 성공적으로 삭제되고 읽혀졌습니다. 그러나 루트는 ACL의 영향을 받지 않으며 연결할 수도 없습니다.
이 문제가 있는 두 대의 서버가 있으며, ifconfig(IP 주소 등 제외)와 이 문제가 발생하지 않는 라우팅 테이블에서 동일한 설정을 가진 다른 많은 서버가 있습니다.
서버 Y의 연결을 찾는 서버 X의 tcpdump는 사용자 A가 연결을 시도할 때 아무것도 표시하지 않지만 사용자 B가 연결을 시도할 때 많은 정보를 생성합니다. 이는 사용자 A가 SSH를 시도할 때 서버 X가 아무것도 수신하지 않음을 나타냅니다.
모든 서버가 RedHat을 실행 중입니다.
서버 Y에 문제가 있다고 가정합니다. 그런데 무엇을 찾아야 합니까? 사용자 이름 기반 연결 문제가 서버 사이의 방화벽에 나타날 수 있습니까? 아니면 그러한 방화벽이 사용자 이름을 기반으로 하지 않습니까?
편집 - 사용자 A와 B 모두 서버 Y에서 그룹의 다른 많은 서버로 SSH를 통해 연결할 수 있습니다. 문제가 있는 것은 단지 서버 X입니다. Ssh-ing은 RSA를 사용하지 않지만 처음에는 서버 Y에 로그인합니다.
답변1
사용자 A의 .ssh/config파일을 확인하십시오. Host문제의 호스트 이름에 대한 항목이 해당 파일에 있을 수 있으며 이로 인해 ssh해당 호스트 이름에 대해 다른 포트나 IP 주소를 시도하게 됩니다. 예를 들어, .ssh/config다음 줄이 있는 경우:
Host a.example.com
Hostname b.example.com
Port 42
그런 다음 "ssh a.example.com"을 실행하면 b.example.com 포트 42에 연결을 시도합니다.
또 다른 가능성은 사용자 A가 어떤 이유로 다른 "ssh" 프로그램을 실행하고 있다는 것입니다. 예를 들어 그의 명령 경로가 다르고 대체 프로그램이 예상대로 작동하지 않기 때문입니다.
편집: 또 다른 가능성이 없는 가능성은 네트워크에 동일한 IP 주소에 응답하는 두 개의 호스트가 있다는 것입니다. 실패한 연결 요청이 잘못된 서버로 전달되어 응답을 받고 있습니다. 이로 인해 사용자별로 일관되게 연결이 실패하는 것이 아니라 무작위로 연결이 실패하게 되므로 설명하는 동작과 실제로 일치하지 않습니다.
답변2
이 문제가 해결되었습니다.
두 가지 액세스 목록이 있습니다. 첫 번째는 사용자가 연결할 수 있는 서버를 나열하는 ACL(일반적으로 알려진 것)이고, 두 번째는 특정 사용자에게만 액세스가 허용되는 이전에 알려지지 않은 서버 목록입니다. 즉, ACL의 반대입니다. . 이 제한 목록에서 서버가 제거되면 모든 사용자에게 액세스가 허용되었습니다.
귀하의 모든 의견과 지도에 감사드립니다.