내부 서버끼리는 SSH 가 되는데 로컬 PC 의 터미널 클라이언트로만 붙으면 비밀번호를 받은 뒤 Access denied 가 반복된다. PermitRootLogin yes, PasswordAuthentication yes 가 모두 켜져 있고 faillock --user root 도 비어 있다.
결정적인 단서는 서버의 journalctl -u sshd -f 에 그 시도가 한 줄도 안 찍힌다는 것이다. 비밀번호 프롬프트까지 받았는데 sshd 가 그 연결을 본 적이 없다면, 붙고 있는 곳이 이 서버가 아니다.
tcpdump -nn -i any 'tcp port 22 and host <클라이언트 IP>'
이 창을 띄워 둔 채 접속을 시도한다.
| 결과 | 의미 |
|---|---|
| 패킷이 잡히는데 로그에 안 찍힘 | sshd 가 무시하는 드문 경우 |
| 패킷이 아예 안 잡힘 | 연결이 이 서버에 도달조차 못 한다 |
후자라면 IP 충돌, 내 PC 의 ARP 캐시 잔존, 중간 장비의 NAT · 포트포워딩 중 하나다.
arping -D -I ens6f0np0 192.168.10.51
ip link show ens6f0np0 | grep ether
arping -D 는 중복 주소 탐지 모드다. 응답이 오면 같은 IP 를 쓰는 다른 장비가 있다는 뜻이고, 응답에 찍힌 MAC 이 자기 인터페이스 MAC 과 다르면 충돌이 확정된다.
Unicast reply from 192.168.10.51 [00:0C:29:21:CB:AE]
MAC 앞 세 바이트는 제조사 식별자(OUI) 다. 00:0C:29 는 VMware 이므로 같은 망의 VMware VM 하나가 그 IP 를 쓰고 있다는 것까지 바로 읽힌다. 물리 Dell 서버가 VMware MAC 을 가질 일은 없다. vCenter · ESXi 에서 그 MAC 으로 검색하면 어떤 VM 인지 나온다.
내 PC 쪽 ARP 캐시가 옛 MAC 을 기억하는 경우도 같이 정리한다.
arp -a | Select-String "192.168.10.51"
arp -d *
ipconfig /flushdns
상대 장비의 IP 를 바꾸거나 내리는 것이 정공법이다. 권한이 없으면 내 서버의 IP 를 바꾼다. 반드시 콘솔에서 작업한다. SSH 로 들어와 IP 를 바꾸면 자기 세션이 끊긴다.
nmcli connection show # NAME 컬럼 확인. 인터페이스명과 다를 수 있다
ip addr show ens6f0np0
ip route
arping -D -I ens6f0np0 -c 3 192.168.10.52 # 새 IP 가 비었는지 먼저 확인
nmcli connection modify "<NAME>" \
ipv4.addresses 192.168.10.52/24 \
ipv4.gateway 192.168.10.1 \
ipv4.dns "192.168.10.1" \
ipv4.method manual
nmcli connection down "<NAME>" && nmcli connection up "<NAME>"
새 IP 도 arping -D 로 비어 있는지 확인하고 쓴다. 확인 없이 고르면 같은 문제를 반복한다.