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

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

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

У меня была такая же проблема при копировании открытого ключа обычного пользователя (например, johndoe) из системы cPanel Centos на сервер Ubuntu в AWS. Как предложено в gertvdijk выше, я проверил /var/log/auth.log и достаточно точно сказал Authentication refused: bad ownership or modes for directory /home/johndoe. Выяснилось, что 777 неправильно /home/johndoe при попытке установить /home/johndoe/public_html в качестве виртуального корневого каталога документов для apache2 (в этом тоже нет необходимости).

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

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

Работает и в Ubuntu 16.04.

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

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

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

vi /etc/ssh/sshd_config

Теперь перейдите к самому низу и измените значение с «нет» на «да».

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

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

PasswordAuthentication yes
service sshd reload

для вступления в силу.

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

Так что откройте новое окно терминала и НЕ входите на сервер, просто введите эту команду:

ssh-copy-id john @ serverIPAddress

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

Вы должны идти, чтобы идти

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

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

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

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

sudo nano /etc/ssh/sshd_config

Заменить это

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

этим [ 118]

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

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

reload ssh

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

Для тех пользователей 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

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

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

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

Обычно я храню список авторизованных ключей на всех моих серверах в ~/.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.

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

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

sudo chown username:username /home/username;

Также проверьте значение PasswordAuthentication в /etc/ssh/sshd_config и, если оно no, измените его на yes. Не забудьте перезапустить службу 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

As для прав, пойти с 700 для .ssh и 600 для authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

PubKeyAuthentication

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

1. Сгенерируйте свой ключ
   • ssh-keygen
2. Настройте ssh на используйте ключ
   • vim ~/.ssh/config
3. Скопируйте ключ на свой сервер
   • ssh-copy-id -i /path/to/key.pub SERVERNAME
[1125 ]

Ваш файл конфигурации из , шаг 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 указывает на ваш ключ PRIVATE.
4. Убедитесь, что ваш каталог .ssh имеет 700, а ваши файлы имеют разрешения 700 (rwx ------).
5. tail -f /var/log/auth.log (на сервере) и отслеживайте ошибки при попытке входа в систему
6. Если у вас много файлов ключей, попробуйте IdentitiesOnly yes ограничить аутентификацию для использования одного указанного ключа. [1124 ]

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

Сообщение об ошибке типа «пользователь не найден» привело бы меня к решению намного быстрее, чем «Отказано в доступе (publickey, клавиатура-интерактивная)».

Следующий метод может работать, если вы можете обращаться к машине A и машине B независимо (например, от машины C).

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

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

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

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

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

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

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

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

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

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

ssh root@your-ip-address

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

logout

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

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

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