У меня есть капля 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
выход:
источник
LogLevel DEBUG3
insshd_config
). Я подозреваю, что это проблемы с разрешениями, но для этого может быть несколько причин.[date omitted] www sssh[15029]: Connection closed by x.x.x.x port 55519 [preauth]
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
? Для подробного журнала с сервера измените файл, упомянутый выше, перезапустите службу ssh, подключитесь снова иauth.log
Ответы:
Конфигурация клиента
Настроить
~/.ssh/config
Настройка записей для хоста
ssh
действительно проста и избавит вас от многих хлопот. Вот пример:В этом примере мы настроили
digitaloceanbox
и такgithub
иgithub.com
так, чтобы мы могли выполнять следующие команды:ssh github
ssh digitaloceanbox
Если мы хотим войти в систему под другим пользователем, чем тот, который указан в файле конфигурации, мы просто
user@
добавим в начало:ssh user@digitaloceanbox
Генерация
ssh
ключейОбратите внимание, что я указал полный путь к закрытому ключу, который я хочу сгенерировать при запросе
ssh-keygen
. Я также определил комментарий (-C
), который позволяет мне легко идентифицировать ключи на удаленных машинах.Это создаст два файла:
.ssh/digitalocean-rsa
.ssh/digitalocean-rsa.pub
Когда вы предоставляете свой
ssh
ключ, убедитесь, что это.pub
версия! Когда вы добавляете в свой~/.ssh/config
, обязательно добавьте правильный закрытый ключ, который соответствует публичному ключу, который вы добавили в систему.Конфигурация сервера
Большинство установок будут поставляться с включенной аутентификацией с открытым ключом. Однако, если вы начнете делать что-то невообразимо, у вас могут возникнуть некоторые проблемы. В тех случаях, когда у OP есть проблема, я рекомендую, чтобы OP удалял
/root/.ssh/
каталог, чтобы начать все сначала.Не рекомендуется использовать
ssh
для доступа пользователя root в удаленной системе. Рекомендуетсяssh
войти в другого пользователя, а затем перейти в root с помощью пароля (sudo su -
).Добавьте ключи к хосту используя
ssh-copy-id
Независимо от того, решите ли вы создать другого пользователя и использовать его в
ssh
качестве этого пользователя или пользователя root, рекомендуется разместитьssh
ключи на сервере следующим образом:ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox
Это позволяет
sshd
создавать каталог и необходимые файлы с необходимыми разрешениями. Это означает, что у вас нет шансов испортить разрешения или необходимость помнить детали. Просто используйте инструмент для загрузки ключей.Отключить аутентификацию по паролю
При этом после того, как вы сами запомнили ключ и убедились, что можете подключиться с помощью ключей, рекомендуется отключить аутентификацию по паролю
sshd
и перезапустить службу:/etc/ssh/sshd_config
PasswordAuthentication no
sudo systemctl restart sshd
А как насчет новых пользователей?
Если вы отключите проверку подлинности по паролю, как вы можете подключить новых пользователей? Одним из способов является добавление файлов шаблонов в
/etc/skel
каталог. После того, как вы указали одного пользователя, сделайте следующее:sudo cp -r .ssh/ /etc/skel/
ls /etc/skel/.ssh
/etc/skel/.ssh/
так, чтобы они были пустыми, если вы не хотите автоматически вводить ключи для каждого вновь созданного пользователя.Когда вы создаете новых пользователей
sudo useradd -m newuser
, у этого пользователя будет тот.ssh/authorized_keys
, который вы можете редактировать, и у вас будут соответствующие разрешения.Отладка
Вы можете посмотреть
sshd
файл журнала, чтобы увидеть, почему соединения не работают или получают отказ:sudo tail -f /var/log/auth.log
Пока вы запускаете эту команду, используйте другой терминал для попытки входа в систему. Часто предоставляемые сообщения достаточно хороши, чтобы помочь определить проблему или найти решение в Интернете.
источник
Ssh довольно требователен к владельцам, файлам и каталогам с помощью ключей ssh.
~ / .ssh / должен принадлежать владельцу и иметь 700 разрешений. ~ / .ssh / authorized_keys должен принадлежать владельцу и иметь 600 разрешений.
Итак, для root:
Для пользователя я:
А потом попробуйте еще раз.
Конечно, вы должны также проверить в / etc / ssh / sshd_config, разрешено ли root входить в систему вообще или только с помощью ключей ssh.
Если у вас есть :
тогда вы можете установить:
А затем перезапустите sshd:
и попробуй еще раз.
Обратите внимание, что с ssh демон sshd может быть перезапущен, даже если для этого используется сессия ssh. OpenShh предназначен для решения этой проблемы.
Глядя на ваши загруженные фрагменты файла журнала, кажется, что вы используете MacOSX? Не могли бы вы создать новый ключ ssh там?
Кроме того, в прошлом я обнаружил, что когда у меня на локальном компьютере более одного закрытого ключа ssh для моего пользователя, это иногда делает невозможным удаленный вход в систему с помощью ssh. Это очень помогло сделать записи на локальном компьютере в файле ~ / .ssh / config, чтобы решить эту проблему. Например :
После этого попробуйте в командной строке на вашем локальном компьютере:
При использовании ключей ssh, а также без ключей ssh для некоторых других входов в систему, вы можете, кроме записей с ключами ssh, также определить имя входа ssh без использования ключа ssh в файле ~ / ssh / config, например:
Это прекрасно работает для меня. Также можно определить, какой ключ использовать в командной строке:
Это может облегчить отладку, и в командной строке это всегда должно работать на локальном компьютере.
источник
sudo chmod 700 /home/me/
IdentityFile
Линия у меня из часовой колеи.Дважды проверьте конфигурацию демона ssh (должна быть включена
/etc/ssh/sshd_config
) и проверьте:Также проверьте файл конфигурации, чтобы увидеть, установлены ли AllowUsers или AllowGroups , так как они действуют как белые списки для пользователя и групп соответственно.
Также я заметил, что вы пытаетесь добавить ключ пользователю root. По умолчанию вход в систему root должен быть отключен, но вы также можете изменить это через поле PermitRootLogin .
источник
Permission denied (publickey)
Судя по ссылкам, которые вы связали, я думаю, что у вас есть проблемы на стороне клиента, когда вы не можете найти файл закрытого ключа .
Сначала проверьте, что файл
~/.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 .Надеюсь, это поможет.
источник
Я закончил тем, что переустановил,
openssh-server
который установил проблему. Все приведенные решения великолепны, но они не работают для меня. Я понятия не имею, что вызвало проблему, но я думаю, что предыдущий разработчик, возможно, испортил конфигурацию и испортил вещи довольно плохо.Я сомневаюсь, что найдется кто-то с такой специфической проблемой, как моя. Однако, если у вас есть дроплет Digital Ocean, вы не можете получить доступ по SSH, и ни одно из данных решений не работает, переустановите сервер SSH, выполнив эти команды через консоль Digital Ocean. Остерегайтесь, это разрушительный процесс, и он удалит старые файлы конфигурации в
/etc/ssh/
(не в вашем.ssh
каталоге).Предполагая, что ваш 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
решило проблему.НТН
источник
Просто была очень похожая проблема. Это сработало для меня - добавьте эту строку в / etc / ssh / sshd_config
Затем перезапустите ssh обычным способом.
источник