Я пытаюсь подключиться к Linode (с Ubuntu 12.04 LTS) с моей локальной машины (также с Ubuntu 12.04 LTS)

Я создал закрытый и открытый ключ на своем локальном компьютере и скопировал мой открытый ключ в файл author_keys моего Linode. Тем не менее, всякий раз, когда я пытаюсь подключиться к моему Linode, я получаю сообщение об ошибке Permission denied (publickey).

Это не проблема с тем, как ssh настроен на моем Linode, потому что я могу подключиться к ssh с моего компьютера Windows с помощью аутентификации по ключу.

В моей .sshдиректории на моей локальной машине Ubuntu, у меня есть id_rsaи id_rsa.pubфайлы. Нужно ли мне создавать файл author_keys на моей локальной машине?

РЕДАКТИРОВАТЬ: Это то, что я получаю, когда я бегу ssh -vvv -i id_rsa [youruser]@[yourLinode]:

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (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, а ваши файлы имеют 700 разрешений (rwx ------).
5. tail -f /var/log/auth.log (на сервере) и отслеживать ошибки при попытке входа
6. Если у вас много файлов ключей, попробуйте IdentitiesOnly yesограничить аутентификацию, чтобы использовать один указанный ключ.

Иногда проблема связана с разрешениями и правами собственности. Например, если вы хотите войти в систему как 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

Тебе не нужен authorized_keysтвой клиент.

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

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

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

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

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

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

Должно было:

sudo chown username:username /home/username;

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

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

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

AllowUsers user1 user2 user3

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

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

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

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

У меня была такая же проблема при копировании открытого ключа обычного пользователя (например, 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в качестве виртуального хоста Document Root по умолчанию для 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 

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

Оригинальный автор разместил его здесь: 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 должен работать сейчас, спрашивая пароль

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

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

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

Проблема в sshd_configфайле

Вот окончательное решение:

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

vi /etc/ssh/sshd_config

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

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

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

PasswordAuthentication yes
service sshd reload

вступить в силу.

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

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

ssh-copy-id john @ serverIPAddress

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

ты должен идти идти

Некоторые люди задаются вопросом, возможно, настроили 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каталога со старой машины. Оказывается, что моя более старая конфигурация SSH использовала ключи DSA, которые с тех пор устарели . Переход на новую пару ключей, на этот раз основанный на RSA, решил проблему для меня.

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

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

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

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

На машине А выполнитьcat ~/.ssh/id_rsa.pub

Образец вывода:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

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

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

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