Borré los archivos de registro, desinstalé y reinstalé PuTTY y verifiqué mi IP con una base de datos de spambot. No sé qué sucede detrás de escena, pero en mi solución de problemas leí que agregar la -vetiqueta proporciona más información de depuración, así que lo hice y pegué el resultado aquí.
Cabe señalar que no tengo acceso al servidor Linux físico que aloja el repositorio Git, es decir, el cPanel modificado de GoDaddy (que por alguna razón, cuando un miembro del equipo ingresa mediante ssh al servidor no permite el apagado o sudo , que según mi investigación son los dos comandos que serían más útiles)
C:\Users\Fish's Ocean>ssh -v [email protected]
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\Fish's Ocean/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.6
ssh_exchange_identification: read: Connection reset
Respuesta1
1. Credenciales
Tenga en cuenta que las debug1: key_load_publiclíneas son incidentales: no son errores, sino simplemente advertencias que no deberían afectar la conexión en sí.
Según mi experiencia, la razón más común de problemas de SSH para los servidores web es que uno no ha configurado una identidad SSH/FTP. El nombre de usuario y la contraseña que utilice para conectarse serán diferentes de cualquier otra credencial de cuenta de Godaddy y, a menudo, deberán configurarse explícitamente, un proceso que se analiza en esteguía de Godaddy. Asegúrese de conocer sus credenciales FTP. Como dice la guía:
Encuentre su nombre de usuario y contraseña de FTP
Inicie sesión en su cuenta GoDaddy y abra su producto.
En la barra de menú superior, haga clic en Archivos y FTP, luego seleccione Usuarios de FTP.
Para cambiar su nombre de usuario o contraseña de FTP, haga clic en el menú desplegable Acciones y seleccione Cambiar contraseña o Cambiar nombre de usuario.
Complete los campos necesarios en la nueva ventana y haga clic en Aceptar para confirmar los cambios.
- Utilice su nombre de usuario y contraseña de FTP para establecer la conexión SSH...
También tenga en cuenta que los comandos como sudoo shutdownsolo estarán disponibles si está utilizando un VPS o alojamiento dedicado de Godaddy. Si tiene algún tipo de alojamiento compartido, estos no estarán disponibles para usted.
2. Lista negra
Tampoco es raro que servidores web como GodaddyIP de lista negraque han fallado múltiples intentos de conexión. Independientemente de su problema inicial, este puede ser el motivo por el que se restablece la conexión. Podrías volver a chatear con el soporte y ver si es posible que eliminen dicha lista negra. También puede intentar conectar su máquina a la conexión a Internet de su dispositivo móvil (si es posible) y tener otra oportunidad con Putty.