0

I configured sshd_config on two machines A and B in the same way such that connection is possible in local network with password :

Match address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
  PasswordAuthentication yes

Both machines have only private IPv4, are in a different LAN and behind a different router with a different public IPv4 and can be connected with the public IP of their router (forwarding port from outside to LAN private IP).

Of course if I ssh a machine to itself or to another machine in the same LAN by using their local (IPv4) address, ssh asks for password, as intended. Now see what happens when connecting machines over their router's public IPv4. When

  1. sshing from A to A by using A's public IP : password is asked

  2. sshing from B to B by using B's public IP : permission denied (publickey)

  3. sshing from B to A, or from B to A : permission denied (publickey)

Obviously, in the first case (inside LAN A) sshd matches the client's local network address though it is sshing through public IP, while in second case (inside LAN B), it is not matched . What could be the cause of this difference ?

NOTE: Using Match host localhost instead of previous one, leads to permission denied in first case (and for other cases of course), because A sshing to itself through router public IP is seen from A itself as having a private LAN IP, not as localhost or public IP.

hello world
  • 103
  • 2
  • 8
  • Now all is clear. After looking to the accepted response and in `/var/log/auth.log` it appears that client has LAN IP address of router in case 1 (LAN A) and WAN IP address of router in case 2 (LAN B). So the address matched by sshd in the first case was the router's local address and not the client's local address as I first thought. – hello world Jun 15 '19 at 01:17

1 Answers1

1

The traffic flow you describe, from internal system-A to WAN IP-address of NAT-router-A where port-forwarding happens, is called hair-pin NAT. (See for instance this Q&A for a more lengthy description of the traffic flows and perils.)

Depending on how hairpin NAT has been implemented in your NAT router, you may see that the source address of the SSH traffic has either :

  • been changed to the WAN IP-address of your NAT router (hair-pin NAT works correctly, but since your Match rule doesn't see an internal IP-address password authentication is rejected.)
  • been changed to the LAN IP-address of your NAT router, the internal gateway address (hair-pin NAT works correctly, and the Match rule works because it detects a source IP-address from the LAN network range)
  • not changed and remains the internal IP-address of system (and hair-pin NAT is effectively broken, except in the special case of traffic that originates from the same system that is the target of the port-warding rule. But your Match rule works because it detects the LAN IP-address of your server.)

You need to check (your logs) and see which IP-address appears as the origin of the SSH connection to find out what applies to your test scenario's.

I think that for your scenario's 1 & 2 hair-pin NAT is implemented differently in the different NAT routers A& B resulting in that different behaviour.

HBruijn
  • 72,524
  • 21
  • 127
  • 192