Tengo dificultades para conectarme mediante SFTP a mi cuenta de prueba de AWS desde mi servidor local.
Cuando ingreso al directorio donde está mi clave ssh privada y ejecuto sftp -v -i <private_key_file> <client>@<hostname>esto es lo que obtengo:
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
y después de mucho tiempo consigoCouldn't read packet: Connection reset by peer.
Lo extraño es que cuando hago la misma conexión desde el mismo servidor local a mi cuenta de desarrollo de AWS, funciona bien. El entorno de prueba de AWS es donde esto no funciona. Obviamente, asigné otra clave pública al cliente que se encuentra en mi entorno de prueba de AWS y hago referencia a la nueva clave privada en el comando anterior.
Cualquier ayuda sería realmente apreciada.
Respuesta1
La congelación de SSH después SSH2_MSG_KEXINIT sentes una señal segura de que hay un problema con la MTU.
Se supone que Path MTU Discovery determina la MTU automáticamente. Sin embargo, dependiendo de las reglas del firewall intermedias y de los sistemas operativos en ambos extremos, es posible que eso no funcione.
Si Path MTU Discovery no funciona, debe configurar la MTU manualmente.
Sugiero comenzar con 1400 y subir hasta el valor más alto que aún funcione.
La forma de configurar la MTU y hacer que el cambio sea persistente depende del sistema operativo.