У меня возникли проблемы с подключением по SFTP к моему тестовому аккаунту AWS с моего локального сервера.
Когда я перехожу в каталог, где находится мой закрытый ssh-ключ, и запускаю, sftp -v -i <private_key_file> <client>@<hostname>вот что я получаю:
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to <hostname> [<IP Adress>] port 22.
debug1: Connection established.
debug1: identity file <private_key_file> type 1
debug1: key_load_public: No such file or directory
debug1: identity file <private_key_file>-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1
debug1: no match: AWS_SFTP_1.1
debug1: Authenticating to <hostname>:22 as 'client'
debug1: SSH2_MSG_KEXINIT sent
и после гораздо большего времени я получаюCouldn't read packet: Connection reset by peer.
Странно то, что когда я делаю то же самое подключение с того же локального сервера к моей учетной записи AWS dev, все работает нормально. В тестовой среде AWS это не работает. Очевидно, я назначил другой открытый ключ клиенту, который находится в моей тестовой среде AWS, и ссылаюсь на новый закрытый ключ в команде выше.
Любая помощь будет по-настоящему оценена.
решение1
Зависание SSH после этого SSH2_MSG_KEXINIT sent— верный признак того, что возникла проблема с MTU.
Path MTU Discovery должен автоматически определять MTU для вас. В зависимости от правил брандмауэра между ними и операционных систем на обоих концах, это может не сработать.
Если обнаружение MTU-пути не работает, вам придется установить MTU вручную.
Я предлагаю начать с 1400 и постепенно увеличивать до максимального значения, которое все еще работает.
Способ установки MTU и сохранения изменений зависит от операционной системы.