☰

로그인 후 SSH 로그인이 즉시 삭제되는 이유는 무엇입니까?

tag-icon • tag-icon linux ubuntu ssh
로그인 후 SSH 로그인이 즉시 삭제되는 이유는 무엇입니까?

다음과 같은 명령을 사용하여 SSH(비밀번호 없음)를 통해 MacBook Air(MacOS 10.14.6)에서 우분투 컴퓨터(16.04.6)에 연결하려고 합니다.

ssh aaa.bbb.ccc.ddd

항상 잘 작동했고, 메시지를 받고 원격 컴퓨터에서 작업을 시작할 수 있었습니다.

그러나 약 일주일 동안 로그인 프로세스, 신규 사용자, 비밀번호 변경, 키 변경, OS 업그레이드, 변경 등을 변경하지 않은 채 더 이상 작동하지 않습니다. .profile또한 확인 .bashrc했지만 거기에는 아무것도 없습니다. , 우분투 시스템과 Mac을 재부팅했지만 아무런 변화가 없었습니다./etc/hosts.allow/etc/hosts.deny

로그인에 성공한 순간 메시지가 뜹니다

Last login: ... from www.xxx.yyy.zzz
Connection to aaa.bbb.ccc.ddd closed

무슨 일이 일어나고 있는지 어떻게 디버깅할 수 있나요?

부록

확인하면 /var/log/auth.log다음 항목이 표시됩니다.

Oct 16 07:02:38 mac353 systemd-logind[1173]: New session 11 of user alex.
Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user
Oct 16 07:02:38 mac353 sshd[11834]: Disconnected from www.xxx.yyy.zzz port 61437

답변1

Oct 16 07:02:38 mac353 sshd[11834]: Received disconnect from www.xxx.yyy.zzz port 61437:11: disconnected by user

www.xxx.yyy.zzz현재 MacBook Air의 IP 주소가 정확 합니까 ?

동일한 IP 주소를 사용하는 네트워크에 다른 시스템이 있을 수 있습니다. 정상적으로 연결을 시작할 수 있지만 모든 응답은 IP 주소 충돌에 참여하는 두 시스템 모두에 무작위로 전달되므로 서버는 나가는 패킷 중 일부를 다시 보내야 할 수 있습니다. 일반적으로 실제로 연결을 설정하려고 시도하는 시스템은 더 빨리 응답하므로 초기 패킷 몇 개에 대해서는 정상적으로 작동하는 것처럼 보일 수 있습니다.

그러나 결국 충돌하는 시스템의 TCP/IP 드라이버는 "이 트래픽은 무엇입니까? 현재 활성화된 TCP 연결이 없습니다."라고 생각할 것입니다. 그리고 가짜로 보이는 트래픽의 소스, 즉 서버로 TCP 재설정 패킷을 다시 보냅니다. 충돌하는 시스템이 MacBook과 동일한 IP 주소를 갖기 때문에 서버는 TCP 재설정이 실제로 연결에 속하지 않는다는 것을 알 수 없으므로 서버는 TCP 재설정이 다음을 의미한다고 가정합니다.너연결을 끊고 싶었습니다. TCP 재설정 패킷 전송은 일반적으로 TCP/IP 드라이버 내에서 우선순위가 낮은 작업이기 때문에 즉시 발생하지 않습니다.

이는 IP 주소 충돌의 매우 일반적인 증상입니다.

충돌하는 시스템을 찾으려면 네트워크 스위치(관리형 스위치인 경우)의 MAC 주소 테이블이나 로컬 네트워크 세그먼트의 WiFi AP를 살펴보세요. IP 주소가 MacBook에 속하지 않은 MAC 주소와 연결되어 있는 경우 충돌하는 시스템의 MAC 주소를 찾은 것입니다. 유선 네트워크에서는 해당 MAC 주소를 확인한 스위치 포트를 확인한 다음 케이블의 다른 쪽 끝에 무엇이 있는지 확인할 수 있습니다.

관리되는 스위치가 없거나 해당 스위치에 액세스할 수 없는 경우 자신의 IP 주소를 ping하여 중복 응답을 받는지 확인할 수 있습니다. 또는 arping명령줄 도구를 사용하여 ARP 패킷에 대해 동일한 작업을 수행할 수 있습니다. 그러면 핑에 응답하지 않는 시스템도 포착할 수 있습니다.

답변2

이 문제에 대한 해결책은 완전히 다른 컨텍스트에 설치된 set -e파일에 있었습니다 . /etc/profile.d해당 파일의 이름을 바꾼 후 ssh로그인이 다시 작동했습니다.

`set -e`

명령에 오류가 있는 경우 스크립트 실행을 중지합니다(여기를 보아라) 일부에서는 나쁜 습관으로 간주됩니다.

관련 정보