Не может ssh даже с открытым ключом, добавленным к авторизованному ключу


16

У меня есть капля 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 выход:

введите описание изображения здесь


Опубликуйте подробный журнал соединения, ваш контент sshd_config и возможные ошибки, связанные с ssh, в журнале сервера.
Jakuje

@Jakuje Я добавил вывод ... Я не заметил твой комментарий раньше.
Джефф

Ключ отклонен. Проверьте журнал сервера на возможные проблемы (возможно, с LogLevel DEBUG3in sshd_config). Я подозреваю, что это проблемы с разрешениями, но для этого может быть несколько причин.
Jakuje

Это говорит[date omitted] www sssh[15029]: Connection closed by x.x.x.x port 55519 [preauth]
Джефф

Каковы права доступа для файла authorized_keys? ls -ld ~ ~/.ssh ~/.ssh/authorized_keys? Для подробного журнала с сервера измените файл, упомянутый выше, перезапустите службу ssh, подключитесь снова и auth.log
опубликуйте

Ответы:


20

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

Настроить ~/.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войти в другого пользователя, а затем перейти в root с помощью пароля ( sudo su -).

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

Независимо от того, решите ли вы создать другого пользователя и использовать его в sshкачестве этого пользователя или пользователя root, рекомендуется разместить 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

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


1
Шаг отладки работал для меня. Корневой каталог имел неправильные разрешения (должно быть 700)
naisanza

12

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

~ / .ssh / должен принадлежать владельцу и иметь 700 разрешений. ~ / .ssh / authorized_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, разрешено ли root входить в систему вообще или только с помощью ключей ssh.

Если у вас есть :

PasswordAuthentication no

тогда вы можете установить:

PermitRootLogin yes

А затем перезапустите sshd:

/etc/init.d/sshd restart

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

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

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

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


В дополнение к этому решению, мне также пришлось изменить разрешения для моей домашней папки, чтобы заставить работать SSH:sudo chmod 700 /home/me/
Rg90

Ты спасатель, @ albert-j! IdentityFileЛиния у меня из часовой колеи.
Зев

4

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

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

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

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


Ни один из них не работает: / Я все еще получаюPermission denied (publickey)
Джефф

3

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

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

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


3

Я закончил тем, что переустановил, 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 на ваш сервер.


1

Эта проблема возникла у меня при использовании образа 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решило проблему.

НТН


0

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

AuthorizedKeysFile %h/.ssh/authorized_keys 

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.