SSH для моего сервера AWS просто сломался как для Putty, так и для Filezilla. Я прикладываю некоторые усилия для того, чтобы этот пост был исчерпывающим списком устранения неполадок, поэтому, если вы обмениваетесь ссылками на другие страницы, я отредактирую их в вопросе.
Disconnected : No supported authentication methods available (server sent :publickey)
Ошибка знакома, когда я установил соединение почти год назад. Если вы впервые устанавливаете AWS SSH, это касается наиболее распространенных проблем:
Однако единственное, что я мог подумать, что повлияло бы на ранее работающую систему:
Какие еще существуют возможности?
Решение этой задачи (согласно принятому положению ниже) заключается в том, что для AWS EC2 все 3 из них должны иметь правильные разрешения (777 не ok для любого из них). Вот один пример, который работает:
/home/ec2-user/ - 700
/home/ec2-user/.ssh/ - 600
/home/ec2-user/.ssh/authorized_keys - 600
/var/log/secure сообщит вам, какая из них выдает ошибку, обратитесь к этому видеоуроку, чтобы получить доступ, если вы полностью заблокированы: http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4
Для меня эта ошибка появилась сразу после того, как я изменил домашний каталог пользователя на
sudo usermod -d var/www/html username
Это также может случиться из-за отсутствия надлежащего разрешения на файл authorized_key в ~/.ssh. Убедитесь, что разрешение этого файла - 0600, а разрешение ~/.ssh - 700.
Вы также получите "Отключено: нет доступных методов проверки подлинности (сервер отправлен: публикация)", когда у вас есть правильный пользователь Linux, но вы не создали файл .ssh/authorized_keys и сохранили открытый ключ, как указано в Управление учетными записями пользователей на вашем Linux-экземпляре
Есть еще одна причина, которая повлияла бы на ранее работающую систему. Я повторно создал свои экземпляры (используя AWS OpsWorks) для использования Amazon Linux вместо Ubuntu и после этого получил эту ошибку. Переключение на использование "ec2-user" в качестве имени пользователя вместо "ubuntu" разрешило проблему для меня.
PuTTY не поддерживает формат закрытого ключа (.pem), созданный Amazon EC2. PuTTY имеет инструмент под названием PuTTYgen, который может преобразовывать ключи в требуемый формат PuTTY (.ppk). Вы должны преобразовать свой закрытый ключ в этот формат (.ppk), прежде чем пытаться подключиться к вашему экземпляру с помощью PuTTY.
Ниже описаны действия, описанные здесь: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html
Это решило проблему.
в большинстве случаев не получил ошибку метода проверки подлинности при использовании неправильного имени пользователя для входа в систему. Но я действительно нахожу что-то еще, если вы все еще боретесь с проблемой подключения, и вы пробовали все вышеперечисленные варианты.
Я создал пару Linux VM и попытался воспроизвести такую проблему подключения, одна вещь, которую я нашел, когда AWS попросил вас назвать вашу пару ключей, НЕ пустое место пользователя ( ") и точка (".") в паре ключей имя, даже AWS на самом деле позволяют это сделать.
ех. когда я назвал пару ключей как "AWS.FREE.LINUX", соединение всегда будет отклонено. Когда меня называют "AWS_FREE_LINUX", все работает нормально.
Надеюсь, это поможет немного.
У меня была такая же проблема, случайно ошибка. Я расскажу об этом здесь, если кто-то, возможно, совершил ту же ошибку. Основные этапы, как описано выше. 1, загрузите putty и puttygen или пакет шпатлевки и установите его. 2, получите файл .pem из вашего экземпляра AWS EC2. 3, используйте puttygen для преобразования файла .pem, чтобы у вас был закрытый ключ. Ошибка здесь. Я выбрал вкладку "Конверсии" из PuttyGen и загрузил мой файл .pem. После загрузки файла pem здесь НЕ НАЙТИ "Сгенерировать", вместо этого непосредственно "Сохранить закрытый ключ". Это ключ, который вам нужен. Если вы нажмете "Создать", у вас будет совершенно другая пара ключей. 4, в шпаклере, используйте [email protected] и загрузите закрытый ключ в SSH/Auth Удачи!
На основе нескольких экземпляров, если ключевой файл и имя пользователя верны, это происходит при изменении определенных разрешений на каталоги, связанных с пользователем root.
Аналогичная проблема произошла со мной сегодня. Я также много искал об этом. Нет одной помощи. Я только что сделал два изменения, и он тоже работает нормально.
Надеюсь, это поможет вам.
У меня была та же проблема, я использовал Public DNS вместо Public IP. Теперь это разрешилось.
При попытке подключиться к серверу SiteGround через Putty у меня была та же проблема. Их инструкции довольно тщательны и должны работать для некоторых людей, но не работали для меня.
Они рекомендуют запустить pageant.exe, который работает в фоновом режиме. Вы регистрируете свой ключ с помощью Pageant, и он должен позволить Putty знать о ключах, когда он пытается подключиться.
В пара места Я нашел предложения, чтобы указать ключ напрямую в определении сеанса Putty: Конфигурация Putty > Соединение > SSH > Auth > "Файл секретного ключа для аутентификации", затем перейдите к вашему ключевому файлу в формате .ppk.
Выполнение этого без запуска Pageant разрешило проблему для меня.
Во время сеанса ssh мое соединение сломалось, так как тогда я не могу ssh мой SRV, я начал новый экземпляр, и я могу ssh новый экземпляр (с тем же ключом).
Я установил старый том на новый компьютер и проверил .ssh/authorized_key и не смог найти никаких проблем с разрешением или контентом.