Permission denied publickey password как исправить

Ошибка: отказано в разрешении (publickey)

Ошибка «Отказано в разрешении» означает, что сервер отклонил подключение. Ниже приведено несколько причин и разъяснение по самым распространенным примерам.

Platform navigation

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:

$ ssh -vT git@github.com > OpenSSH_8.1p1, LibreSSL 2.7.3 > debug1: Reading configuration data /Users/YOU/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 47: Applying options for * > debug1: Connecting to github.com port 22. 

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:

$ ssh -T GITHUB-USERNAME@github.com > Permission denied (publickey). 

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:

$ ssh -T git@github.com > Hi USERNAME! You've successfully authenticated.  

Make sure you have a key that is being used

1. Open Terminal Terminal Git Bash .
2. Verify that you have a private key generated and loaded into SSH.

# start the ssh-agent in the background $ eval "$(ssh-agent -s)" > Agent pid 59566 $ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

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:

# start the ssh-agent in the background $ eval "$(ssh-agent -s)" > Agent pid 59566 

If you are using another terminal prompt, such as Git for Windows, turn on ssh-agent:

# start the ssh-agent in the background $ eval $(ssh-agent -s) > Agent pid 59566 

Note: The eval commands above start ssh-agent manually in your environment. These commands may fail if ssh-agent already runs as a background system service. If that happens, we recommend you check the relevant documentation for your environment.

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

1. Open Terminal Terminal Git Bash .
2. Verify that you have a private key generated and loaded into SSH.

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

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/id_rsa and ~/.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 :

$ ssh -vT git@github.com > . > debug1: identity file /Users/YOU/.ssh/id_rsa type -1 > debug1: identity file /Users/YOU/.ssh/id_rsa-cert type -1 > debug1: identity file /Users/YOU/.ssh/id_dsa type -1 > debug1: identity file /Users/YOU/.ssh/id_dsa-cert type -1 > . > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Trying private key: /Users/YOU/.ssh/id_rsa > debug1: Trying private key: /Users/YOU/.ssh/id_dsa > debug1: No more authentication methods to try. > Permission denied (publickey). 

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:

$ ssh -vT git@github.com > . > debug1: identity file /Users/YOU/.ssh/id_rsa type 1 > . > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /Users/YOU/.ssh/id_rsa 

Verify the public key is attached to your account

You must provide your public key to GitHub to establish a secure connection.

1. Open Terminal.
2. Start SSH agent in the background.

$ eval "$(ssh-agent -s)" > Agent pid 59566 

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

In the upper-right corner of any page, click your profile photo, then click Settings.

1. Open the command line.
2. Start SSH agent in the background.

$ ssh-agent -s > Agent pid 59566 

$ ssh-add -l -E sha256 > 2048 SHA256:274ffWxgaxq/tSINAykStUL7XWyRNcRTlcST1Ei7gBQ /Users/USERNAME/.ssh/id_rsa (RSA) 

In the upper-right corner of any page, click your profile photo, then click Settings.

1. Open Terminal.
2. Start SSH agent in the background.

$ eval "$(ssh-agent -s)" > Agent pid 59566 

$ ssh-add -l > 2048 a0:dd:42:3c:5a:9d:e4:2a:21:52:4e:78:07:6e:c8:4d /Users/USERNAME/.ssh/id_rsa (RSA) 

If you’re using OpenSSH 6.8 or newer:

$ ssh-add -l -E md5 > 2048 MD5:a0:dd:42:3c:5a:9d:e4:2a:21:52:4e:78:07:6e:c8:4d /Users/USERNAME/.ssh/id_rsa (RSA) 

In the upper-right corner of any page, click your profile photo, then click Settings.

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 us through the GitHub Support portal for further help. An unidentified public key may indicate a possible security concern. For more information, see «Reviewing your SSH keys.»

SSH Permission denied (publickey) [Решено]

Youpiter — 28 Апрель, 2013 — 13:15

Первое, что бросается в глаза: ssh слушает 22 порт, а подключиться пытаетесь через 2042

yarmol76 — 28 Апрель, 2013 — 15:28

На сервере это порт 2042. Если я указываю неправильный порт, то выводится «ssh: connect to host xx.xx.xx.xx port 22: Connection timed out». То есть порт можно уточнять в команде ssh, что я и делаю. Значит ошибка не в этом.

dm — 28 Апрель, 2013 — 15:03

3) скопировал публичный ключ id_dsa.pubв домашнюю директорию на удалённый сервер

Вероятно по этой причине не работает, так как по умолчанию ssh ищет ключи в файле ~/.ssh/authorized_keys а не в домашней директории. По этому либо копируй ключ правильно на сервер командой

ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine

либо на сервере редактируй конфиг sshd_conf, опция AuthorizedKeysFile

yarmol76 — 28 Апрель, 2013 — 15:16

Уточню, что скопировал я ключ туда, куда сказал администратор. в директорию ~/.ssh/
Доступа к конфигу на удалённом сервере не имею.
Статью по ссылке я читал. Всё практически выполняю как там написано, но ошибка, вероятно, в каких-то особых конфигах скрыта.

dm — 28 Апрель, 2013 — 15:17

При настройках по умолчанию у тебя на клиентской стороне ключи должный быть в папке
$HOME/.ssh/
что-то типа id_dsa, id_dsa.pub

На стороне сервера публичные ключи хранятся в файле
$HOME/.ssh/authorized_keys

yarmol76 — 28 Апрель, 2013 — 15:28

Администратор мне сообщил, что публичный ключ id_dsa.pub нужно поместить в ~/.ssh, что я и сделал.
У меня на компьютере я знаю где хранится приватный ключ, и я могу указать его расположение явно так: ssh -p 2042 [email protected] -i ~/.ssh/id_dsa. Но это не помогает.

yarmol76 — 28 Апрель, 2013 — 15:28

Кстати, не очень понятно, как можно использовать команду ssh-copy-id, которая работает при помощи ssh, если сам ssh я ещё не настроил?
Я так сделал и мне вывелось: /usr/bin/ssh-copy-id: ERROR: No identities found

dm — 28 Апрель, 2013 — 15:35

Кстати, не очень понятно, как можно использовать команду ssh-copy-id, которая работает при помощи ssh, если сам ssh я ещё не настроил?

Имеется в виду, что есть доступ на сервер и до копирования ключей в ssh работает авторизация по паролю.

Можно попробовать на сервере из папки .ssh сделать

cat id_dsa.pub >> authorized_keys

это добавит ключ в конец файла authorized_keys

yarmol76 — 28 Апрель, 2013 — 15:52

Файл «authorization» с текстом «key id_dsa.pub» я также создал, как и требовал администратор. Это было сделано с самого начала.

yarmol76 — 1 Май, 2013 — 09:43

Ещё интересный момент. Администратор сервера предложить скачать и скомпилировать из исходных кодов свою особую программу и использовать её для создания файла ключей и подключения по ssh? o_O Что это может значить? Особый безопасный шел?

yarmol76 — 2 Май, 2013 — 12:38

Проблема решена с помощью программы PuTTY и генерирования ключей с помощью команды puttygen. Может кому пригодится, что ключи в openssh и putty это не одно и тоже.

Гость — 3 Ноябрь, 2020 — 09:13

Забавно. Ответ из 2013 помог с Яндекс.Облако в 2020

witus — 11 Январь, 2021 — 12:33

Строка: ssh-copy-id -i ~/.ssh/id_dsa.pub user@machine просто спасла меня после недели мучений.

490 — 4 Март, 2021 — 04:44

Вы всю ветку обсуждаете файл id_dsa.pub, хотя в статье о генерации ключей идет речь о файле id_rsa.pub. Даже там специально выделили жирным шрифтом.
Второе: в файле sshd_config парметр AuthorizedKeysFile надо раскомментить

ssh -p 2042 [email protected] -i ~/.ssh/id_dsa

Гость — 14 Апрель, 2021 — 13:07

У меня файл называется mySSH3 и он находится в домашнем каталоге. Почему-то при рестрате Ubuntu 18 про него забывает и приходится вновь будить ssh-agent и делать в домашнем каталоге где этот файл) ssh-add ./mySSH3

Гость — 30 Январь, 2022 — 01:48

Мне при ошибке Permission denied (publickey,password) помогло следующее:
На сервере проверил права на ~/.ssh/authorized_keys, оказалось -rw——-.
Я включил для «other» только чтение:
chmod o+r .ssh/authorized_keys
После чего заработало.

Как исправить ошибку аутентификации SSH

Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.

В чем суть ошибки

У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.

Аутентификация — это проверка подлинности. Например, у вас есть сервер на timeweb.cloud . Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.

Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.

Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:

Permission denied (publickey)

Но причины появления ошибки не ограничиваются только неправильным паролем или не теми ключами. Сбой может возникать также из-за повреждения системных файлов или неверно выставленных прав доступа.

Ниже разберемся с наиболее частыми ситуациями.

Ошибка при использовании пароля

Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:

1. Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
2. Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
3. Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.

С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.

Ошибка при использовании ключей

Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.

Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке:

Too many authentication failures for user

Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:

ssh -o IdentitiesOnly=yes \ 
-o IdentityFile=id1.key \ 
user@example.com

Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH ~/.ssh/config. Пример такой настройки:

Host 192.168.3.44 
IdentityFile ~/.ssh/id_rsa
Host * 
IdentitiesOnly=yes

В этом случае SSH будет использовать только идентификаторы, указанные в файлах ssh_config, плюс идентификатор, указанный в командной строке. Идентификаторы, предоставленные агентом, будут игнорироваться.

При использовании ssh-ключей может возникнуть еще одна ошибка:

Permission denied (publickey, password)

Ее причиной может быть ввод неверной ключевой фразы.

Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.

Восстановление открытого ключа

Если у вас есть закрытый ключ, но вы потеряли открытую часть, то эту проблему можно решить стандартными средствами OpenSSH.

Самый просто способ — использовать утилиту ssh-keygen.

Запустите терминал и выполните команду:

ssh-keygen -y -f ~/.ssh/id_rsa

Здесь ~/.ssh/id_rsa — это путь к закрытому части, которая хранится на компьютере. В ответ вы получите последовательность символов. Это и есть открытая часть, которую необходимо добавить на сервер.

В среде Windows решить ту же задачу можно с помощью утилиты PuTTYgen, которая входит в набор PuTTY. В ней есть кнопка Load, через которую вы можете загрузить закрытый ключ. Для этого нужно лишь знать директорию, в которой он хранится на компьютере.

После импорта вы увидите окно с полем `Public key for…`. В нём отобразится открытая часть, которую можно скопировать и отправить на сервер.

Восстановить закрытую часть по открытой нельзя — это противоречит основам безопасности.

На что еще обратить внимание

У понятия « authentication failed» перевод дает весьма общее представление о причине сбоя. Проблема может крыться не только в пароле или ключах. Значение имеют также выставленные права доступа и алгоритмы шифрования.

Неправильная конфигурация клиента

Распространенная ошибка — использование клиента SSH/SFTP (SSH, PuTTY, Filezilla) без правильной настройки всех необходимых параметров, таких как хост, порт, имя пользователя или закрытый ключ.

Другая частая проблема возникает, когда вы используете неподдерживаемый сертификат. Например, пытаетесь добавить в PuTTY файл ключа *.pem вместо файла ключа *.ppk.

Противоречия в файле конфигурации

Убедитесь, что в файле /etc/ssh/sshd_config установлены параметры, которые не противоречат друг другу. Такое может быть, например, при отключении парольной проверки или запрете на подключение для пользователя root.

Распространенный пример конфликта: у параметра PasswordAuthentication установлено значение `yes`, а у параметра PermitRootLogin — значение `no` или `without-password`. Из-за этого сервер не понимает, как проверять пользователей, и не пускает никого.

Настройка прав доступа

У OpenSSH строгие правила к тому, кто должен быть владельцем файлов и какие на них должны быть выставлены права доступа.

Убедитесь, что на сервере выставлены следующие доступы:

• ~./ssh – 700.
• ~./ssh принадлежит текущему аккаунту.
• ~/.ssh/authorized_keys – 600.
• ~/.ssh/authorized_keys принадлежит текущему аккаунту.

На клиенте также проверьте разрешения следующих файлов:

• ~ / .ssh / config – 600.
• ~ / .ssh / id_ * – 600.

Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.

Использование устаревших алгоритмов

В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.

Если у вас старые ключи, оптимальное решение — сгенерировать и добавить на хосты новые, которые основаны на более стойких алгоритмах.

Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.

Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:

ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost

Ошибки на сторонних сервисах

Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session . Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.

Заключение

Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.

Почему не пускает по ssh (Permission denied (publickey)) со второго IP?

Настроен доступ по SSH к удалённой машине с помощью ключей. Ключ скопирован с клиента на сервер.
Доступ по: ssh external_ip
отлично работает.
На удаленной машине поднят OpenVPN-сервер. При попытке доступа по IP tun-интерфейса (10.8.0.1) приводит к ошибке «Permission denied (publickey)».
Судя по логам (ssh -v) проблема в том, что во втором случае SSH не может найти нужный ключ в ~/.ssh/known_hosts — у меня нестандартное имя файла ключа (для разных машин разные ключи).
Подключение с явным указанием файла ключа проходит, но, видимо, не добавляет запись в ~/.ssh/known_hosts — повторная попытка соединиться без указания файла приводит к той же ошибке.
Ясности не добавляет то, что файл ~/.ssh/known_hosts хэширован — IP удаленных машин не видны.
Как можно сделать так, чтобы клиент SSH запомнил, что есть 1 и тот же ключ для 2 разных IP удаленных машин?

Лог успешного подключения

debug1: Server host key: ssh-ed25519 SHA256:_some_host_key_ debug1: Host '10.8.0.1' is known and matches the ED25519 host key. debug1: Found key in /home/user/.ssh/known_hosts:7 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: ED25519 SHA256:_some_key_ .ssh/id_ed25519_my_remote_machine debug1: Server accepts key: pkalg ssh-ed25519 blen 51 debug1: Authentication succeeded (publickey).

Лог подключения с ошибкой

debug1: Server host key: ssh-ed25519 SHA256:_some_host_key_ debug1: Host '10.8.0.1' is known and matches the ED25519 host key. debug1: Found key in /home/user/.ssh/known_hosts:7 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/user/.ssh/id_rsa debug1: Trying private key: /home/user/.ssh/id_dsa debug1: Trying private key: /home/user/.ssh/id_ecdsa debug1: Trying private key: /home/user/.ssh/id_ed25519 debug1: Trying private key: /home/user/.ssh/id_xmss debug1: No more authentication methods to try. user@10.8.0.1: Permission denied (publickey).

• Вопрос задан более трёх лет назад
• 27980 просмотров

1 комментарий

Средний 1 комментарий