Я очистил файлы реестра, удалил и переустановил PuTTY и проверил свой IP по базе данных спам-ботов. Я не знаю, что происходит за кулисами, но в своем устранении неполадок я прочитал, что добавление тега -v
дает больше отладочной информации, поэтому я это сделал и вставил вывод сюда.
Следует отметить, что у меня нет доступа к физическому серверу Linux, на котором размещен репозиторий Git, то есть к модифицированной панели cPanel от GoDaddy (которая по какой-то причине, когда член команды подключается к серверу по ssh, не позволяет выполнить команду shutdown или sudo, которые, согласно моим исследованиям, являются двумя наиболее полезными командами).
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
решение1
1. Учетные данные
Обратите внимание, что эти debug1: key_load_public
строки случайны — это не ошибки, а просто предупреждения, которые не должны влиять на само соединение.
Наиболее распространенной причиной проблем с SSH на веб-хостингах по моему опыту является то, что кто-то не настроил идентификатор SSH/FTP. Имя пользователя и пароль, которые вы используете для подключения, будут отличаться от любых других учетных данных Godaddy и часто должны быть настроены явно — процесс, который обсуждается в этомруководство от Godaddy. Убедитесь, что вы знаете свои учетные данные FTP. Как гласит руководство:
Найдите свое имя пользователя и пароль FTP
Войдите в свою учетную запись GoDaddy и откройте свой продукт.
В верхней строке меню нажмите «Файлы и FTP», затем выберите «Пользователи FTP».
Чтобы изменить имя пользователя или пароль FTP, щелкните раскрывающийся список «Действия» и выберите «Изменить пароль» или «Изменить имя пользователя».
Заполните необходимые поля в новом окне и нажмите «ОК» для подтверждения изменений.
- Используйте свое имя пользователя и пароль FTP для установки SSH-соединения...
Также обратите внимание, что команды типа sudo
или shutdown
будут доступны только если вы используете VPS или выделенный хостинг от Godaddy. Если вы используете какой-либо общий хостинг, они вам не будут доступны.
2. Внесение в черный список
Также не редкость для таких веб-хостингов, как Godaddy,черный список IP-адресовкоторые не смогли подключиться несколько раз. Независимо от вашей первоначальной проблемы, это может быть причиной сброса подключения. Вы можете снова пообщаться со службой поддержки и узнать, возможно ли удалить такой черный список. Вы также можете попробовать привязать свой компьютер к интернет-соединению вашего мобильного устройства (если это возможно) и сделать еще одну попытку с помощью Putty.