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,7754 gold badges36 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,52513 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 badges136 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,2595 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.8k19 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.5k6 gold badges37 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
No supported authentication methods available server sent publickey is an error message commonly encountered when trying to access a remote server through SSH. This complete guide gives detailed information on why this error message occurs and how you can resolve it, so let’s start!
Contents
- Why Does the No Supported Publickey Error Message Occur?
- – Incorrect Public and Private Keys
- – Incorrect Username
- – Public Key Authentication Is Disabled
- – Incorrect Permissions
- – Firewall or Network Issues
- How To Resolve the No Supported Publickey Error Message?
- – Verify the Public Key
- – Check the File Permissions
- – Check SSH Agent
- – Verify the Server Settings
- Conclusion
Why Does the No Supported Publickey Error Message Occur?
The “no supported publickey” error message occurs when a user tries to authenticate with a remote server using SSH, but the server cannot verify the user’s identity. It indicates that the server rejected the authentication request because it could not find a valid private key.
– Incorrect Public and Private Keys
An incorrect public key error can occur when the public key used for authentication is invalid or corrupted. A private key and a public key are required for public key authentication. The public key is used for encrypting the data, while the private key is used for decrypting it.
When you connect to an SSH server, you must provide the public key to authenticate yourself. The server then checks this public key against the corresponding private key that is stored on the server. If the server cannot find the correct matching private key for your public key, or if the public key is malformed or invalid, you will receive an incorrect public key error.
– Incorrect Username
An “Incorrect username” error can occur when you are using a different username to connect to the server than the one associated with your public key. When you connect to an SSH server, you must provide your username along with your public key to authenticate yourself.
– Public Key Authentication Is Disabled
A “Public key authentication disabled” error can occur when the SSH server does not allow public key authentication. SSH servers typically support multiple authentication-methods, including password authentication and public key authentication. However, some servers may disable certain authentication-methods for security reasons.
Let’s see an example below:
AuthorizedKeysFile .ssh/authorized_keys
The settings are set to “no,” so you will receive the Public key authentication disabled error when trying to connect to the server using public key authentication.
– Incorrect Permissions
An “Incorrect permissions” error can occur when the permissions on the files or directories associated with your SSH public keys or private keys are not set correctly. SSH requires specific permissions on the files and directories that store the public and private keys to ensure the usage of authorized users only.
Let’s look at the example below.
chmod 777 ~/.ssh/authorized_keys
chmod 777 ~/.ssh/id_rsa
chmod 777 ~/.ssh/id_rsa.pub
This sets the permissions to 777, which allows anyone to read, write, and execute the files and directories. This is not recommended for SSH keys as it poses a significant security risk.
– Firewall or Network Issues
A “Firewall or network issues” error can occur when there are network connectivity issues between your computer and the SSH server. Various factors, such as firewalls, network congestion, or routing problems, can cause this.
Firewalls are often used to restrict network traffic and can sometimes block SSH connections. If you try to connect to an SSH server through a firewall, you may need to configure the firewall to allow SSH traffic.
Network congestion can also cause SSH connection problems. When the network is congested, packets may be dropped, and the SSH connection may be interrupted.
How To Resolve the No Supported Publickey Error Message?
To resolve the “no supported publickey” error message, you can check that the correct public key is associated with the user’s account, make sure that the user’s permissions are set correctly on the server, and verify that the SSH configuration is correct.
– Verify the Public Key
The first thing to verify is whether the public key is correct and matches the private key stored on the local machine. Ensuring the correct public key is uploaded to the remote server is important.
Let’s see its examples.
# Replace ‘public_key_file_path’ with the path to the public key file
public_key_file_path = ‘/path/to/public/key’
# Load the public key from the file
with open(public_key_file_path, ‘rb’) as key_file:
public_key = paramiko.RSAKey.from_private_key(key_file)
# Verify that the key is loaded correctly
if not public_key:
print(‘Error: Unable to load public key’)
else:
print(‘Public key loaded successfully’)
– Check the File Permissions
Ensure that the file permissions for the public key on the local machine are set to 600 (-rw——-). Moreover, ensure that the ~/.ssh/authorized_keys file on the remote machine is set to 644 (-rw-r–r–).
Let’s check its example.
public_key_file_path=’/path/to/public/key’
# Check the file permissions for the public key file
perms=$(stat -c “%a %n” “${public_key_file_path}”)
# Verify that the file permissions are correct
if [[ $perms == “600 ${public_key_file_path}” ]]; then
echo “Public key file permissions are set correctly”
else
echo “Error: Incorrect file permissions for public key file”
fi
– Check SSH Agent
When using SSH to authenticate with a remote server using public-key authentication, an SSH agent can be used to manage the private key(s) required for authentication. The SSH agent is a program that runs in the background and holds decrypted private keys in memory. The SSH client can then use the keys from the agent without prompting the user for the passphrase.
Here’s how to check whether the SSH agent is running and whether the required keys have been added to the agent:
- Check whether the SSH agent is running: To check whether the SSH agent is running, enter this command in a terminal window: $ ps -e | grep ssh-agent. If the SSH agent is running, you should see an output that includes “ssh-agent” and the agent’s process ID (PID).
- Check whether the required keys have been added to the agent: To check whether the required keys have been added to the SSH agent, enter the following command in a terminal window: $ ssh-add -l. If the required keys have been added to the SSH agent, you should see a list of the key fingerprints.
- If the SSH agent is not running, you can start it by entering this command: $ eval “$(ssh-agent -s)”.
- Once the SSH agent is running, you can add the required keys to the agent by entering the following command: $ ssh-add /path/to/private/key. This command will prompt you to enter the passphrase for the private key. After entering the passphrase, the key will be added to the SSH agent and can be used for authentication without further prompting.
– Verify the Server Settings
Check the server’s SSH settings and make sure that public key authentication is allowed. It’s also important to check that the SSH daemon is running on the remote machine. Let’s see an example below.
server_ip=’192.168.1.100’
# Verify the server settings
ssh -v “$server_ip”
This code uses the ssh command with the -v option to establish a verbose SSH connection to the server with the IP address specified in the server_ip variable. The verbose output will provide information about the server settings, such as the authentication-methods and key exchange algorithms that are supported by the server.
Conclusion
When you are trying to connect to a remote server via SSH (Secure Shell), you may encounter an error message that says something similar to the error message. Here are some key takeaways.
- This error happens if the server is set up to only allow certain types of authentication and your SSH client doesn’t have a valid key or credential that matches what the server expects.
- One common cause of this error is when you’re using SSH key-based authentication, but your private key isn’t recognized by the server. This can happen if the server doesn’t have your public key on file or if you’re using the wrong key file or passphrase.
- Another cause of this error is if the server is configured to use a different authentication method, such as password-based authentication or a different type of public key.
- In this case, you may need to adjust your SSH client settings or ask the server administrator to change the authentication method.
Thank you for reading!
- Author
- Recent Posts
Your Go-To Resource for Learn & Build: CSS,JavaScript,HTML,PHP,C++ and MYSQL. Meet The Team
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.