Вы можете Wireshark подключить SSH и увидеть связь на уровне TCP. Клиент SSH сначала отправит свою версию протокола перед сервером.
Я не думаю, что у вас есть возможность изменить порядок общения. С моим SSH-клиентом (OpenSSH_8.1p1, LibreSSL 2.7.3) я мог видеть, что после выполнения SYN-ACK сервер ожидает, пока SSH-клиент отправит поддерживаемую версию протокола.
Вы не можете изменить порядок протокола в этом случае; это зафиксировано в RFC, и порядок действительно имеет значение. Сервер отправляет свою версию как часть запроса на открытие, а затем клиент отправляет свою версию. После этого обе стороны обмениваются списком алгоритмов, поддерживаемых обеими сторонами, и выбранный алгоритм, как правило, является первым, поддерживаемым клиентом, который также поддерживается сервером.
Хотя вы не можете изменить объявление номера версии протокола, вы можете, в зависимости от версии, отправленной клиентом, предлагать различные алгоритмы. Например, некоторые версии OpenSSH неправильно реализованы [email protected]
, поэтому сервер, который знает об этом, может решить не предлагать этот алгоритм сломанной версии OpenSSH. Точно так же клиент может объявить серверу различные алгоритмы на основе объявления версии сервера.
Протокол имеет значение, если какая-либо из сторон использует взлом SSH-1.99
, как указано в §5.1, потому что клиент должен объявить правильный протокол и/или не отправлять дополнительные данные. Я согласен, что это не требуется, если вы не используете этот формат и используете только SSH 2.0.
Это хороший и важный момент, @bk2204.
Порядок обмена версиями протокола SSH не указан; он говорит:
Когда соединение установлено, обе стороны ДОЛЖНЫ отправить идентификационная строка. Эта идентификационная строка ДОЛЖНА быть
SSH-protoversion-softwareversion SP комментарии CR LF
RFC, вероятно, ничего не говорит о порядке обмена версиями протокола, потому что, фактически, это гонка, и порядок не должен иметь значения. Когда TCP-соединение клиента принимается сервером, клиент и сервер отправляют информацию о своей версии... кто первым доберется до другого, зависит только от скорости, трафика и т. д.
Как клиент, вы не можете (или не должны иметь возможности...) "заставить" сервер ждать; вполне возможно, что конкретная реализация сервера ожидает клиента перед отправкой собственной информации, но это деталь реализации сервера.
Для тех, кто проголосовал за закрытие: задавать протокольные вопросы, кажется, вполне в рамках SO. Но, независимо от целесообразности, голосование за закрытие без объяснения причин затрудняет оценку вашего суждения. И делать это новому участнику не очень приветливо. Пожалуйста, будьте более прозрачными.