Вопросы Теги

занимает слишком много времени соединяться с ssh сервером

Я думаю, что Вы не понимаете, как работают Живые CD. Когда Вы загружаетесь, CD смонтирован только для чтения. Затем существует squashfs, смонтированный объединением на главном, смонтированном чтении-записи. Это означает, что весь CD, на самом деле, не становится загруженным в RAM. Поэтому исполняемые файлы не находятся автоматически в RAM, и все еще необходимо загрузить их.

3
13.04.2017, 15:36
2 ответа

Думаю, проблема в таймаутах DNS-запросов. Попробуйте ... отключить опцию UseDNS на сервере, к которому вы подключаетесь.

enter image description here

Журнал сервера практически подтвердил это (так хорошо сделано для отправки :).

Глядя на [1188662]man sshd_config[1188663]:

UseDNS Определяет, должен ли sshd(8) искать имя удаленного хоста и проверить, что разрешенное имя хоста для карт удаленных IP-адресов обратно на тот же самый IP-адрес. По умолчанию - "да".

Обратите внимание, что это [1188666] практически бессмысленно [1188667]. Проверка не [1188668], а [1188669] прерывает соединение. Если она не проходит, она просто регистрирует виляющее сообщение:

Июль 9 05:43:00 brick sshd[18971]: Адрес 200.41.233.234 maps to host234.advance.com.ar, но это не map back to the address - POSSIBLE BREAK-IN ATTEMPT!

find . -name "*.exe" -exec rm -f '{}' +

который служит только для генерации страшных ложных срабатываний для пользователей с некомпетентными провайдерами.OK, так как это может вызвать задержку? Если DNS-сервер не ответит немедленно, клиент будет склонен ждать и повторять попытку. (В случае, если DNS-пакет был задержан или потерян из-за перегрузки сети). Если DNS-сервер вообще не отвечает, клиент в конце концов сдастся. Например, [1188672]dig[1188673] на моей системе повторяет попытку в течение 15 секунд. (Он использует более конкретный код библиотеки dns, но принцип тот же)

find -name '*.exe' | xargs -d \\n rm

Таким образом, проблема в том, что обратный поиск не получает ответа. Тот же самый поиск на сервере можно запустить и вручную, и вы должны увидеть ту же задержку, что и ssh. [1188674]получить хосты 10.0.2.2[1188675].[1188208].

2
27.01.2020, 21:19
[1183540] На данном этапе существует множество возможностей, которые могут привести к медленному соединению. Из [1183838] этой [1183839] связи, одна проблема, которую я вижу, связана с шифрованием.
  • Наконец, я знаю, в чем проблема.
  • мой /дома/пользователь зашифрован, и поэтому ssh не смог получить доступ Также еще одна возможность из [1183844] здесь [1183845] связана со службой [1183846] SELinux [1183847].
  • Да, [1183940]SELinux[1183941], вероятно, является причиной. Вероятно, [1183942].ssh[1183943] гирька с неправильной маркировкой. Посмотрите на [1183944]/var/log/audit/audit.журнал[1183945]. Он должен быть обозначен [1183946]ssh_home_t[1183947]. Проверьте с помощью [1183948]ls -laZ[1183949]. Запустите [1183950]restorecon -r -vv /root/.ssh[1183951]. При необходимости
  • Также из [1183850]этого[1183851] соединения я вижу, что аутентификация PAM может быть причиной медленного SSH.
  • Отредактируйте свой "[1183952]/etc/ssh/ssh_config[1183953]" и прокомментируйте эти строки:
  • GSSAPIAuthentication yes. GSSAPIDelegateУчетные данные нет
    • 2
    27.01.2020, 21:19

    Теги

    Похожие вопросы