Освещаю, не отсвечивая))
Рубрики
Свежие записи
SSH, server refused our key. (Решено).
Писал заметочку о CentOS на VPS дошёл до ssh авторизации по ключу. и нормально так встрял аж на две недели)), забегая вперёд скажу, что ошибка была наивная и от того досадной)), но было интересно!
Ну-с, начнём по-порядку расписывать картину моего позора))
рассматриваем то, что есть. Оставляем то, что нужно.
в секции Port пишем нестандартный порт (отобьёт немалую часть срача в логи на предмет неудачной авторизации армии ботов))
5 настройка iptables
не заб и ываем отметить изменение порта (я так пару раз переустанавливал системы)).
6 PubKeyAuthentication yes
явно указываем аутентификацию по ключу.
7 PasswordAuthentication yes
это отключаем в последнюю очередь
9 user — server refused our key
и вот на этом я встрял — ситуация такова: рут с ключами заходит — пользователь (группа wheel) по ключам не заходит, только по паролю.
Что я только не делал, все рецептики предлагаемые в рунете были вычитаны, осмыслены, применены и нифига)) рут — всё ок, юзер — болт.
Я потерял покой и сон.
Далее пара моментов, которые не помогли в решении, но показались интересными
отключаем поддержку ipv6
11 Очень занятная опция Match
Проблема была в преднастроенном профиле PuTTY. Профиль для рута был настроен верно, с правильными путями к секурному ключу. А вот профиль пользователя был настроен с путями к старому ключу, не соответствующего паре публичного ключа на сервере)) вот такой я тормаз!
UPD — настройка PuTTY для нормального отображения псевдографики в консоли
Terminal > Keyboard > «The Function keys and keypad» = linux
Window > Translation > Character set — выставляем правильную кодировку
Connection > Data > «Terminal-type string» пишем linux
Putty: получение сервера отказано в нашей ключевой ошибке
Я создал пару ключей, используя puttygen.exe (клиент-windows 8). На сервере (Ubuntu 12.04.3 LTS) я поместил свой открытый ключ в
так что это правильно (одна строка, без комментариев, начинается с ssh-rsa и т. д.)
.ssh уровень разрешений dir составляет 700, разрешение файла authorized_keys-600. И каталог, и файл принадлежат фактическому пользователю, который я пытаюсь войти в систему.
когда я пытаюсь подключиться, я получаю ‘server refused our key’ и сервер запрашивает пароль. Вот и все. Ничего не регистрируется в /var/log/auth.log при попытке войти в систему с ключом.
Я искал везде, и все статьи и советы упоминают настройку chmod 600 и 700 для файла/каталога и правильное форматирование ключа. Я сделал все это, все еще получая ошибку «отказался от нашего ключа», и у меня закончились идеи.
23 ответов
хорошо, в моем ключе была небольшая опечатка. По-видимому, при вставке в файл первая буква была отрезана, и она началась с sh-rsa вместо ssh-rsa.
nrathathaus-ваш ответ был очень полезен, большое спасибо, этот ответ приписывают вам 🙂 я сделал, как вы сказали, и установить это в sshd_conf:
глядя на журналы, я понял, что sshd читает ключ правильно, но отклоняет его из-за неправильного идентификатора.
добавление нескольких мыслей, поскольку другие ответы помогли,но не были точными.
прежде всего, как указано в принятом ответе, edit
и установите уровень журнала:
затем попробуйте аутентифицировать, и когда это не удается, найдите файл журнала:
у него будут ошибки, которые вы ищете.
в моем случае мне пришлось изменить разрешения /home / user с 0755 до 0700.
Я добавляю этот ответ, чтобы помочь любому, как я, кто потратил часы, прочесывая Интернет без успеха.
ВАША ДОМАШНЯЯ ПАПКА МОЖЕТ БЫТЬ ЗАШИФРОВАНА.
или, если на то пошло, любая папка, в которую вложен ваш файл «authorized_keys». Блин, это сэкономило бы мне кучу времени. Чтобы проверить, go perform
в каталоге, статус шифрования которого вы хотите определить. Если папка содержит папку с именем «.encryptfs», ответ-да, эта папка зашифрована. Это затруднит доступ к файлу «authorized_keys», содержащему открытый ssh-ключ, необходимый для проверки.
чтобы исправить это, поместите файл» authorized_key » в дерево каталогов, которое не содержит шифрования.
Как только я это сделал, он работал без проблем.
имея ту же проблему в windows server 2008 r2 и исследовал много, чтобы решить, наконец, сделал это, следуя:
открыть C:\Program файлы (x86)\OpenSSH\etc\sshd_config с textpad или любым другим текстовым редактором
снимите комментарий со следующей строки, после удаления они должны выглядеть следующим образом:
сохраните его и попробуйте войти в систему с закрытым ключом теперь. повеселись.
в моем случае это проблема с разрешением.
я изменил уровень журнала DEBUG3 и /var/log/secure Я вижу эту строку:
Googled и я нашел этот пост:
в основном, он говорит мне:
другое дело, что даже я включил root login, я не могу получить root на работу. Лучше использовать другого пользователя.
благодаря nrathaus и /var/log/auth.log расследование на уровне отладки происходит следующее.
еще одна причина заключается в том, что ваш домашний каталог может иметь разрешения, отличные от 755.
спасибо!
спасибо LogLevel DEBUG3 (в моем случае CentOS 7 лог в /var/log/secure )
в моем случае мне пришлось отключить SELinux на Centos6.6, чтобы заставить его работать:)
Edit/etc/selinux / config и установите следующее, а затем перезагрузите хост.
кстати. забыл упомянуть, что мне пришлось установить LogLevel=DEBUG3, чтобы определить проблему.
у меня была такая же ошибка на solaris, но найдена в /var/adm / splunk-auth.входить следующее:
в /etc / shadow учетная запись была заблокирована:
и я мог бы использовать SSH с authorized_keys как обычно.
В моем случае это было вызвано ( /etc/ssh/sshd_config ):
Я столкнулся с этой проблемой сегодня, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются новые символы строки. Вы можете использовать «: set list » в vim, чтобы увидеть все скрытые новые строки и удалить все новые строки, кроме последней. Кроме того, мой ключ отсутствовал «ssh-rsa» в начале. Убедитесь, что у вас есть и это.
для тех, кто получает эту ошибку от Windows Server, я получил эту же ошибку, и это была проблема учетной записи пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку SSH-сервера и соединений. При таком типе настройки это должно быть сделано из локальной учетной записи администратора. Возможно, стоит изучить, если вы подтвердили, что в открытом ключе нет опечаток.
Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на моем сервере Windows, когда нам потребовалось создать новые ключи для клиента. The private_key_name.ppk файл и open_ssh.txt-файл должен находиться в одном каталоге для подключения к работе.
в моем случае дом на nfs был 777, должен был быть 750. Это исправило проблему.
я решил эту проблему, puttygen-это стороннее программное обеспечение, ssh-ключ, который генерируется им, не используется напрямую, поэтому вы должны внести некоторые изменения. Например, это выглядит так
я опускаю некоторые из алфавитов в середине, замененный*, если нет, StackOverflow сказал мне, что формат кода неправильно, не позволяйте мне опубликовать。
это мой ssh-ключ, сгенерированный puttygen, вы должны изменить на это
в моем случае, у меня удалены некоторые комментарии, такие как
/.ssh/authorized_keys by cat public-key >>
/.ssh/authorized_keys затем sudo chmod 700
/.ssh sudo chmod 600
копирование или переименование файла исправили проблему для меня.
P. S. Я с помощью Putty из Windows и использовать PuTTyKeygen для генерации пары ключей.
Я столкнулся с аналогичной проблемой при попытке входа в систему через Mobaxterm. Закрытый ключ был сгенерирован через puttygen. Регенерация ключа помогла в моем случае.
при использовании Cpanel вы можете проверить, авторизован ли ключ в
SSH-доступ > > открытые ключи > > управление > > авторизация или Деавторизация.
если вы получите эту ошибку в /var/log/secure
ошибка: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwx04nfg+rKz93l7em1BsUBzjHPMsswD
и когда вы попытаетесь вставить его, вы получите ошибку при чтении ключа, поэтому попробуйте отредактировать ключ и сделать его одной строкой и попробуйте
это должно выглядеть как-то
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname
что работает для меня, так это:
Putty: Getting Server refused our key Error
I created key pair using puttygen.exe (client is windows 8). On server (Ubuntu 12.04.3 LTS), I have put my public key in
So it’s correct (one line, no comments, starts with ssh-rsa, etc.)
.ssh dir permission level is 700, authorized_keys file permission is 600. Both directory and file owned by the actual user that I try to log in.
When I try connecting I’m getting ‘server refused our key’ and server asks for password. That’s all. Nothing is logged to /var/log/auth.log when attempting to log in with the key.
I’ve looked everywhere and all articles and tips mention setting chmod 600 and 700 for the file/directory and formatting the key correctly. I’ve done all this still getting ‘refused our key’ error and I’m out of ideas.
31 Answers 31
OK, there was a small typo in my key. Apparently when pasting to file the first letter was cut off and it started with sh-rsa instead of ssh-rsa.
By looking at the logs I realized that sshd reads the key correctly but rejects it because of the incorrect identifier.
Adding a few thoughts as other answers helped, but were not exact fit.
First of all, as mentioned in accepted answer, edit
Then try to authenticate, and when it fails, look for log file:
It will have errors you are looking for.
In my case I had to change the permissions of /home/user from 0755 to 0700 as well.
In my case, is a permission problem.
Googled and I found this post:
Basically, it tells me to:
Another thing is that even I enabled root login, I cannot get root to work. Better use another user.
Running Windows 8.1 I ran into the server refused our key problem.
Getting it to work with a public key came down to the permissions on the file: C:\ProgramData\ssh\administrators_authorized_keys
After making a connection, scanning the logs revealed:
Then running the one-time command line again, in the logs showed:
This fixed the problem.
Other Useful links:
C# example of how to use the WinSCPnet.dll to make a connection to the OpenSSH server: https://winscp.net/eng/docs/library#csharp
Here is the code snippet to make a connection using the WinSCPnet.dll :
Replace SshHostKeyFingerprint and SshPrivateKeyPath with your own values.
Edit: added screenshot of administrators_authorized_keys file permissions: 
Как настроить SSH сертификаты входа на Ubuntu
Настройка входа на сервер используя SSH сертификаты, является отличным способом повышения безопасности сервера (перебор паролей SSH станет бесполезным). А использование пароля для приватного сертификата снизит риск взлома ключей (при копировании сертификата входа).
В инструкции рассматриваются вопросы создания и настройки SSH сертификатов на сервере Ubuntu 18 и клиентском приложении — PuTTY.
Содержание
Подготовка папок
Выполняем подготовку папок и файла ключа на сервере.
Важный момент при настройке авторизации SSH по ключам — это указать правильные Права доступа на папку и файл ключа.
Предварительная настройка сервера
Разрешим вход с использованием публичного сертификата SHH на сервер и укажем путь до сертификата в настройках SSH, файл sshd_config.
Раскомментируйте или добавьте значения:
Настройка SSH сертификатов на сервере
Выполним генерацию ключей SSH.
Укажем путь хранения ключа и его имя
💡 В моем случае при создании сертификата для root оказалось важным указать жесткий путь /root/.ssh/, вместо относительного
/.ssh/ чтобы избежать ошибки SSH Server refused our key.
Система так же создаст публичный ключ по данному пути.
Указываем ключевую фразу для доступа к приватному ключу.
Добавляем содержимое файла публичного ключа к файлу сертификата авторизации SSH.
Настройка подключения PuTTY
Преобразуем приватный ключ в формат ключа PuTTY
💡 При попытке использовать скопированный ключ, PuTTY покажет ошибку: Unable to use key file (OpenSSH SSH-2 private key (new format)).
Настройка подключения PuTTY с использованием SSH сертификата
Добавьте приватный сертификат в подключение:
Connection > SSH > Auth > Private key file for authentication
При успешном подключении после ввода имени пользователя, выйдет запрос ключевой фразы сертификата, после чего вход на сервер должен быть успешно выполнен.
Успешный вход на сервер с SSH сертификатами
💡 Если при входе на сервер вы получаете сообщение SSH Server refused our key, проверьте правильность прав на папку .ssh и файл authorized_keys, а так же что вы входите под тем именем пользователя, в authorized_keys которого добавлен ваш ключ.
Финальная настройка сервера
Последний шаг настройки SSH — отключение возможности входа на сервер по паролю, в файле конфигурации.
Раскомментируйте или добавьте значениe:
После чего перезапустите службу SSH.
Настройка авторизации по сертификату SSH — завершена!
Putty: Получение сервера отказалось от нашей ключевой ошибки
Итак, это правильно (одна строка, без комментариев, начинается с ssh-rsa и т.д.)
.ssh Уровень разрешения для dir равен 700, разрешение файла authorized_keys равно 600. Оба каталога и файла принадлежат фактическому пользователю, с которым я пытаюсь войти.
Я смотрел повсюду, и все статьи и советы упоминают установку chmod 600 и 700 для файла/каталога и правильное форматирование ключа. Я сделал все это, все еще получая ошибку «отказался от нашего ключа», и у меня нет идей.
ОТВЕТЫ
Ответ 1
ОК, в моем ключе была небольшая опечатка. По-видимому, при вставке в файл первая буква была отключена, и она начиналась с sh-rsa вместо ssh-rsa.
Изучая журналы, я понял, что sshd правильно считывает ключ, но отклоняет его из-за неправильного идентификатора.
Ответ 2
Добавление нескольких мыслей, как помогли другие ответы, но они не были точно подходящими.
Прежде всего, как упоминалось в принятом ответе, отредактируйте
и установите уровень журнала:
Затем попробуйте выполнить проверку подлинности, и когда он не работает, найдите файл журнала:
У него будут ошибки, которые вы ищете.
Ответ 3
В моем случае мне пришлось изменить разрешения /home/user с 0755 по 0700.
Ответ 4
В моем случае это проблема с разрешением.
Погуглил и нашел этот пост:
В основном, это говорит мне:
Ответ 5
Я добавляю этот ответ, чтобы помочь кому угодно, как и я, который часами прочесывал интернет без успеха.
ВАША ПАМЯТЬ ДОМА МОЖЕТ БЫТЬ ЗАВЕРШЕНА.
Или, в любом случае, любая папка, в которой находится ваш файл authorized_keys. Человек, это спасло бы меня много времени. Чтобы проверить, перейдите выполнить
в каталоге, состояние которого вы хотите определить. Если папка содержит папку с именем «.encryptfs», ответ будет да, эта папка зашифрована. Это затруднит доступ к файлу «authorized_keys», содержащему открытый ключ ssh, необходимый для проверки.
Чтобы исправить это, поместите файл «authorized_key» в дерево каталогов, которое не содержит шифрования.
Ответ 6
Как только я это сделал, это сработало без проблем.
Ответ 7
с той же проблемой в Windows Server 2008 r2 и много исследовал, чтобы решить, в конце концов, выполнив следующее:
открыть C:\Program Files (x86)\OpenSSH\etc\sshd_config с текстовой панелью или любым другим текстовым редактором
удалить комментарий из следующих строк, после удаления они должны выглядеть следующим образом:
сохраните его и попробуйте войти в систему с помощью закрытого ключа. получайте удовольствие.
Ответ 8
Спасибо!
Спасибо за LogLevel DEBUG3 (в моем случае, CentOS 7 журнал находится в /var/log/secure )
Ответ 9
Благодаря nrathaus и /var/log/auth.log расследование на уровне отладки происходит следующим образом.
Другая причина заключается в том, что ваш домашний каталог может иметь разрешения, отличные от 755.
Ответ 10
Я столкнулся с этой проблемой сегодня, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются символы новой строки. Вы можете использовать «: set list» в vim, чтобы увидеть все скрытые новые строки и убедиться, что удалили все новые строки, кроме последней. Кроме того, в моем ключе в начале отсутствовал «ssh-rsa». Убедитесь, что у вас это тоже есть.
Ответ 11
Под управлением Windows 8.1 я столкнулся с server refused our key проблемы.
Работа с открытым ключом C:\ProgramData\ssh\administrators_authorized_keys к разрешениям для файла: C:\ProgramData\ssh\administrators_authorized_keys
После установления соединения сканирование логов выявило:
Затем снова запустив одноразовую командную строку, в логах показывало:
Это решило проблему.
Другие полезные ссылки:
Пример использования С# WinSCPnet.dll для подключения к серверу OpenSSH: https://winscp.net/rus/docs/library#csharp
Вот фрагмент кода для подключения с помощью WinSCPnet.dll :
Замените SshHostKeyFingerprint и SshPrivateKeyPath своими собственными значениями.
Редактировать: добавлен скриншот прав доступа к файлам administrator_authorized_keys: 
Ответ 12
Для тех, кто получает эту ошибку от Windows Server, я получил эту же ошибку, и это была проблема с учетной записью пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку SSH-сервера и соединений. При таком типе настройки это должно быть сделано из учетной записи Local Admin. Возможно, стоит заглянуть, если вы подтвердили, что в публичном ключе нет опечаток.
Ответ 13
В моем случае мне пришлось отключить SELinux на Centos6.6, чтобы заставить его работать:)
Измените/etc/selinux/config и установите следующее, а затем перезагрузите хост.
Кстати. забыл упомянуть, что мне пришлось установить LogLevel = DEBUG3, чтобы определить проблему.
Ответ 14
В/etc/shadow учетная запись была заблокирована:
и я мог бы использовать ssh с authorized_keys как обычно.
Ответ 15
В моем случае это было вызвано ( /etc/ssh/sshd_config ):
Ответ 16
Я опускаю некоторые из алфавитов в середине, заменяя на *, если нет, StackOverflow сказал мне, что формат кода неверен, не позволяйте мне публиковать сообщения.
это мой ssh-ключ, сгенерированный puttygen, вы должны изменить на это
В моем случае я удалил некоторые комментарии, например
/.ssh/authorized_keys на cat public-key >>
/.ssh sudo chmod 600
Ответ 17
Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на моем Windows Server, когда нам нужно было создавать новые ключи для клиента. Файл private_key_name.ppk и файл open_ssh.txt должны находиться в том же каталоге для подключения к работе.
Ответ 18
В моем случае домой на nfs было 777, необходимо было 750. Это исправило проблему.
Ответ 19
Копирование или переименование файла исправило проблему для меня.
P.S. Я использую Putty из Windows и использовал PuTTyKeygen для генерации пары ключей.
Ответ 20
Я столкнулся с подобной проблемой при попытке войти через Mobaxterm. Закрытый ключ был сгенерирован через puttygen. Восстановление ключа помогло в моем случае.
Ответ 21
При использовании Cpanel вы можете проверить, авторизован ли ключ в
Доступ по SSH >> Открытые ключи >> Управление >> Авторизация или деавторизация.
Ответ 22
если вы получите эту ошибку в /var/log/secure
ошибка: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD
и когда вы попытаетесь вставить его, вы получите ошибку при чтении ключа, поэтому попробуйте отредактировать ключ и сделать его одной строкой, и попробуйте
это должно выглядеть как-то
Ответ 23
Что работает для меня, так это:
На этот раз это работает для меня. Но я не знаю, почему у него нет информации о моем файле ключей при запуске экземпляра. Проверьте эту ссылку тоже https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubilityInstancesConnecting.html#TroubilityInInstancesConnectingMindTerm
Ответ 24
В моем случае проблема была в следующем: во время генерации ключей ssh я намеренно изменил каталоги ключей по умолчанию. Поэтому вместо того, чтобы использовать местоположение
/.ssh/authorized_keys, я решил использовать
Ответ 25
Шаги по исправлению Root mount (То, что я следовал, когда я изменил разрешение с папкой ec2-user и файлом ключа авторизации) Этот процесс будет аналогичен отсоединению и подключению флешки
Ниже приведены некоторые другие сценарии, с которыми вы можете столкнуться:
Шаги, чтобы исправить их
Теперь после входа в новый ec2 запустите следующие шаги
При этом вы должны успешно войти в систему
Ответ 26
Исходя из моего опыта, я предлагаю вам генерировать ключи из putty, а не из linux. Потому что ключ будет старого формата PEM. Во всяком случае, только мое предложение. Я сделал, как шаги ниже, и работал хорошо со мной и со своей командой.
Создайте пару ключей с PuTTYGen.exe на локальном компьютере (тип: RSA, длина: 2048 бит).
Сохраните закрытый/открытый ключ как файлы » id_rsa.ppk/id_rsa.pub » на вашем локальном компьютере.
Запустите эти команды:
Проверьте настройки подключения, загрузив закрытый ключ » id_rsa.ppk » в профиле PuTTY.exe, затем нажмите кнопку «Открыть» (введите пароль, если он есть).
Ответ 27
проверьте ваш ключ, сегодня это должен быть ключ rsa (id_rsa.pub), а не ключ dss (id_dsa.pub), используйте puttygen 0.70 и выберите RSA для типа генерируемого ключа, замените открытый ключ на хосте
