Проверьте ssh конфигурацию демона дважды (должен быть в /etc/ssh/sshd_config), и проверка на:

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Также проверяют конфигурационный файл, чтобы видеть, был ли AllowUsers или AllowGroups установлен, поскольку они действуют как белые списки для пользователя и групп соответственно.

кроме того, я заметил, что Вы пытаетесь добавить ключ к пользователю root. Корневым входом в систему по умолчанию должен быть отключен, но можно также изменить это через поле PermitRootLogin.

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

• Сначала проверьте, существует ли файл ~/.ssh/id_rsa на вашем локальном компьютере и является ли он правильным _ (если у вас есть больше).

• Проверьте .ssh разрешения для папки (должно быть drwx------, если не запущено sudo chmod 700 ~/.ssh) и его содержимое (должно быть -rw-------, если не запущено sudo chmod 600 ~/.ssh/* ]) . Примените те же разрешения для удаленного компьютера.

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

• Вы можете запустить что-то вроде следующего:

  ssh -i /path/to/your/private-key root@X.X.X.X

  или

  ssh -i ~/.ssh/id_rsa myRemoteUser@X.X.X.X

Вы можете получить больше информации на ssh manpage (запустите man ssh на своем терминале) .

Также имейте в виду, что если вы хотите войти в систему как root пользователь, ваша учетная запись root должна быть включена до входа в систему, создав для нее passwd с помощью sudo passwd root или инструмента администрирования вашего сервера (Ubutntu имеет root учетная запись отключена по умолчанию) . Вы можете получить больше информации на Ubuntu Wiki .

Надеюсь, это поможет.

Клиентская конфигурация

Настроить ~/.ssh/config

Установка записей хоста для ssh действительно легко и сохранит Вас большая проблема. Вот пример:

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

В этом примере мы устанавливаем digitaloceanbox и github и github.com так, чтобы мы могли сделать следующие команды:

1. ssh github
2. ssh digitaloceanbox

Если мы хотим войти в систему как другой пользователь, чем тот, указанный в файле конфигурации, мы просто помещаем user@ в начале:

• ssh user@digitaloceanbox

Генерация ssh ключи

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

Обратите внимание, что я указал полный путь закрытого ключа, который я хочу генерировать при запросе ssh-keygen. Я также определил комментарий (-C) то, которое позволяет мне легко определять, включает удаленные машины.

Это создаст два файла:

1. .ssh/digitalocean-rsa
   • ЗАКРЫТЫЙ КЛЮЧ. Никогда не совместно используйте это.
2. .ssh/digitalocean-rsa.pub
   • Открытый ключ. Это - то, что Вы храните на сервере для аутентификации.

Когда Вы обеспечиваете Ваш ssh ключ, быть уверенным это .pub версия!! Когда Вы добавляете к Вашему ~/.ssh/config, обязательно добавьте корректный закрытый ключ, который соответствует открытому ключу, который Вы добавили к системе.

Конфигурация сервера

Большинство установок будет идти с включенной Аутентификацией С открытым ключом. Если Вы начинаете делать вещи все волей-неволей, Вы могли бы столкнуться с несколькими проблемами, как бы то ни было. В том, где OP находится в их проблеме, я рекомендую, чтобы OP удалил /root/.ssh/ каталог для запуска.

Не рекомендуется использовать ssh получить доступ к пользователю root в удаленной системе. Рекомендуется что Вы ssh в другого пользователя, и затем возрастают для укоренения с помощью пароля (sudo su -).

Добавьте ключи для хостинга использования ssh-copy-id

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

1. ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox

Это позволяет sshd создать каталог и файлы, необходимые с необходимыми полномочиями. Это означает, что существует нулевой шанс для Вас испортить полномочия или бывший должный помнить детали. Просто используйте инструмент для загрузки ключей.

Отключите аутентификацию по паролю

Однако после того как Вы имеете key'd сами и проверили, что можете соединить использование ключей, рекомендуется отключить Аутентификацию по паролю в sshd и перезапуск сервис:

1. Править /etc/ssh/sshd_config
2. PasswordAuthentication no
3. sudo systemctl restart sshd

Что относительно новых пользователей?

Если Вы отключаете Аутентификацию по паролю, как можно включить новых пользователей? Один путь состоит в том, чтобы добавить шаблонные файлы к /etc/skel каталог. После того как у Вас есть key'd один пользователь, сделайте следующее:

1. sudo cp -r .ssh/ /etc/skel/
2. ls /etc/skel/.ssh
3. Отредактируйте любые файлы, найденные в /etc/skel/.ssh/ так, чтобы они были пробелом, если Вы не хотите автоматически включить себя для каждого недавно созданного пользователя.

Когда Вы создаете новых пользователей с sudo useradd -m newuser, тот пользователь будет иметь .ssh/authorized_keys, который Вы можете отредактировать и будете иметь верные полномочия.

Отладка

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

1. sudo tail -f /var/log/auth.log

При выполнении этой команды используйте другой терминал для попытки входа в систему. Много раз предоставленные сообщения достаточно хороши, чтобы помочь точно определить проблему или найти решение онлайн.

Ssh довольно требователен в отношении владения, файла и полномочий каталога с ssh ключами.

~/.ssh/должны принадлежать владельцу и иметь 700 полномочий. ~/.ssh/authorized_keys должны принадлежать владельцу и иметь 600 полномочий.

Так, для корня:

sudo chown root:root -R /root/.ssh/
sudo chmod 700 /root/.ssh/
sudo chmod 600 /root/.ssh/authorized_keys

Для пользователя меня:

sudo chown me:me -R /home/me/
sudo chmod 700 /home/me/.ssh/
sudo chmod 600 /home/me/.ssh/authorized_keys

И затем попробуйте еще раз.

Конечно, необходимо также зарегистрироваться в/etc/ssh/sshd_config, позволяют ли корню войти в систему вообще, или только с ssh ключами.

Если Вы имеете:

PasswordAuthentication no

затем можно установить:

PermitRootLogin yes

И затем перезапуск sshd:

/etc/init.d/sshd restart

и попробуйте еще раз.

Обратите внимание, что с ssh, sshd демон может быть перезапущен даже когда с помощью ssh сессии для этого. Openssh разработан для контакта с этим.

Смотря на Ваши загруженные отрывки файла журнала, кажется использованием MacOSX? Вы могли создать новый ssh ключ там?

Кроме того, я узнал в прошлом, что, когда у меня есть больше чем один частный ssh, включают мой локальный компьютер для моего пользователя, что это иногда лишает возможности входить в систему удаленно с ssh. Это помогло большой партии сделать записи на локальном компьютере в файле ~/.ssh/config, решить это. Например:

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

После того, как это примеряет командную строку на Вашем локальном компьютере:

ssh -v my-vps

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

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

Это хорошо работает для меня. Также возможно определить который ключ использовать на командной строке:

ssh -v root@10.111.111.254 -i .ssh/id_rsa

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

Эта проблема открылась для меня использующий изображение Debian на Цифровом Океане. Так или иначе во время резюме настроенный процесс, вероятно, когда я установил пароль root, владельца для /root был изменен на пользователя debian. Я видел следующее в /var/log/auth.log:

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

Просто выполнение chown root:root -R /root решенный проблема.

HTH

Просто имел очень похожую проблему. Это работало на меня - Добавляет эта строка к/etc/ssh/sshd_config

AuthorizedKeysFile %h/.ssh/authorized_keys 

Затем перезапустите ssh обычным способом.