Назад | Перейти на главную страницу

Почему SSH сообщает «сбой при проверке обратного сопоставления getaddrinfo», даже если установлена ​​запись PTR?

Я пытаюсь настроить кластер с использованием частной сети в подсети 10. Одна машина имеет два интерфейса: один для подключения к обычной сети, а другой для подключения ко всем узлам в подсети 10. Этот компьютер с CentOS 6 (назовем его «zaza.domain.com») запускает DHCP, DNS, и в настоящее время оба они управляются Cobbler, что может быть, а может и не быть частью проблемы (хотя его отключение и выполнение всех действий вручную по-прежнему вызывает у меня проблемы).

Если я использую SSH в zaza, а затем пытаюсь подключиться по SSH из zaza в node1, я получаю следующее предупреждающее сообщение:

[root@zaza ~]# ssh node1
reverse mapping checking getaddrinfo for node1.cluster.local [10.69.0.1] failed - POSSIBLE BREAK-IN ATTEMPT! 

Я все еще получаю запрос на ввод пароля и могу войти в систему ОК.

Я знаю из sshd предупреждение: "ВОЗМОЖНАЯ ПОПЫТКА ВЗЛОМА!" для неудачного обратного DNS и «ВОЗМОЖНА ПОПЫТКА ВКОЛА!» в / var / log / secure - что это значит? и множество других поисков того, что причиной этой ошибки обычно является неустановленная запись PTR. Однако он установлен - учтите следующее:

[root@zaza ~]# nslookup node1.cluster.local   
Server:     10.69.0.69   
Address:    10.69.0.69#53

Name:   node1.cluster.local   
Address: 10.69.0.1

[root@zaza ~]# nslookup 10.69.0.1   
Server:     10.69.0.69   
Address:    10.69.0.69#53

1.0.69.10.in-addr.arpa  name = node1.cluster.local.

IP-адрес 10.69.0.69 является вторым интерфейсом zaza.

Если я попробую другой инструмент, например dig, чтобы просмотреть запись PTR, я получу следующий результат:

[root@zaza ~]# dig ptr 1.0.69.10.in-addr.arpa    
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.4 <<>> ptr 69.0.69.10.in-addr.arpa
;; global options: +cmd
;; Got answer:   
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29499   
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;1.0.69.10.in-addr.arpa.    IN  PTR

;; ANSWER SECTION:  
1.0.69.10.in-addr.arpa. 300 IN  PTR node1.cluster.local.

;; AUTHORITY SECTION:  
10.in-addr.arpa.    300 IN  NS  zaza.cluster.local.

;; ADDITIONAL SECTION:   zaza.cluster.local.    300 IN  A   10.69.0.69

;; Query time: 0 msec
;; SERVER: 10.69.0.69#53(10.69.0.69)
;; WHEN: Wed Mar  1 17:05:44 2017   
;; MSG SIZE  rcvd: 110

Мне кажется, что запись PTR установлена, поэтому я не знаю, почему SSH выдает шипение, когда я пытаюсь подключиться к одной из узловых машин. Чтобы предоставить всю информацию, вот соответствующие файлы конфигурации, испорченные, чтобы все выглядело более читабельным ...

/etc/ named.conf

[root@zaza ~]# cat /etc/named.conf 
options {
          listen-on port 53 { any; };
          directory       "/var/named";
          dump-file       "/var/named/data/cache_dump.db";
          statistics-file "/var/named/data/named_stats.txt";
          memstatistics-file "/var/named/data/named_mem_stats.txt";
          allow-query     { any; }; # was localhost
          recursion yes;

          # setup DNS forwarding
          forwarders {1.2.3.4;}; # Real IP goes in here
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "cluster.local." {
    type master;
    file "cluster.local";

    # these two lines allow DNS querying
    allow-update { any; };
    notify no;
};

zone "10.in-addr.arpa." {
    type master;
    file "10";

    # these two lines allow DNS querying
    allow-update { any; };
    notify no;
};

/var/ named/cluster.local

[root@zaza ~]# cat /var/named/cluster.local 
$TTL 300
@                       IN      SOA     zaza.cluster.local. nobody.example.com. (
                                        2017030100   ; Serial
                                        600         ; Refresh
                                        1800         ; Retry
                                        604800       ; Expire
                                        300          ; TTL
                                        )

                        IN      NS      zaza.cluster.local.

zaza     IN  A     10.69.0.69



node1  IN  A     10.69.0.1;
node2  IN  A     10.69.0.2;

/ var / named / 10

[root@zaza ~]# cat /var/named/10 
$TTL 300
@                       IN      SOA     zaza.cluster.local. root.zaza.cluster.local. (
                                        2017030100   ; Serial
                                        600         ; Refresh
                                        1800         ; Retry
                                        604800       ; Expire
                                        300          ; TTL
                                        )

                        IN      NS      zaza.cluster.local.

69.0.69 IN  PTR  zaza.cluster.local.



1.0.69  IN  PTR  node1.cluster.local.
2.0.69  IN  PTR  node2.cluster.local.

Если у вас есть идеи, мы будем очень признательны!

Все дело было в Avahi и домене .local, а не в записях PTR.

Я провел еще несколько поисков, осознав, что разрешение хоста работает, но этот хост по FQDN не работает. Это в конечном итоге привело меня https://superuser.com/questions/704785/ping-cant-resolve-hostname-but-nslookup-can и отсюда я был связан с http://www.lowlevelmanager.com/2011/09/fix-linux-dns-issues-with-local.html который решил все для меня.

В конечном итоге проблема в том, что в /etc/nsswitch.conf там есть строчка:
hosts: files mdns4_minimal [NOTFOUND=return] dns
Изменив это на:
hosts: files dns
Проблема исчезла, и я больше не получал ошибку о возможных попытках взлома.

Другое решение, которое я тестировал, заключалось в простом переименовании домена, поскольку такое поведение характерно для домена .local. При переименовании cluster.local в cluster.bob сообщение об ошибке также исчезло.

Другое решение - переместить Avahi с .local на что-то вроде .alocal, чтобы многоадресный DNS не применялся к домену .local, а конфигурация nsswitch по умолчанию, казалось бы, работала. Я полагаю удаление [NOTFOUND=return] Параметр также будет работать, поскольку он остановит многоадресный DNS от завершения поиска, если хост .local не найден, однако это, вероятно, плохая идея.

В конечном итоге это был крайний случай, который возник, потому что я не полностью понимал значение домена .local, я просто рассматривал его как хорошее соглашение для внутренней сети.