Рейтинг:1

Соединение через туннель SSH изначально медленное

флаг mx

Я создал службу туннелирования SSH, работающую в контейнере на основе Alpine, на основе описанного здесь подхода: https://github.com/cagataygurturk/докер-ssh-туннель

Служба подключается через IdentityFiles и устанавливает несколько ControlSockets и туннелей.

Я тестирую это на бастионе Amazon Linux, туннелируя в базу данных PostgreSQL.

Вход в SSH и создание туннеля выполнены правильно, и туннели можно использовать, но, похоже, где-то есть тайм-аут.

  • Если туннель - может подключение к целевому SSH серверу в целом? - был оставлен бездействующим в течение 5 минут, а затем подключен, процесс подключения зависает на 30 секунд, прежде чем успешно продолжиться.
  • Туннельные соединения сразу после первого соединения выполняются быстро - доли секунды.
  • Пусть туннель/сервер бездействует в течение 5 минут, и 30-секундная задержка возвращается.

Вот доказательства:

клиент ssh-config

Хозяин моего бастиона
    Имя хоста 99.99.99.99
    Пользователь ec2-пользователь
    Файл идентификации ~/.ssh/key.pem

Хозяин *
    Авто ControlMaster
    Путь управления ~/.ssh/controlmasters/cp_%r_%h
    ControlPersist да
    StrictHostKeyChecking нет
    ServerAliveCountMax 60
    Серверживеинтервал 30
    TCPKeepAlive нет
    ForkAfterAuthentication да
    StdinNull да
    ExitOnForwardFailure да
    IPQOS 0x00

Тестовый рабочий процесс

Туннель, установленный ранее с использованием ControlSocket.

Тестирование с помощью запроса psql, который не проходит аутентификацию, но проверяет туннель.

psql делает 2 подключения через туннель во время теста.

Первый доступ после не менее 5 минут простоя.

# дата и время psql "host=localhost port=5430 dbname=xxx user=UUU password=X"
Вт 8 марта 12:10:57 PST 2022
psql: ошибка: FATAL: ошибка аутентификации пароля для пользователя "UUU"
FATAL: аутентификация пароля не удалась для пользователя "UUU"

реальные 0m32.497s - медленно!

Журнал клиента SSH -vv

1-й запрос psql

[2022-03-08 20:10:57] debug1: запрошено подключение к порту 5430, перенаправление на порт 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:10:57] debug1: канал 3: новый [direct-tcpip]

30 секунд Задержка здесь
[2022-03-08 20:10:57] debug2: канал 3: открыть подтвердить rwindow 2097152 rmax 32768

[2022-03-08 20:11:29] debug2: канал 3: чтение<=0 rfd 7 len 0


2-й запрос psql

[2022-03-08 20:11:29] debug1: запрошено подключение к порту 5430, перенаправление на порт 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:11:29] debug1: канал 4: новый [direct-tcpip]

ответ доли секунды на канале 4

[2022-03-08 20:11:29] debug2: канал 4: открыть подтвердить rwindow 2097152 rmax 32768

[2022-03-08 20:11:29] debug2: канал 4: чтение<=0 rfd 8 len 0

Доступ сразу после 1-го.


# дата и время psql "host=localhost port=5430 dbname=xxx user=UUU password=X"
Вт 8 марта 12:11:41 PST 2022
psql: ошибка: FATAL: ошибка аутентификации пароля для пользователя "UUU"
FATAL: аутентификация пароля не удалась для пользователя "UUU"

реальные 0m0.874s - быстро!
пользователь 0м0.021с
система 0m0.016s

1-й запрос psql

[2022-03-08 20:11:41] debug1: запрошено подключение к порту 5430, перенаправление на порт 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:11:41] debug2: настройка fd 7 TCP_NODELAY
[2022-03-08 20:11:41] debug2: настройка fd 7 O_NONBLOCK
[2022-03-08 20:11:41] debug1: канал 3: новый [direct-tcpip]

Ответ доли секунды на запрос

[2022-03-08 20:11:41] debug2: канал 3: открыть подтвердить rwindow 2097152 rmax 32768

[2022-03-08 20:11:42] debug2: канал 3: чтение<=0 rfd 7 len 0

...

2-й запрос psql

[2022-03-08 20:11:42] debug1: запрошено подключение к порту 5430, перенаправление на порт 5432 xxx.us-east-1.rds.amazonaws.com.
[2022-03-08 20:11:42] debug1: канал 4: новый [direct-tcpip]

[2022-03-08 20:11:42] debug2: канал 4: открыть подтвердить rwindow 2097152 rmax 32768

Я искал других с этой проблемой, но не нашел, что эта проблема обсуждалась. Я попробовал совет от https://jrs-s.net/2017/07/01/slow-ssh-логины/ и установите IpQos=0x00, чтобы обойти любые возможные проблемы с маршрутизатором.

Рейтинг:0
флаг mx

Проблема была со службой Aurora PostgreSQL Serverless, к которой я туннелировал. Настройка по умолчанию для Serverless — приостанавливать работу кластера при бездействии в течение 5 минут. Когда приходит новое соединение, перезапуск службы занимает около 30 секунд.

Таким образом, медленное соединение через 5 минут было перезапуском бессерверной службы, а не проблемой SSH :-/

Ответить или комментировать

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