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

Вход по SSH из VPN очень медленный

У меня есть сервер, на котором работает OpenSSH. Когда я вхожу в локальную сеть (есть несколько сетевых интерфейсов, и это верно для всех), вход в систему происходит относительно быстро - обычно за пару секунд.

У меня также есть мостовой VPN, работающий в локальной сети, в которой находится сервер, с использованием OpenVPN, и когда я пытаюсь получить доступ к серверу через VPN, при входе в систему возникает задержка в 40 секунд - число 40 секунд довольно точное и всегда такая же задержка.

Просматривая журналы отладки sshd, я вижу, что нормальный процесс входа в систему имеет следующие строки:

Oct 18 10:05:07 server sshd[7745]: debug1: KEX done
Oct 18 10:05:07 server sshd[7745]: debug1: userauth-request for user root service ssh-connection method none
Oct 18 10:05:07 server sshd[7745]: debug1: attempt 0 failures 0
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: initializing for "root"
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: setting PAM_RHOST to "192.168.xx.xx"
Oct 18 10:05:07 server sshd[7744]: debug1: PAM: setting PAM_TTY to "ssh"
Oct 18 10:05:10 server sshd[7745]: debug1: userauth-request for user root service ssh-connection method publickey
Oct 18 10:05:10 server sshd[7745]: debug1: attempt 1 failures 1
Oct 18 10:05:10 server sshd[7744]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Oct 18 10:05:10 server sshd[7744]: debug1: trying public key file /root/.ssh/authorized_keys
Oct 18 10:05:10 server sshd[7744]: debug1: matching key found: file /root/.ssh/authorized_keys, line 13

Когда происходит соединение через VPN, я получаю похожие строки, похожие на это (обратите внимание на временные метки):

Oct 18 10:01:14 server sshd[31438]: debug1: KEX done
Oct 18 10:01:14 server sshd[31438]: debug1: userauth-request for user root service ssh-connection method none
Oct 18 10:01:14 server sshd[31438]: debug1: attempt 0 failures 0
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: initializing for "root"
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: setting PAM_RHOST to "192.168.xx.xx"
Oct 18 10:01:14 server sshd[31437]: debug1: PAM: setting PAM_TTY to "ssh"
Oct 18 10:01:54 server sshd[31438]: debug1: userauth-request for user root service ssh-connection method publickey
Oct 18 10:01:54 server sshd[31438]: debug1: attempt 1 failures 1
Oct 18 10:01:54 server sshd[31438]: debug1: test whether pkalg/pkblob are acceptable             
Oct 18 10:01:54 server sshd[31437]: debug1: temporarily_use_uid: 0/0 (e=0/0)
Oct 18 10:01:54 server sshd[31437]: debug1: trying public key file /root/.ssh/authorized_keys
Oct 18 10:01:54 server sshd[31437]: debug1: matching key found: file /root/.ssh/authorized_keys, line 13

Как вы можете видеть, во втором журнале есть 40-секундный промежуток посередине - это происходит каждый раз, когда я пытаюсь войти через VPN на любой сервер в локальной сети, но никогда не из локальной сети или общедоступной сети, и я ' m, используя тот же ключ SSH.

Серверы - CentOS 5 и 6, клиент - OpenSSH в Fedora, Ubuntu и Putty в MS-Windows.

Любые подсказки будут оценены.

Я наконец нашел проблему - это GSSAPIAuthentication.

Я установил

GSSAPIAuthentication no

в /etc/ssh/sshd_config и теперь все работает нормально. Я не уверен что GSSAPIAuthentication делает (что-то связанное с Kerberos), но поскольку я не использую это, мне все равно, и, очевидно, когда он включен, OpenSSH пытается выполнить аутентификацию GSS и отключается через 40 секунд - или что-то в этом роде.

Вероятно, он пытается выполнить обратный поиск в DNS на вашем IP-адресе, но в конечном итоге приводит к ошибке.

Убедитесь, что обратный DNS для IP-адреса, назначенного вам VPN, работает - он не обязательно должен давать ответ, но вы хотите убедиться, что он может по крайней мере быстро дать ответ «не найден». чем тайм-аут.

Я согласен с TomH, в первую очередь следует искать обратный поиск. Вы можете быстро отключить обратный поиск:

nano /etc/ssh/sshd_config

Перед UseDNS может стоять #, в таком случае удалите # и установите для него значение:

UseDNS No

Сохраните файл конфигурации и перезапустите службу ssh.