Я создал пару ключей, используя puttygen.exe
(клиент - Windows 8). На сервере (Ubuntu 12.04.3 LTS) я ввел свой открытый ключ ~/.ssh/authorized_keys
. Открытый ключ таков:
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231
Так что это правильно (одна строка, без комментариев, начинается с ssh-rsa и т. Д.)
.ssh
уровень разрешений dir - 700, разрешение файла authorized_keys - 600. И каталог, и файл принадлежат фактическому пользователю, к которому я пытаюсь войти.
Когда я пытаюсь подключиться, я получаю, 'server refused our key'
а сервер запрашивает пароль. Вот и все. /var/log/auth.log
При попытке войти с помощью ключа ничего не происходит .
Я искал везде, и во всех статьях и советах упоминается установка chmod 600 и 700 для файла / каталога и правильное форматирование ключа. Я сделал все это, все еще получая ошибку «отказался от нашего ключа», и у меня нет идей.
DEBUG
и посмотрите, можете ли вы увидеть какие-либо зарегистрированные проблемы, если он по-прежнему не показывает, что вы получаете доступ, вы просматриваете неправильный файл журналаОтветы:
Хорошо, в моем ключе была небольшая опечатка. Видимо при вставке в файл первая буква была обрезана и начиналась с sh-rsa вместо ssh-rsa.
nrathathaus - ваш ответ был очень полезным, большое спасибо, этот ответ зачислен вам :) Мне понравилось, что вы сказали, и установите это в sshd_conf:
Посмотрев логи, я понял, что sshd правильно читает ключ, но отклоняет его из-за неправильного идентификатора.
источник
LogLevel
определен в/etc/ssh/sshd_config
. Журнал по умолчанию,/var/log/auth.log
если иное не определено вsshd_config
.i
) ведущей 's' не будет вырезана.sudo service ssh restart
чтобы изменения вступили в силу. В противном случае в моем лог-файле авторизации ничего не было.Добавление нескольких мыслей, поскольку другие ответы помогли, но не совсем подходят.
Прежде всего, как указано в принятом ответе, отредактируйте
и установите уровень журнала:
Затем попробуйте пройти аутентификацию, а если это не удастся, найдите файл журнала:
Там будут ошибки, которые вы ищете.
источник
/var/log/
существует, ноsecure
не существует. Как узнать, в какой журнал ведется запись?/var/log/auth.log
, по крайней мере, в моем Ubuntu 14.04.1.secure
файла, прежде чем читать комментарии @axel здесь.В моем случае мне также пришлось изменить разрешения для / home / user с 0755 на 0700.
источник
В моем случае это проблема с разрешением.
Я изменил уровень журнала на
DEBUG3
и/var/log/secure
вижу эту строку:Погуглил и нашел этот пост:
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
По сути, он говорит мне:
w
разрешения вашего домашнего каталога пользователя700
в.ssh
реж600
вauthorized_keys
файле.И это работает.
Другое дело, что даже я включил вход с правами root, я не могу приступить
root
к работе. Лучше используйте другого пользователя.источник
При запуске Windows 8.1 я столкнулся с
server refused our key
проблемой.Следуя руководству: https://winscp.net/eng/docs/guide_windows_openssh_server Было легко установить соединение, используя логин Windows
username
иpassword
. Однако при аутентификации с помощьюusername
в сочетании с aprivate key
ответ былserver refused our key
.Чтобы заставить его работать с открытым ключом, нужны были права доступа к файлу:
C:\ProgramData\ssh\administrators_authorized_keys
Это полезная страница: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps
Остановите две службы OpenSSH, затем откройте с
command prompt
помощьюadmin permissions
. Затем запустите:C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd
Примечание: укажите полный путь к exe, иначе
sshd
жалуется. Это создает одноразовый прослушиватель подключения. Уровень-ddd
подробности 3.После установления соединения сканирование журналов показало:
Пришлось создать файл:
C:\ProgramData\ssh\administrators_authorized_keys
и скопировать в негоpublic key
текст, например:ssh-rsa AAAA................MmpfXUCj rsa-key-20190505
а затем сохранить файл. Я сохранил файл какUTF-8
с расширениемBOM
. Не тестировалANSI
.Затем снова запустив одноразовую командную строку, в журналах было показано:
S-1-5-11
это имя, данноеSystem
.Чтобы исправить это
Bad permissions
, щелкнитеadministrators_authorized_keys
файл правой кнопкой мышиSecurity Tab
, перейдите к, нажмитеAdvanced
кнопку и удалите унаследованные разрешения. Затем удалите все,Group or user names:
кроме имени пользователя для входа в Windows, например:YourMachineName\username
разрешения для этогоusername
должны бытьRead Allow
,Write Deny
все остальное не отмечено. Владелец файла также должен бытьYourMachineName\username
Это устранило проблему.
Другие полезные ссылки:
Загрузите OpenSSH-Win32.zip с: https://github.com/PowerShell/Win32-OpenSSH/releases
Пример C # того, как использовать WinSCPnet.dll для подключения к серверу OpenSSH: https://winscp.net/eng/docs/library#csharp
Вот фрагмент кода для подключения с помощью
WinSCPnet.dll
:Замените
SshHostKeyFingerprint
иSshPrivateKeyPath
своими ценностями.Изменить: добавлен снимок экрана с правами доступа к файлам administrators_authorized_keys:
Когда
OpenSSH SSH Server
работает как служба, только тогдаSystem
должно быть разрешение. Однако при запускеsshd.exe
из командной строки текущий пользователь должен быть единственным в списке (разрешение на чтение, запрет на запись).источник
Я добавляю этот ответ, чтобы помочь любому, кто, как и я, часами безуспешно рыскал по Интернету.
ВАША ГЛАВНАЯ ПАПКА МОЖЕТ БЫТЬ ЗАШИФРОВАНА.
Или, если уж на то пошло, любую папку, в которую вложен ваш файл «authorized_keys». Черт, это сэкономило бы мне много времени. Чтобы проверить, пойдите, выполните
в каталоге, статус шифрования которого вы хотите определить. Если папка содержит папку с именем «.encryptfs», ответ - да, эта папка зашифрована. Это помешает вам получить доступ к файлу «authorized_keys», содержащему открытый ключ ssh, необходимый для проверки.
Чтобы исправить это, поместите файл «authorized_key» в дерево каталогов, не содержащее шифрования.
источник
Я нашел простое решение - переместить
authorized_keys
файл из скрытого каталога .ssh и поместить его в системный каталог ssh:Как только я это сделал, все заработало без проблем.
источник
имея такую же проблему в Windows Server 2008 R2 и много исследовал, чтобы решить, наконец, сделал это следующим образом:
откройте C: \ Program Files (x86) \ OpenSSH \ etc \ sshd_config с помощью текстовой панели или любого другого текстового редактора
удалите комментарий из следующих строк, после удаления они должны выглядеть следующим образом:
сохраните его и попробуйте войти с закрытым ключом сейчас. радоваться, веселиться.
источник
Благодаря nrathaus и
/var/log/auth.log
исследованиям на уровне отладки происходит следующее.Другая причина в том, что ваш домашний каталог может иметь разрешения, отличные от 755.
источник
Сегодня я столкнулся с этой проблемой, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются символы новой строки. Вы можете использовать ": set list" в vim, чтобы увидеть все скрытые новые строки и не забудьте удалить все новые строки, кроме последней. Кроме того, в моем ключе в начале отсутствовал ssh-rsa. Убедитесь, что у вас есть это.
источник
Для тех, кто получил эту ошибку от Windows Server, я получил ту же ошибку, и это была проблема с учетной записью пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку сервера SSH и подключений. При таком типе настройки это должно выполняться из учетной записи локального администратора. Возможно, стоит посмотреть, если вы подтвердили, что в открытом ключе нет опечаток.
источник
В моем случае мне пришлось отключить SELinux на Centos6.6, чтобы он заработал :)
Отредактируйте / etc / selinux / config и установите следующее, а затем перезагрузите хост.
Кстати ... забыл упомянуть, что мне пришлось установить LogLevel = DEBUG3, чтобы идентифицировать проблему.
источник
У меня была такая же ошибка на solaris, но в /var/adm/splunk-auth.log я обнаружил следующее:
В / etc / shadow учетная запись была заблокирована:
Удалена часть "* LK *":
и я мог бы использовать ssh как обычно с authorized_keys.
источник
В моем случае это было вызвано (
/etc/ssh/sshd_config
):Сменил на
yes
, перезапустил службу и вошел в обычном режиме.источник
Я решил эту проблему, puttygen - это стороннее программное обеспечение, ssh-ключ, который сгенерирован им, не использовался напрямую, поэтому вы должны внести некоторые изменения. Например, это выглядит так
Я опускаю некоторые алфавиты посередине, заменяю их на *, если нет, StackOverflow сказал мне, что формат кода неправильный, не позволяйте мне публиковать。
это мой ключ ssh, сгенерированный puttygen, вы должны изменить его
В моем случае я удалил некоторые комментарии, например
и добавить
ssh-rsa
в начале, добавитьyourname@hostname
в последний. примечание : не удаляйте==
в последнем, и вы должны изменить «свое имя» и «имя хоста» для себя. В моем случаеuaskh@mycomputer
, ваше имя - это то, что вы хотите войти в свой vps. Когда все это будет сделано, вы можете загрузить общедоступный -ключ к дому uaskh~/.ssh/authorized_keys
кcat public-key >> ~/.ssh/authorized_keys
томуsudo chmod 700 ~/.ssh
sudo chmod 600 ~/.ssh/authorized_keys
времени вы должны изменить / etc / ssh / sshd_config,RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
моя операционная система - CentOS 7, это мой первый раз, когда я задаю вопрос, я постараюсь сделать все, спасибо!источник
Боже мой, я целыми днями пытался это исправить. Вот что у меня сработало. Я вернулся в корневую папку следующим образом: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w authorized_keys service ssh restart Итак, я использовал root для ведения журнала через Putty, и это сработало. поэтому попробуйте сделать то же самое с пользователем, которого вы хотите использовать в замазке.
источник
Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на своем Windows Server, когда нам требовалось создать новые ключи для клиента. Private_key_name .PPK , и файл open_ssh.txt должен находиться в том же каталоге , для подключения к работе.
источник
В моем случае home на nfs был 777, нужно было 750. Это устранило проблему.
источник
У меня проблема, когда sshd только читает
authorized_keys2
.Копирование или переименование файла устранило проблему для меня.
PS Я использую Putty из Windows и использую PuTTyKeygen для генерации пары ключей.
источник
Я столкнулся с аналогичной проблемой при попытке войти в систему через Mobaxterm. Закрытый ключ был создан с помощью puttygen. В моем случае помогла регенерация ключа.
источник
При использовании Cpanel вы можете проверить, авторизован ли ключ в
Доступ по SSH >> Открытые ключи >> Управление >> Авторизация или деавторизация.
источник
если вы получите эту ошибку в
/var/log/secure
это означает, что у вашего ключа есть место, если вы сгенерировали ключ через puttgen при просмотре
.ppk
файла, он будет выглядеть так:и когда вы попытаетесь вставить его, вы получите ошибку при чтении ключа, поэтому попробуйте отредактировать ключ и сделать его одной строкой и попробовать
это должно выглядеть как-то
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname
источник
Что мне подходит, так это то, что:
На этот раз у меня это работает. Но я не знаю, почему у него нет информации о моем ключевом файле сразу при запуске экземпляра. Также проверьте эту ссылку https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm
источник
В моем случае проблема была такой: во время генерации ключей ssh я намеренно изменил каталоги ключей по умолчанию. Поэтому вместо того, чтобы использовать местоположение ~ / .ssh / authorized_keys, которое я выбрал
~/home/user/folder1/.ssh/authorized_keys
, чтобы эти изменения работали, я должен был внести те же изменения в новое местоположение в этом файле/etc/ssh/sshd_config
. Но пока я не осознал это, я уже пробовал несколько решений, предложенных здесь другими людьми, включая установку разрешения для домашней папки700
и каталога .ssh на600
.источник
Шаги по исправлению корневого монтирования (которые я выполнил, когда изменил разрешение с папкой ec2-user и файлом ключа авторизации) Этот процесс будет похож на отсоединение и присоединение флеш-накопителя
Ниже приведены некоторые другие сценарии, с которыми вы можете столкнуться -
Шаги по их исправлению
Теперь после входа в новый ec2 выполните следующие шаги
sudo mount /dev/mapper/rootvg-home /mnt
Теперь мы исправили наш том с проблемой, с которой столкнулись. В основном это может быть проблема с правами пользователя - Umount / mnt для его размонтирования - Теперь перейдите в консоль, укажите на том, прикрепленный к новому экземпляру, и отсоедините его - После отсоединения прикрепите его к новому тому как / dev / sda1
С учетом сказанного вы сможете успешно войти в систему
источник
Исходя из моего опыта, я предлагаю вам создавать ключи из замазки, а не из Linux. Потому что ключ будет старого формата PEM. Во всяком случае, только мое предложение. Я выполнил шаги, указанные ниже, и отлично работал со мной и моей командой.
Создайте пару ключей с помощью PuTTYGen.exe на вашем локальном компьютере (тип: RSA, длина: 2048 бит).
Сохраните закрытый / открытый ключ как файлы " id_rsa.ppk / id_rsa.pub " на вашем локальном компьютере.
Создайте файл «authorized_keys» на своем локальном компьютере, затем введите открытый ключ в « id_rsa.pub » в « authorized_keys ». Помните, что контент должен начинаться с « ssh-rsa » и только одной строкой .
Выполните эти команды:
chmod 700 .ssh
chmod 600 .ssh / authorized_keys
chown $ USER: $ USER .ssh -R
Проверьте настройки подключения, загрузив закрытый ключ « id_rsa.ppk » в профиль PuTTY.exe, затем нажмите «Открыть» (введите кодовую фразу, если есть).
источник
проверьте свой ключ, сегодня это должен быть ключ rsa (id_rsa.pub), а не ключ dss (id_dsa.pub), используйте puttygen 0.70 и выберите RSA по типу ключа для генерации, замените открытый ключ на хосте ~ /. ssh / authorized_keys
источник
После добавления ключа войдите в систему, как
ec2-user
если бы вы использовали машину Amazon Linux.источник
В моем случае это был неправильный пользователь: групповая атрибуция. Я решил установить правильного пользователя и группу:
источник
Другой причиной может быть спецификация UTF-8 в
authorized_keys
файле.источник