Error: Permission denied (publickey)
A «Permission denied» error means that the server rejected your connection. There could be several reasons why, and the most common examples are explained below.
Should the sudo command or elevated privileges be used with Git?
You should not be using the sudo command or elevated privileges, such as administrator permissions, with Git. If you have a very good reason you must use sudo , then ensure you are using it with every command (it’s probably just better to use su to get a shell as root at that point). If you generate SSH keys without sudo and then try to use a command like sudo git push , you won’t be using the same keys that you generated.
Check that you are connecting to the correct server
Typing is hard, we all know it. Pay attention to what you type; you won’t be able to connect to «githib.com» or «guthub.com». In some cases, a corporate network may cause issues resolving the DNS record as well.
To make sure you are connecting to the right domain, you can enter the following command:
The connection should be made on port 22, unless you’re overriding settings to use SSH over HTTPS.
Always use the «git» user
All connections, including those for remote URLs, must be made as the «git» user. If you try to connect with your GitHub username, it will fail:
If your connection failed and you’re using a remote URL with your GitHub username, you can change the remote URL to use the «git» user.
You should verify your connection by typing:
Make sure you have a key that is being used
- Open Terminal Terminal Git Bash .
- Verify that you have a private key generated and loaded into SSH.
If you have GitHub Desktop installed, you can use it to clone repositories and not deal with SSH keys.
If you are using Git Bash, turn on ssh-agent:
If you are using another terminal prompt, such as Git for Windows, turn on ssh-agent:
Verify that you have a private key generated and loaded into SSH.
- Open Terminal Terminal Git Bash .
- Verify that you have a private key generated and loaded into SSH.
The ssh-add command should print out a long string of numbers and letters. If it does not print anything, you will need to generate a new SSH key and associate it with GitHub.
Tip: On most systems the default private keys (
/.ssh/identity ) are automatically added to the SSH authentication agent. You shouldn’t need to run ssh-add path/to/key unless you override the file name when you generate a key.
Getting more details
You can also check that the key is being used by trying to connect to git@github.com :
In that example, we did not have any keys for SSH to use. The «-1» at the end of the «identity file» lines means SSH couldn’t find a file to use. Later on, the «Trying private key» lines also indicate that no file was found. If a file existed, those lines would be «1» and «Offering public key», respectively:
Verify the public key is attached to your account
You must provide your public key to GitHub to establish a secure connection.
Start SSH agent in the background.
Find and take a note of your public key fingerprint.
In the upper-right corner of any page, click your profile photo, then click Settings.
In the «Access» section of the sidebar, click
SSH and GPG keys.
Compare the list of SSH keys with the output from the ssh-add command.
Open the command line.
Start SSH agent in the background.
Find and take a note of your public key fingerprint.
In the upper-right corner of any page, click your profile photo, then click Settings.
In the «Access» section of the sidebar, click
SSH and GPG keys.
Compare the list of SSH keys with the output from the ssh-add command.
Start SSH agent in the background.
Find and take a note of your public key fingerprint. If you’re using OpenSSH 6.7 or older:
If you’re using OpenSSH 6.8 or newer:
In the upper-right corner of any page, click your profile photo, then click Settings.
In the «Access» section of the sidebar, click
SSH and GPG keys.
Compare the list of SSH keys with the output from the ssh-add command.
If you don’t see your public key in GitHub, you’ll need to add your SSH key to GitHub to associate it with your computer.
Warning: If you see an SSH key you’re not familiar with on GitHub, delete it immediately and contact GitHub Support, for further help. An unidentified public key may indicate a possible security concern. For more information, see «Reviewing your SSH keys.»
Help us make these docs great!
All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.
Устранение неполадок SSH: ошибки аутентификации
В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки 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-ключей)
Этот метод использует криптографические ключи для аутентификации пользователя.
Читайте также:
Вы можете получить такую ошибку:
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:
Но после ввода пароля появляется ошибка:
После сброса пароля вы получите:
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 должны иметь следующие права:
Кроме того, клиент должен также иметь такие права:
Эти изменения можно внести с помощью консоли.
Проверка открытого и закрытого ключа
Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом
Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.
/.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).
В любом случае этот открытый ключ нужно добавить в файл
OpenSSH 7 и устаревшие ключевые алгоритмы
В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.
Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.
Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.
Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.
Заключение
Если у вас не получается самостоятельно настроить аутентификацию SSH, вы можете обратиться за помощью к службе поддержки своего хостинг-провайдера.
Permission denied (publickey,password). while using ssh to login
I’m trying to login to the server using ssh, and I realise that I forgot my password. I’m using this command:
I don’t know what to do, I searched for a solution but nothing helped me. I’m using Ubuntu 14.04. Any help?
4 Answers 4
If you are not using ssh public key, and you just forget your root password, you can reset your root password using Digital Ocean control panel
If you are using ssh public key and you forget the password to that key, you can force SSH to use your Digital Ocean password instead of the key
If you get Permission denied while using ssh to login, you probably need to edit the /etc/ssh/sshd_config file.
Change PasswordAuthentication value to yes .
I faced a similar problem while trying to ssh into another machine. These steps helped me to get to a solution:
1 — sudo passwd root — Change root password (optional)
2 — sudo install openssh-server
4 — sudo nano sshd_config (Now uncomment line PermitRootLogin and change it to yes, Uncomment Authorized keys file, Uncomment PasswordAuthentication and change it to yes)
5 — sudo systemctl restart ssh
Now you are good to go, and can easily connect over ssh using the root account.
How to Fix SSH Failed Permission Denied (publickey,gssapi-keyex,gssapi-with-mic)
The SSH Permission denied error appears after permission-related settings are modified on the SSH server. Usual scenarios include a new package installation or the creation of new users.
In this tutorial, you will learn how to troubleshoot the SSH Permission denied error and reconnect to your SSH server.
- SSH client on the local machine and SSH server on the remote system
- A user account to access the remote server (for password-based login)
- A user account with sudo or root privileges
What is Causing SSH Permission Denied (publickey,gssapi-keyex,gssapi-with-mic)?
The SSH Permission denied error appears when trying to SSH into a server:
Following the Permission denied statement, the bracket contains the attempted authentication methods that failed at the initiation of the connection. The error suggests that the public key is the issue, which is misleading.
One reason for the error may be sshd_config , the file that contains SSH server configuration. The other possibility is that the authorized_keys file has insufficient permissions. This file contains the list of public keys for the clients allowed to SSH into the server. Consequently, the system’s inability to read from the file results in the Permission denied error.
How to fix SSH Permission denied
Both solutions contain steps you need to perform on the server-side. Start by opening the terminal on your server and proceed with one of the solutions below.
Solution 1: Enable Password Authentication
If you want to use a password to access the SSH server, a solution for fixing the Permission denied error is to enable password login in the sshd_config file.
To do this, open the file in a text editor. This example uses the nano editor:
In the file, find the PasswordAuthentication line and make sure it ends with yes .
Find the ChallengeResponseAuthentication option and disable it by adding no .
If lines are commented out, remove the hash sign # to uncomment them.
Save the file and exit.
Restart the SSH service by typing the following command:
Solution 2: Change File System Permissions
Using the password-based login as the SSH authentication method is not recommended due to security concerns. Therefore, the following solution may be preferable since it troubleshoots the public key authentication method.
First, open the sshd_config file using a text editor:
In the file, make sure the following options are set as follows:
Note: The steps above are considered best security practices. If you need to use root login, set the relevant line to yes .
Comment out the GSSAPI-related options by adding the hash sign at the beginning of the line:
Also, make sure the UsePAM line is set to yes :
Save the file and restart the sshd service:
Now navigate to your home folder and check the permissions:
If your owner permissions are not set to read, write, and execute ( drwx—— ), use the chmod command to change them:
Now go to the .ssh folder and recheck the permissions:
This directory should also have read, write, and execute permissions for the file owner. To enforce them, use chmod again:
The .ssh folder contains the authorized_keys file. Check its permissions with:
The file owner should have read and write permissions. To set them, use:
Now try logging in with the key pair again. The output below shows a successful login attempt.
Note: For more information about Linux file permission, read the Linux File Permissions Tutorial.
This tutorial covered the steps necessary to troubleshoot the SSH Permission denied (publickey,gssapi-keyex,gssapi-with-mic) error. By completing the steps in the guide, you should fix the error and successfully SSH into your server.