#2355 Issue closed: ssh drops connection with "POSSIBLE BREAK-IN ATTEMPT" when another host with same IP appears

Labels: support / question, fixed / solved / done, not ReaR / invalid

IT-Guy-1973 opened issue at 2020-04-09 04:30:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):

  • Description of the issue (ideally so that others can reproduce it):

Hello REAR users,

I had this bizzare issue related to rear.

I took a backup of the root disk on a RedHat linux system with IP 192.168.1.150/24 (Server A). The backup was stored in an NFS server with IP 192.168.1.125/24. I created a new VM and started restoring the rear backup of server 192.168.1.150/24 on this new VM (Server B). The restore resulted in the new VM having the same IP 192.168.1.150/24 hence resulting in an IP conflict.

I was using SSH to connect to the original server (Server A) from my desktop with IP 192.168.1.200/24. Suddenly the connection dropped to "Server A" and I saw the message "Apr 8 10:12:47 ServerA sshd[2448]: Address 192.168.1.200 maps to user-pc, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!"

I know this is related to the duplicate IP. But what I do not understand is the process how this error was generated. Because between my desktop (user-pc 192.168.1.200/24) and ServerA nothing changed. It was just that there was another server (ServerB) that had the same IP but the error reported is between user-pc and ServerA.

Can someone able to explain this?

Regards,
IT-Guy

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

```
verbatim content
```

jsmeix commented at 2020-04-09 08:41:

@IT-Guy-1973
I had experienced the same or basically the same
but I am neither a networking expert nor a SSH expert
so I cannot explain why what seems to be a single
established ssh TCP connection breaks.
I guess what seems to be a single established TCP connection
is not actually a single established TCP connection so the
duplicate new IP gets somehow noticed.
I even assume that detection is intentional in ssh to be more safe
against possibly malicious users in the network that use same IPs.

Some general information FYI:

By default ReaR tries to recreate the original system as much as possible
exactly as it was before so the recreated system has the same IP as the
originial system had.
This is because by default the recreated system has the same config files
(that are restored "as is" from the backup) as the originial system had.

By default even the ReaR recovery system uses the same IP as the
originial system had. The reason is that network access should be the
same as when "rear mkbackup" was run because during "rear recover"
the same network is usually needed to access the backup to restore it.

But in my test cases all works well for me when I use DHCP in the
ReaR recovery system via USE_DHCLIENT="yes" cf.
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L2611
(plus SSH_ROOT_PASSWORD as needed)
so that there is no IP address conflict while the ReaR recovery system runs
and after "rear recover" finished one can still from within the running
ReaR recovery system do chroot /mnt/local into the recreated system
and adapt the network config as needed before the recreated system
is booted.

You may also have a look at "the current workaround to migrate the
networking setup on the recreated tartget system" in
https://github.com/rear/rear/issues/2310#issuecomment-595149640

In general regarding adapting the network config of the recreated system see
https://github.com/rear/rear/issues/2312

gdha commented at 2020-04-12 06:13:

@IT-Guy-1973 That was a normal reaction of SSH as suddenly there were 2 ARP MAC addresses for the same IP address. It is a built-in security ssh thing.

IT-Guy-1973 commented at 2020-04-13 02:55:

Thank you, @jsmeix and @gdha for your replies.

I was trying to understand exactly how SSH was rejecting the traffic from a previously established connection between two computers that did not have any changes done to the network configurations. The only change was adding a duplicate IP and SSH should have rejected the new duplicate IP MAC, not the established ones.

Regards,
Niranjan

jsmeix commented at 2020-04-14 12:16:

I think the question is sufficiently answered as far as we can here.
We cannot explain here how exactly ssh is working internally.
I think you need to ask for that on a ssh developer forum.

IT-Guy-1973 commented at 2020-04-14 17:44:

Yes, it has. Thank you!! @jsmeix @gdha

[Export of Github issue for rear/rear.]