У мене є крапелька Digital Ocean, до якої я намагаюся надати доступ до ssh. Я не впевнений, що з цим було зроблено раніше. Я спробував додати свій відкритий ключ через інтерфейс Digital Ocean. Це не вийшло, я продовжував отримувати permission denied (publickey).

Я отримав доступ до сервера через консоль Digital ocean і вручну додав свій відкритий ключ до /root/.ssh/authorized_keys. Потім я спробував ssh за допомогою ssh root@x.x.x.x. Це не спрацювало (у дозволі відмовлено).

Тому я спробував додати нового користувача, створив /home/me/.sshкаталог з дозволами як 700на сам .sshкаталог, так і 600на authorized_keysфайл. Потім я спробував ssh me@x.x.x.x. Це теж не спрацювало.

Перезапуск демону ssh також нічого не змінює.

Що я пропускаю?

Редагувати:

Ось багатослівний ssh-вихід.

https://gist.github.com/jaesung2061/a37cfd68308414cede8abf7f0137daa9

Редагувати 2:

LogLevel DEBUG3 вихід:

Конфігурація клієнта

Налаштуйте ~/.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, не забудьте додати правильний приватний ключ, який відповідає відкритому ключу, який ви додали до системи.

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

Більшість установок матимуть включену автентифікацію відкритих ключів. Якщо ви почнете робити все недоброзичливо, у вас можуть виникнути деякі проблеми. Там, де ОП є їхньою проблемою, я рекомендую ОП видалити /root/.ssh/каталог для початку.

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

Додайте ключі для хосту за допомогою ssh-copy-id

Незалежно від того, чи вирішили ви створити іншого користувача та використовувати його sshяк кореневого або кореневого користувача, рекомендований спосіб розміщення sshключів на сервері:

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

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

Вимкнути автентифікацію пароля

Зважаючи на це, щойно ви встановили ключ і переконалися, що можете підключитися за допомогою клавіш, рекомендується вимкнути автентифікацію пароля sshdта перезапустити службу:

1. Редагувати /etc/ssh/sshd_config
2. PasswordAuthentication no
3. sudo systemctl restart sshd

Що з новими користувачами?

Якщо ви вимкнете автентифікацію пароля, як ви можете дозволити новим користувачам? Один із способів - додати файли шаблонів до /etc/skelкаталогу. Коли ви ввели одного користувача, зробіть наступне:

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 / Author_keys повинен належати власнику і мати 600 дозволів.

Отже, для root:

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 для цього. Опенш призначений для вирішення цього питання.

Переглядаючи завантажені фрагменти файлу журналу, здається, що ви використовуєте 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, також визначати sh-логін без використання 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

Це може полегшити налагодження, і в командному рядку це завжди має працювати на локальному комп'ютері.

Двічі перевірте конфігурацію демона 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користувач, перед входом у систему потрібно ввімкнути кореневий обліковий запис, створивши для нього пароль sudo passwd rootабо інструмент адміністрування сервера (Ubutntu за замовчуванням вимкнено кореневий обліковий запис) . Ви можете отримати більше інформації на Ubuntu Wiki .

Сподіваюся, це допомагає.

Я закінчив перевстановлення, openssh-serverщо вирішило проблему. Надані рішення - це чудово, але вони не спрацювали для мене. Я поняття не маю, що було причиною проблеми, але я думаю, що попередній розробник, можливо, зіпсувався з конфігурацією та переплутав речі досить погано.

Я сумніваюся, що знайдеться хтось із таким конкретним питанням, як я. Однак якщо у вас є крапелька Digital Ocean, ви не можете отримати доступ до SSH, і жодне із заданих рішень не працює, перевстановіть SSH-сервер, виконавши ці команди через консоль Digital Ocean. Остерігайтеся, що це руйнівний процес, і ви стираєте старі файли конфігурації в/etc/ssh/ (а не у вашому .sshкаталозі).

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

Припустимо, що ваш ssh-клієнт / ключі в порядку, ви повинні мати можливість SSH на свій сервер.

Ця проблема з’явилася для мене за допомогою зображення Debian у Digital Ocean. Якось під час процесу короткого налаштування, ймовірно, коли я встановлював пароль 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 звичайним способом.