В доступе SSH отказано (publickey)

PubKeyAuthentication

Настройте своего клиента

1. Создайте свой ключ.

    ssh-keygen
    

2. Настройте ssh для использования ключа.

    vim ~ / .ssh / config
    

3. Скопируйте свой ключ на свой сервер.

    ssh-copy-id -i /path/to/key.pub SERVERNAME`
    

Ваш файл конфигурации из шага 2 должен иметь примерно следующее:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Вы можете добавить IdentitiesOnly yes , чтобы убедиться, что ssh использует ] IdentityFile и никаких других ключевых файлов во время аутентификации, что может вызвать проблемы и не рекомендуется.

Устранение неполадок

1. используйте параметр «-vvv»
2. Убедитесь, что на сервере есть ваш PUBLIC ключ (.pub ).
3. Убедитесь, что ваш файл IdentiyFile указывает на ваш ЧАСТНЫЙ ключ.
4. Убедитесь, что ваш каталог .ssh имеет 700 прав, а файлы внутри - 600 прав.
5. tail -f / var / log /auth.log (на сервере) и отслеживать ошибки при попытке входа в систему
6. Если у вас много файлов ключей, попробуйте IdentitiesOnly yes , чтобы ограничить аутентификацию с использованием одного указанного ключа .

Следующий метод может работать, если у вас есть независимый доступ к machineA и machineB (например, с machineC).

Если ssh-copy-id не работает, аутентификацию по паролю можно отключить. Ниже приводится обходной путь .

Наличие открытого ключа machineA в авторизованных ключах machineB (то есть ~ / .ssh / authorized_keys) позволит вам использовать ssh с machineA. Это также относится к scp.

После генерации пар ключей с помощью: ssh-keygen

На machineA выполните cat ~ / .ssh / id_rsa.pub

Пример вывода:

ssh-rsa AAAAB3NzaSGMFZW7yB anask @ mahineA

Скопируйте распечатанный ключ ( ⌘ Команда + C или CRTL + ), затем 1110330910] добавьте его в файл ~ / .ssh / authorized_keys на machineB .

Например, выполните следующее на machineB :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask @ mahineA '>> ~ / .ssh / authorized_keys

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

AllowGroups ssh #Here only users of 'ssh' group can login

В моем случае проблема была вызвана копированием каталога .ssh со старой машины. Оказалось, что моя старая конфигурация SSH использовала ключи DSA, которые с тех пор устарели . Переход на новую пару ключей, на этот раз на основе RSA, решил проблему для меня.

Также работает на Ubuntu 16.04.

Проблема находится в файле sshd_config

Вот решение ULTIMATE:

Зарегистрируйтесь как root для своего сервера Ubuntu

vi /etc/ssh/sshd_config

Теперь перейдите в самый низ и измените значение с " нет "на" да ".

Это должно выглядеть так:

Измените на нет, чтобы отключить туннелированные пароли в открытом виде

PasswordAuthentication yes
service sshd reload

, чтобы они вступили в силу.

Теперь вы можете просто ввести ключ, используя следующую команду со своего ЛОКАЛЬНОГО компьютер (он же ноутбук и т. д.)

Итак, чтобы открыть новое окно терминала и НЕ входить на сервер, просто используйте эту команду:

ssh-copy-id john @ serverIPAddress

(замените john своим именем пользователя) .

вам должно быть хорошо идти

Некоторые люди, которым интересно, возможно, настроили доступ по ssh к быть ключом только для учетной записи root, затем создал нового пользователя и не осознал, что ему нужно

ssh root @ your-ip-address

rsync --archive --chown = [user]: [user] ~ /. ssh / home / [user]

logout

Затем попробуйте еще раз. Замените [user] своей новой учетной записью.

Это обычное дело при настройке нового сервера в DigitalOcean, когда вы использовали ssh-ключи при настройке.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with- ubuntu-18-04

У меня была такая же проблема, как описано в вопросе.Результат выполнения ssh -vvv -i id_rsa [youruser] @ [yourLinode] на клиентской машине был аналогичен описанному в вопросе. Я проверил все разрешения для файлов и каталогов, как было рекомендовано в других ответах, и они были правильными.

Оказалось, что при копировании сгенерированного файла id_rsa.pub на серверную машину в виде файла ] ~ username / .ssh / authorized_keys , Я бы случайно пропустил слово ssh-rsa с самого начала. Добавление его решило проблему.

Это то, что у меня сработало, исправление не мое, но я бы предпочел записать его здесь на случай, если кто-то другой имеет ту же проблему.

Первоначальный автор разместил это здесь: digital-ocean-public-access-key-denied

sudo nano /etc/ssh/sshd_config

Замените это

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

На это

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Сохраните файл и перезапустите ssh

reload ssh

ssh теперь должен работать, запрашивая пароль

У меня была такая же проблема при копировании открытого ключа обычного пользователя (например, johndoe) из системы cPanel Centos на сервер Ubuntu на AWS. Как было предложено gertvdijk выше, я проверил /var/log/auth.log и, конечно же, он сказал В аутентификации отказано: неправильное владение или режимы для каталога / home / johndoe . Оказалось, что я ошибочно 777'ed / home / johndoe при попытке установить / home / johndoe / public_html в качестве корневого каталога документов виртуального хоста по умолчанию для apache2 (это также не требуется для этой задачи)

См. Также ответы здесь и здесь

Сервер должен иметь только открытый ключ в .ssh / authorized_keys , а клиент (компьютер, на котором вы работаем)должен иметь закрытый ключ (.pem, или, если используется SFTP с Filezilla, .ppk)

Для таких пользователей Putty, как я, которые пришли на этот поток, Вы также можете получить эту ошибку, если забыли добавить пользователя user@Ip!

Другие, имеющие права на ключевой файл chmod на 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file 

Другой возможной причиной может быть конфигурация AllowedUsers в / etc / ssh / sshd_conf . ПРИМЕЧАНИЕ: список разделен пробелами (без запятых), как я узнал трудный путь.

AllowUsers user1 user2 user3

Недавно я столкнулся с этой проблемой на своем веб-сервере.

Обычно я храню список авторизованных ключей на всех моих серверах в ~ / .ssh / authorized_keys2 . По моему опыту, sshd по умолчанию будет искать ~ / .ssh / authorized_keys или ~ / .ssh / authorized_keys2 .

В случае моего на веб-сервере / etc / ssh / sshd_config была эта строка

AuthorizedKeysFile    %h/.ssh/authorized_keys

вместо

AuthorizedKeysFile    %h/.ssh/authorized_keys2

. Я применил последнюю, перезапустил демон ssh и решил проблему со входом в систему с помощью ssh с помощью моего ключа pubkey.

Моя проблема заключалась в использовании неправильных ключей на клиенте. Я переименовал id_rsa и id_rsa.pub во что-то другое. Вы можете либо переименовать их обратно в значения по умолчанию, либо, когда вы введете команду ssh, используйте ее так

ssh -i ~/.ssh/private_key username@host

Также убедитесь, что домашний каталог пользователя (на сервере ) на самом деле принадлежит пользователю ssh'ing (в моем случае было установлено значение root: root).

Должно было быть:

sudo chown username:username /home/username;

Также проверьте значение PasswordAuthentication в / etc / ssh / sshd_config , и если оно нет , измените его на да . После этого не забудьте перезапустить службу ssh.

Вам не нужны authorized_keys на вашем клиенте.

Вы должны указать ssh-клиенту на самом деле использовать созданный вами ключ. Есть несколько способов сделать это. Просто для тестирования введите ssh -vvv -i .ssh / id_rsa [youruser] @ [yourLinode] . Вам нужно будет вводить свою парольную фразу каждый раз, когда вы хотите подключиться к серверу.

Если это сработало, вы можете добавить ключ к ssh-agent с помощью ssh-add .ssh / id_rsa (для этого вам нужно будет указать кодовую фразу только один раз, и это должен работать, пока вы не выходите из системы / не перезагружаетесь)

Иногда проблема возникает из-за разрешений и владельца. Например, если вы хотите войти в систему как root, / root , .ssh и authorized_keys должны принадлежать root. В противном случае sshd не сможет их прочитать и, следовательно, не сможет определить, авторизован ли пользователь для входа в систему.

В вашем домашнем каталоге:

chown -R your_user:your_user .ssh

Что касается прав, выберите 700 для .ssh и 600 для authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

В моем случае клиент ubuntu 14.04lts, на сервере был выигран 2012 сервер под управлением cygwin. Я использовал 'ssh administrator@x.x.x.x', когда каталогом 2012 сервера в cygwin был /home/Administrator. Так что это было чувствительно к регистру, когда я попробовал 'ssh Administrator@x.x.x.x' (обратите внимание на заглавную букву A на Администраторе), то все работало нормально.

Сообщение об ошибке типа 'user not found' привело бы меня к решению намного быстрее, чем 'Permission denied (publickey,keyboard-interactive)'.

Я добавил неправильный ключ на сервер. Поскольку я не использовал команду с возможностью указать определенный ключ, он добавил стандартный файл ключей.

Убедитесь, что вы использовали ssh-copy-id -i CORRECT_KEY.pub

Этот неправильный ключ отлично работал с одним клиентом, потому что у этого клиента тоже был этот ключ. Но при попытке подключиться с другим клиентом к тому же серверу это явно не удалось.

Также может быть интересно то, что вы получаете больше протоколов с помощью ssh -vv вместо одного - v .