Почему ssh-сервер может рассматривать машину как имеющую локальный адрес, когда sshing к себе через общедоступный IP-адрес?

Я настроил sshd_config на двух машинах A и B одинаково, так что подключение возможно в локальной сети с паролем:

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

Обе машины имеют только частный IPv4, находятся в другой локальной сети и за другим маршрутизатором с другим общедоступным IPv4 и могут быть подключены к общедоступному IP-адресу своего маршрутизатора (порт переадресации извне на частный IP-адрес локальной сети).

Конечно, если я подключил машину к себе или к другой машине в той же локальной сети, используя их локальный (IPv4) адрес, ssh запросит пароль, как и предполагалось. Теперь посмотрим, что происходит при подключении машин через общедоступный IPv4 их маршрутизатора. когда

sshing от A к A с использованием публичного IP-адреса A: запрашивается пароль
sshing от B к B с использованием публичного IP-адреса B. permission denied (publickey)
переход от B к A или от B к A: permission denied (publickey)

Очевидно, что в первом случае (внутри LAN A) sshd совпадает с адресом локальной сети клиента, хотя он передается через общедоступный IP-адрес, а во втором случае (внутри LAN B) он не совпадает. В чем может быть причина такой разницы?

ПРИМЕЧАНИЕ: Использование Match host localhost вместо предыдущего приводит к отказу в разрешении в первом случае (и, конечно, в других случаях), потому что отправка к самому себе через общедоступный IP-адрес маршрутизатора рассматривается от самого A как имеющего частный IP-адрес локальной сети, а не как localhost или общедоступный IP-адрес.

ssh routing ip local-area-network

Описываемый вами поток трафика от внутренней системы A до IP-адреса WAN NAT-маршрутизатора A, на котором происходит перенаправление портов, называется шпилька NAT. (См. Например этот вопрос и ответ для более подробного описания транспортных потоков и опасностей.)

В зависимости от того, как закрепленный NAT был реализован в вашем маршрутизаторе NAT, вы можете увидеть, что исходный адрес SSH-трафика имеет либо:

был изменен на IP-адрес WAN вашего NAT-маршрутизатора (штыревой NAT работает правильно, но поскольку ваше правило Match не видит внутренний IP-адрес, аутентификация пароля отклоняется).
был изменен на IP-адрес LAN вашего NAT-маршрутизатора, внутренний адрес шлюза (волосяной NAT работает правильно, а правило Match работает, потому что оно определяет исходный IP-адрес из диапазона сети LAN)
не изменился и остается внутренним IP-адресом системы (и виртуальный NAT эффективно нарушается, за исключением особого случая трафика, исходящего из той же системы, которая является целью правила переадресации портов. Но ваше правило сопоставления работает, потому что оно определяет LAN IP-адрес вашего сервера.)

Вам нужно проверить (свои журналы) и посмотреть, какой IP-адрес появляется в качестве источника SSH-соединения, чтобы выяснить, что применимо к вашему сценарию тестирования.

Я думаю, что для вашего сценария NAT 1 и 2 реализован по-разному в разных маршрутизаторах NAT A и B, что приводит к такому разному поведению.