Почему мое SSH-соединение медленное? Пять немедленных исправлений проблем с задержкой

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

Перед изменением настроек выполните один простой тест:

time ssh -vvv [email protected] exit

Вывод time показывает, медленное ли все соединение. Вывод -vvv показывает, где клиент тратит время. Ищите повторные попытки ключей, сообщения GSSAPI, паузы, связанные с DNS, или длинный промежуток перед началом аутентификации. Если ssh user@host exit быстрый, но интерактивный вход медленный, проблема, вероятно, в файлах запуска удаленной оболочки, а не в самом SSH.

Есть три распространенных паттерна:

Медленно до аутентификации: Обычно DNS, GSSAPI, поиск ключа хоста или медленный бэкенд аутентификации.
Медленно после аутентификации, но до приглашения: Обычно .bashrc, .profile, .zshrc, сетевые домашние каталоги или плагины оболочки.
Медленно при наборе текста или использовании полноэкранных инструментов: Обычно реальная сетевая задержка, потеря пакетов, перегруженные конечные точки, накладные расходы на сжатие или рендеринг терминала.

Исправления ниже упорядочены по частоте, с которой они решают реальные жалобы на задержку SSH.

1. Отключите обратные DNS-запросы на сервере

Обратный DNS — классическая причина медленных входов в SSH во внутренних сетях. Сервер принимает ваше TCP-соединение, затем пытается разрешить IP-адрес подключающегося клиента обратно в имя хоста. Если обратный DNS отсутствует, неправильно настроен или обрабатывается медленным резолвером, вход может задерживаться на несколько секунд.

Это настройка на стороне сервера. Добавьте или обновите эту строку в /etc/ssh/sshd_config:

UseDNS no

Затем протестируйте и перезагрузите SSH:

sudo sshd -t
sudo systemctl reload sshd

Некоторые дистрибутивы используют ssh в качестве имени службы:

sudo systemctl reload ssh

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

2. Отключите GSSAPI, если вы не используете Kerberos

GSSAPI полезен в средах, использующих Kerberos. Вне этих сред он может добавить ненужную попытку аутентификации. Симптом обычно — пауза во время установки соединения перед тем, как продолжится аутентификация по открытому ключу.

Установите это в вашем локальном ~/.ssh/config:

Host *
    GSSAPIAuthentication no

Если вы видите задержку только с одним сервером, ограничьте настройку этим хостом:

Host legacy-admin
    HostName legacy-admin.example.com
    User admin
    GSSAPIAuthentication no

Запустите ssh -vvv legacy-admin и сравните до и после. Вы должны увидеть, что клиент пропускает GSSAPI и переходит непосредственно к аутентификации по открытому ключу или паролю.

3. Перестаньте предлагать неправильные ключи

Если ваш SSH-агент содержит кучу ключей, ваш клиент может предложить несколько идентификаторов, прежде чем достигнет того, который принимает сервер. Это медленнее, чем нужно, и некоторые серверы отклоняют вход после слишком большого количества неудачных попыток.

Подробный вывод делает это очевидным:

debug1: Offering public key: /Users/me/.ssh/id_personal
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_old_vendor
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_prod

Зафиксируйте правильную идентичность:

Host prod-api
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

IdentitiesOnly yes имеет значение. Без него клиент все равно может предлагать ключи агента до или вместе с настроенным файлом.

Вы также можете проверить, что загружено в агент:

ssh-add -l

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

ssh-add -D
ssh-add ~/.ssh/id_ed25519_prod

4. Используйте сжатие только там, где это помогает

Сжатие — это не универсальный переключатель скорости. Оно может помочь, когда канал ограничен по пропускной способности, а данные сжимаемы, например, длинные текстовые логи через медленный VPN. Оно может навредить в быстрых сетях, потому что обе стороны тратят процессорное время на сжатие и распаковку данных, которые в противном случае быстро прошли бы по проводам.

Используйте его узконаправленно:

Host distant-bastion
    HostName bastion.example.net
    User ops
    Compression yes

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

Если набор текста медленный, сжатие редко является первым исправлением. Проверьте сетевой путь:

ping server.example.com
mtr server.example.com

Если вы видите высокую задержку или потерю пакетов, конфигурация SSH может сделать не так много. Переместитесь через более близкий бастион, исправьте путь VPN или используйте регион, более близкий к оператору.

5. Повторно используйте соединения с помощью мультиплексирования

Если первое SSH-соединение занимает пару секунд, но каждая новая вкладка терминала повторяет эту стоимость, мультиплексирование соединений — чистое исправление. SSH держит одно управляющее соединение открытым и повторно использует его для последующих сессий к тому же пользователю, хосту и порту.

Добавьте это в ~/.ssh/config:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

Создайте каталог сокетов:

mkdir -p ~/.ssh/controlmasters
chmod 700 ~/.ssh/controlmasters

Первое соединение все равно платит обычную стоимость рукопожатия и аутентификации. Следующее должно быть почти мгновенным.

Если мультиплексированное соединение застревает после изменения сети, закройте мастер-сокет:

ssh -O exit [email protected]

Или удалите соответствующий сокет из ~/.ssh/controlmasters.

Проверьте запуск оболочки, прежде чем винить SSH

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

Сравните это:

time ssh [email protected] true
time ssh [email protected] 'bash --noprofile --norc -i -c exit'

Затем проверьте .bashrc, .bash_profile, .profile, .zshrc и все, что они подключают. Распространенные замедления включают темы приглашения, которые выполняют команды Git в больших каталогах, завершения kubectl или облачного CLI, которые запрашивают удаленный API, инициализацию менеджера пакетов, заблокированные NFS-домашние каталоги и скрипты, вызывающие внутренние службы во время входа.

Самое быстрое исправление SSH — то, которое соответствует паузе, которую вы действительно видите. Используйте -vvv, меняйте по одной вещи за раз и тестируйте из второго терминала, оставляя текущую сессию открытой.