27 мая, 2017 12:10 пп
36 066 views
| Комментариев нет
Linux, SSH, VPS
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:
- Проблемы с подключением к серверу: здесь вы узнаете, как исправить ошибки подключения к серверу.
- Ошибки протокола: в этой статье вы узнаете, что делать, если сбрасываются клиентские соединения, клиент жалуется на шифрование или возникают проблемы с неизвестным или измененным удаленным хостом.
- Ошибки оболочки: это руководство поможет исправить ошибки ветвления процессов, валидации оболочки и доступа к домашнему каталогу.
После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.
Требования
- Убедитесь, что можете подключиться к виртуальному серверу через консоль.
- Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.
Основные ошибки
Отказ в доступе (парольная аутентификация)
Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.
Клиенты PuTTY и OpenSSH выдают такое сообщение:
root@111.111.111.111's password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111's password:
Access denied
Server sent disconnect message
type 2 (protocol error):
"Too many authentication failures for root"
Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:
- Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
- Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
- Убедитесь, что сервер поддерживает парольную аутентификацию.
Отказ в доступе (аутентификация на основе SSH-ключей)
Этот метод использует криптографические ключи для аутентификации пользователя.
Читайте также:
- Как настроить SSH-ключи
- Создание SSH-ключей для PuTTY
Вы можете получить такую ошибку:
Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)
Многие наиболее распространенные проблемы, связанные с аутентификацией на основе ключей, вызваны неправильными правами доступа к файлам или правами собственности. Чтобы устранить проблему, попробуйте сделать следующее:
- Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
- Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
- Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
- Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
- Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.
Консоль не поддерживает пароли
Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме PAM, которые влияют на механизм аутентификации. Эта ошибка также повлияет на попытки сбросить пароль root и войти в систему через консоль.
В консоли появляется форма аутентификации:
Ubuntu 14.04.4 LTS server tty1
server Login:
Password:
Но после ввода пароля появляется ошибка:
Login incorrect
После сброса пароля вы получите:
You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:
Повторно введите текущий пароль. Если соединение закроется, возможно, вы допустили ошибку, повторно вводя пароль. Повторите попытку.
При успешном завершении вам будет предложено дважды ввести новый пароль:
Enter new UNIX password:
Retype new UNIX password:
Однако если после повторного ввода правильного нового пароля сессия перезапустится (т.е. снова вернется форма для входа в систему) или появится сообщение об ошибке, это означает, что проблема в одном из файлов, в котором хранятся данные аутентификации.
В таком случае рекомендуется обратиться за помощью в службу поддержки хостинг-провайдера, подготовить сервер к повторному развёртыванию или исправить ошибки в настройках PAM.
Устранение неполадок
Проверка доступных методов аутентификации
Если вы используете подробный вывод или следите за логами SSH-клиента, убедитесь, что в сообщении, описывающем методы аутентификации, указаны password и/или publickey.
debug1: Authentications that can continue: publickey,password
Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.
Исправьте эту ошибку, перезапустите сервис.
Настройка прав доступа и собственности
Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.
Сервер и клиент OpenSSH должны иметь следующие права:
- ~./ssh – 700.
- ~./ssh должен принадлежать текущему аккаунту.
- ~/.ssh/authorized_keys – 600.
- ~/.ssh/authorized_keys должен принадлежать текущему аккаунту.
Кроме того, клиент должен также иметь такие права:
- ~ / .ssh / config – 600.
- ~ / .ssh / id_ * – 600.
Эти изменения можно внести с помощью консоли.
Проверка открытого и закрытого ключа
Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом ~/.ssh/authorized_keys.
Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.
ssh-keygen -y -f ~/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f
В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).
Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key
Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).
В любом случае этот открытый ключ нужно добавить в файл ~/.ssh/authorized_keys.
OpenSSH 7 и устаревшие ключевые алгоритмы
В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.
Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.
Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.
Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.
Заключение
Если у вас не получается самостоятельно настроить аутентификацию SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Читайте также: Как настроить SSH-ключи
Tags: OpenSSH, PuTTY, SSH
I don’t know what is happening.
I have been able to connect to the server for a couple of days without problems and suddendly I got a frozen window using putty. After that, each time I try to connect, I receive this message:
disconnected: no supported authentication methods available (server sent: publickey, gssapi-with-mic)
I am using putty and puttyagent for private key. I already have uploaded the public key to the server and I was able to connect half an hour ago.
How can I check why it is failing? I haven’t change the user or password or anything.
asked Mar 4, 2014 at 9:36
1
I had the same issue after creating a Centos 7 vm using Vagrant. In the sshd_config file it said “PasswordAuthentication no”. Changing that to “PasswordAuthentication yes” and a restart of sshd solved it for me.
answered Jul 29, 2017 at 6:27
I had a similar issue:
- in putty console, I got the message saying “Server refused our key”
- windows error message was: “PuTTY Fatal Error” – “No supported authentication methods
available (server sent: public key,gssapi-keyex,gssapi-with-mic)”
I was able to connect to EC2 via PowerShell successfully (with .pem file) so I realized that .ppk file was wrong.
Googled for about an hour and find that when you generate the .ppk with PuTTYgen for the first time you’ll see the key comment filed something like “rsa-key-20191006” and what should be there is “imported-openssh-key”.
After I loaded the same .pem file, as for the first time (but DID NOT CLICK on Generate) and clicked Save Private Key and used this private key for Auth, everything worked as expected.
answered Oct 6, 2019 at 15:45
1
I got the same error
disconnected: no supported authentication methods available (server sent: publickey, gssapi-with-mic) while trying to connect to an AWS EC2 instance with ssh using a PPK. The issue I had and fixed was that when I used PuTTYKeyGenerator to convert from PEM to PPK, by default it uses PPK file version 3 which is not supported by AWS EC2 and when I tried to connect with mRemoteNG I got the error, then I tried directly with PuTTYNG I got PuTTY key format too new:
To make it work, change in PuTTYKeyGenerator >> Key >> Parameters for saving key files >> PPK file version: 2 and then reconvert the PPK and should work.
answered Sep 15, 2021 at 14:26
m4rcccm4rccc
1011 silver badge2 bronze badges
2
In my case updating both putty and puttygen to the latest version (0.76) solved this issue.
- Download latest putty and latest puttygen from https://www.puttygen.com/#Download_PuTTYgen_on_Windows
- In puttygen click Load, chose All Files and select your PEM file for your EC2 instance.
- Choose SSH-1 (RSA) as a type of key to generate.
- Click on Save private key.
- In putty in the Auth section click on browse and select your generated private key.
answered Feb 11, 2022 at 9:52
Michał StochmalMichał Stochmal
5,7054 gold badges34 silver badges43 bronze badges
0
Well…
In the end, I had to delete all my keys, upload them again and wait a half an hour more or less. I don’t know what happened but now it works again.
answered Jun 2, 2014 at 10:47
BiribuBiribu
3,51512 gold badges42 silver badges79 bronze badges
I was getting this error because of wrong userid. As soon as I used ec2-user it worked.
I was under the impression that my AWS account id is my userid. It seems ec2-user is by default the user, you should login with.
answered Feb 26, 2020 at 17:52
0
Copy the content in your pem file and create another pem file and paste the content.
Sounds lame… but it works !!
answered May 8, 2019 at 13:52
Just go to Putty keygen and load an existing private key from your local path where vagrant box for centos is installed (example :- …vagrantmachinesdefaultvirtualboxprivate_key) and then choose SSH-1 (RSA) option from below and lastly click on “Save Private Key” button and save that file in your desktop or any where. Then open putty fill the ip address of machine -> go to SSH –> Auth –>Browse and provide the same key you have saved in your desktop or anywhere and then click on open.
answered May 27, 2021 at 12:16
I have the same issue and this is only because of Windows Defender.
Just Goto RANSOMWARE Protection and allow your Know App like Putty or MoBaExtreme etc.
answered Apr 22, 2020 at 5:44
After trying almost everything, this solved the issue for me:
I downloaded the latest version of PuTTYgen (0.77) and loaded the private key (.ppk) file. I then proceeded to [Save Private Key] and saved it under a different name.
This resolved the issue for me.
answered Aug 31, 2022 at 9:58
MDeMDe
3831 gold badge4 silver badges8 bronze badges
I had the same issue while connecting to openshift Labs.
Stopped working for a new server. I had to Upload public key to OPENTLC again and it worked with the Putty
In PuTTY, under Category on the left, navigate to Connection → SSH → Auth.
On the right under Authentication parameters, click Browse and locate the private key saved from PuttyGen
answered Oct 31, 2019 at 17:31
I faced the same error and this is what worked for me.
- In the Category pane, expand Connection, expand SSH, and then choose Auth.
- Complete the following: Choose Browse. Select the .ppk file that you
generated for your key pair and choose Open.
AWS Docs reference link: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html
answered Dec 29, 2021 at 16:57
AtindraAtindra
1111 gold badge3 silver badges9 bronze badges
I am using CPanel and I forgot to authorize the key so it kept giving me that error..then I had some caffeine and realized I needed to authorize. Problem solved!
answered Jul 6, 2022 at 12:08
Restarting the machine and re-installing FileZilla and then connecting again solved my issue.
answered Nov 16, 2021 at 14:42
1
This issue I could resolve by using .ppk file instead of .pem file.
The above worked for me.
Yunnosch
25.9k9 gold badges42 silver badges54 bronze badges
answered Mar 8, 2021 at 12:12
user3593025user3593025
212 silver badges10 bronze badges
4
I have a 12.10 server setup in a virtual machine with its network set to bridged (essentially will be seen as a computer connected to my switch).
I installed opensshd via apt-get and was able to connect to the server using putty with my username and password.
I then set about trying to get it to use public/private key authentication. I did the following:
- Generated the keys using PuttyGen.
- Moved the public key to
/etc/ssh/myusername/authorized_keys(I am using encrypted home directories). -
Set up
sshd_configlike so:PubkeyAuthentication yes AuthorizedKeysFile /etc/ssh/%u/authorized_keys StrictModes no PasswordAuthentication no UsePAM yes
When I connect using putty or WinSCP, I get an error saying No supported authentication methods available (server sent public key).
If I run sshd in debug mode, I see:
PAM: initializing for "username"
PAM: setting PAM_RHOST to "192.168.1.7"
PAM: setting PAM_TTY to "ssh"
userauth-request for user username service ssh-connection method publickey [preauth]
attempt 1 failures 0 [preauth]
test whether pkalg/pkblob are acceptable [preauth[
Checking blacklist file /usr/share/ssh/blacklist.RSA-1023
Checking blacklist file /etc/ssh/blacklist.RSA-1023
temporarily_use_uid: 1000/1000 (e=0/0)
trying public key file /etc/ssh/username/authorized_keys
fd4 clearing O_NONBLOCK
restore_uid: 0/0
Failed publickey for username from 192.168.1.7 port 14343 ssh2
Received disconnect from 192.168.1.7: 14: No supported authentication methods available [preauth]
do_cleanup [preauth]
monitor_read_log: child log fd closed
do_cleanup
PAM: cleanup
Why is this happening and how can I fix this?
Eric Carvalho
53.4k102 gold badges134 silver badges162 bronze badges
asked Oct 22, 2012 at 1:10
2
Problem solved:
Looks like there was a problem with my public key file. PuttyGen will create a public key file that looks like:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20121022"
AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwu
a6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOH
tr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/u
vObrJe8=
---- END SSH2 PUBLIC KEY ----
However, this will not work, so what you need to do is to open the key in PuttyGen, and then copy it from there (this results in the key being in the right format and in 1 line):
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20121022
Paste this into authorized_keys then it should work.
answered Oct 22, 2012 at 1:47
F21F21
4,2495 gold badges24 silver badges23 bronze badges
9
- Edit the
/etc/ssh/sshd_configfile. - Change
PasswordAuthenticationandChallengeResponseAuthenticationtoyes.
3a. Restart ssh /etc/init.d/ssh restart.
OR
3b. better you use service sshd restart
waltinator
34.6k19 gold badges57 silver badges93 bronze badges
answered Aug 19, 2015 at 12:35
HunterHunter
5294 silver badges2 bronze badges
8
Just a tip I hope may help someone else with the headaches I had. F21 is right that you need to copy the key out of the PuTTYGen window instead of saving the file, but after copying, the way you paste may have significant impact on whether your key will work or not. Some editors will alter the text as you paste, or do something with newlines or something that makes the authorized_keys file invalid.
What I have found to be the least likely to break is to echo the full string and redirect the output to the file. Right-clicking in PuTTY to paste the key string to the commandline, it works out like this (with the example given above):
echo [right-click-to-paste-here] > /etc/ssh/username/authorized_keys
You’ll end up with this:
echo ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAhGF6GIuMY8FJ1+CNApnSY1N2YSlkYz72Yvwua6N1nFpBklz1+dsIMg4rcTLcF34M/tW5Yz+NUDAw2AEbxQ32FPgw7sAOIXktkYOHtr7mmimiTjkoSCrJh1kqalPSpi8rglT/Bp67Ql2SZwvUFfMzHISryR0EZC4rXP/uvObrJe8= rsa-key-20121022 > /etc/ssh/username/authorized_keys
Another advantage of this method is that you can add multiple keys this way by using >> to append instead of > to overwrite, eg:
echo ssh-rsa AAAAB3<...snip...>rJe8= rsa-key-20121022 >> /etc/ssh/username
Hope that helps someone.
answered Feb 27, 2013 at 1:04
DaveDave
1411 silver badge2 bronze badges
4
We were already using the right type of key (ppk instead of pem).
In our case, it was a problem with the file permissions for authorized_keys on the server user folder. It has to be -rw-r--r-- … It was -rw-rw-r--.
SSH is very finicky about file perms.
Check file permissions using:
ls -l authorized_keys
You can fix them if necessary with:
chmod 644 authorized_keys
matigo
19.3k6 gold badges35 silver badges63 bronze badges
answered Mar 13, 2015 at 18:50
SharadSharad
1411 silver badge2 bronze badges
6
SOLVED:
- You need to download the puttyGEN and generate a public and a private key.
- I’ve assigned a password to my private key.
- then configure the private key in putty. Putty->SSH->Auth->Browse to your private.
- You need to configure the public key on the server. (In my case I’ve talked with the server guy and asked if he could add my public key to the server). You need the public key in the other side (server) the connection.
answered Apr 17, 2013 at 9:38
1
In my case the reason was that private key file (.ppk) had been removed in Putty authentication agent i.e. Pageant. I just updated it again to Pageant there and connection worked perfectly after that.
answered Jan 17, 2014 at 17:58
Marko HMarko H
811 silver badge1 bronze badge
Filezilla SSH – cPanel Instructions
Set Filzilla to SSH/SFTP using the site manager.
Set to use authorisation by Key File
For me I had to go into cPanel and then create a key. REMEMBER your password you need it in a minute.
Then “authorize” my key.
Convert your key to PPK in cPanel. You need your password.
Download it & save it somewhere you remember.
Use the Browse option in Filezilla SFTP settings and then upload it.
Then I also had to change my “username” in Filezilla from id_rsa to my cPanel account name. After that things worked well.
As an additional note, instead of using my remote directory as /public_html/ which I would for FTP I had to change it to the full directory /home/YourCpanelUserName/public_html
Hope that that helps someone.
In one case I had MOVED my PPK into a sub folder which was the issue.
Решение этой ошибки стоило много времени, чтобы решить ее, и не смогли найти решение для нее в Интернете, но после некоторой помощи от поддержки AWS нам удалось ее решить, поэтому мы делимся ею, надеясь, что это поможет другим.
Предпосылка
Мы пытались подключиться к Ubuntu AWS EC2 через PuTTy (мы пробовали и другие альтернативы), но когда мы это делаем, то получаем сообщение об ошибке «Disconnected: No supported authentication methods available (server sent: publickey)»
Поиск проблемы
Эта ошибка может возникать при следующих обстоятельствах:
- Вы не подключаетесь к соответствующему имени пользователя для AMI, когда вы подключаете сеанс SSH с экземпляром EC2.
- Вы используете неправильный закрытый ключ, когда вы используете сеанс SSH с экземпляром EC2.
Если вы подключаетесь к соответствующему имени пользователя, убедитесь, что вы используете правильный закрытый ключ, выполнив следующие шаги:
- Войдите в свою учетную запись AWS и откройте консоль Amazon EC2.
- В навигационной панели выберите Экземпляры.
- Найдите экземпляр EC2, к которому вы хотите подключиться, используя SSH.
- В столбце «Имя ключа» проверьте имя закрытого ключа, который вы используете для подключения через SSH.
Если вы используете PuTTY:
Убедитесь, что закрытый ключ SSH соответствует закрытому ключу, который вы видите в столбце «Имя ключа» для вашего экземпляра EC2 в консоли. Если ваш экземпляр основан на ОС Ubuntu, имя пользователя по умолчанию должно быть ubuntu.
Убедитесь, что файл приватного ключа (.pem) преобразован в формат, распознанный PuTTY (.ppk). Дополнительные сведения см. В разделе Преобразование личного ключа с помощью PuTTYgen.
- проблема с каталогом, который содержит ключ ssh (/home/ubuntu)
В нашем случае мы случайно выполнили команду sudo chmod -R 777. для каталога EC2 «/home/ubuntu», поэтому это привело к отказу доступа к EC2, и неправильное разрешение было похоже на следующее:
Неправильная разрешающая способность EC2
Между тем, правильное разрешение должно быть таким:
Право доступа EC2
Чтобы решить эту проблему, нам пришлось создать экземпляр восстановления в том же AZ, что и поврежденный экземпляр (в случае выбора другого неправильного AZ вы не сможете использовать + прикреплять тома от подверженного воздействия экземпляра, который должен быть прикреплен + монтирован на экземпляр восстановления для работы над разрешениями).
- Создайте EC2 в одной и той же зоне доступности затронутого экземпляра
- Остановите затронутый экземпляр.
- Отсоедините том затронутого экземпляра
- Прикрепите том к новому экземпляру восстановления
- Подключитесь к экземпляру восстановления
- Смонтируйте том на экземпляре восстановления, как показано ниже.
sudo mkdir /mountpoint
cd ../
lsblk # to know where the new volume is attached, in my case "/dev/xvdf1"
sudo mount /dev/xvdf1/mountpoint # mount step
/dev/xvdf1 # this gave me permission denied
cd /mountpoint/var/log
ls
nano auth.log
Это покажет вам причину ошибки, которая является “Authentication refused: bad ownership or modes for file /home/ubuntu/.ssh/authorized_keys”
ls -l /mountpoint/home/ubuntu/.ssh/authorized_keys
sudo chmod 600 /mountpoint/home/ubuntu/.ssh/authorized_keys
чтобы убедиться, что разрешение было обновлено
ls -l /mountpoint/home/ubuntu/.ssh/authorized_keys
следующий шаг:
ls -ld /mountpoint//home/ubuntu/.ssh/
sudo chmod 700 /mountpoint/home/ubuntu/.ssh
ls -ld /mountpoint//home/ubuntu
sudo chmod 755 /mountpoint/home/ubuntu/
ls -ld /mountpoint//home/ubuntu
ls -ld /mountpoint//home/
Следующее:
- Остановите экземпляр восстановления
- Отсоедините том удаляемого экземпляра от восстановления
- Прикрепите том к затронутому экземпляру
-
- Запустите экземпляр
- Подключитесь к экземпляру через PuTTY
Вуаля, теперь вы можете подключаться правильно без ошибок.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
