Я создал пару ключей, используя puttygen.exe (клиент - это окно 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 для файла/каталога и правильное форматирование ключа. Я сделал все это, все еще получая ошибку "отказался от нашего ключа", и у меня нет идей.
ОК, в моем ключе была небольшая опечатка. По-видимому, при вставке в файл первая буква была отключена, и она начиналась с sh-rsa вместо ssh-rsa.
nrathathaus - ваш ответ был очень полезен, спасибо, этот ответ зачислен к вам:) Мне понравилось, что вы сказали, и установите это в sshd_conf:
LogLevel DEBUG3
Изучая журналы, я понял, что sshd правильно считывает ключ, но отклоняет его из-за неправильного идентификатора.
Добавление нескольких мыслей, как помогли другие ответы, но они не были точно подходящими.
Прежде всего, как упоминалось в принятом ответе, отредактируйте
/etc/ssh/sshd_config
и установите уровень журнала:
LogLevel DEBUG3
Затем попробуйте выполнить проверку подлинности, и когда он не работает, найдите файл журнала:
/var/log/secure
У него будут ошибки, которые вы ищете.
В моем случае мне пришлось изменить разрешения /home/user с 0755 по 0700.
В моем случае это проблема с разрешением.
Я изменил уровень журнала на DEBUG3, и в /var/log/secure я вижу эту строку:
Authentication refused: bad ownership or modes for directory
Погуглил и нашел этот пост:
https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/
chmod g-w /home/your_user chmod 700 /home/your_user/.ssh chmod 600 /home/your_user/.ssh/authorized_keys
В основном, это говорит мне:
w вашего пользователя700 из .ssh реж600 из authorized_keys файла.И это работает.
Другое дело, что даже если я включил root, я не могу заставить работать root. Лучше использовать другого пользователя.
Я добавляю этот ответ, чтобы помочь кому угодно, как и я, который часами прочесывал интернет без успеха.
ВАША ПАМЯТЬ ДОМА МОЖЕТ БЫТЬ ЗАВЕРШЕНА.
Или, в любом случае, любая папка, в которой находится ваш файл authorized_keys. Человек, это спасло бы меня много времени. Чтобы проверить, перейдите выполнить
ls -A
в каталоге, состояние которого вы хотите определить. Если папка содержит папку с именем ".encryptfs", ответ будет да, эта папка зашифрована. Это затруднит доступ к файлу "authorized_keys", содержащему открытый ключ ssh, необходимый для проверки.
Чтобы исправить это, поместите файл "authorized_key" в дерево каталогов, которое не содержит шифрования.
Простым решением, которое я нашел, было перемещение файла authorized_keys из скрытого каталога .ssh и поместить его в системный каталог ssh:
/etc/ssh/keys/authorized_keys
Как только я это сделал, это сработало без проблем.
с той же проблемой в Windows Server 2008 r2 и много исследовал, чтобы решить, в конце концов, выполнив следующее:
открыть C:\Program Files (x86)\OpenSSH\etc\sshd_config с текстовой панелью или любым другим текстовым редактором
удалить комментарий из следующих строк, после удаления они должны выглядеть следующим образом:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
сохраните его и попробуйте войти в систему с помощью закрытого ключа. получайте удовольствие.
Спасибо!
Спасибо за LogLevel DEBUG3 (в моем случае, CentOS 7 журнал находится в /var/log/secure)
Оказалось, что мой режим .ssh/authorized_keys был 644 а не 600, и sshd почувствовал, что в одиночку это было пустым, что я наконец обнаружил, читая этот файл журнала!
Благодаря nrathaus и /var/log/auth.log расследование на уровне отладки происходит следующим образом.
Другая причина заключается в том, что ваш домашний каталог может иметь разрешения, отличные от 755.
Я столкнулся с этой проблемой сегодня, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются символы новой строки. Вы можете использовать ": set list" в vim, чтобы увидеть все скрытые новые строки и убедиться, что удалили все новые строки, кроме последней. Кроме того, в моем ключе в начале отсутствовал "ssh-rsa". Убедитесь, что у вас это тоже есть.
Под управлением Windows 8.1 я столкнулся с server refused our key проблемы.
Следуйте инструкциям: https://winscp.net/rus/docs/guide_windows_openssh_server Было легко установить соединение, используя username и password входа в Windows. Однако при аутентификации с использованием username в сочетании с private key ответом server refused our key был server refused our key.
Работа с открытым ключом C:\ProgramData\ssh\administrators_authorized_keys к разрешениям для файла: C:\ProgramData\ssh\administrators_authorized_keys
Это полезная страница: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubility-Steps
Остановите две службы OpenSSH, затем откройте command prompt с admin permissions. Затем запустите: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd
Примечание: укажите полный путь к файлу exe, иначе sshd жалуется. Это создает одноразовый приемник соединения. -ddd - подробный уровень 3.
После установления соединения сканирование логов выявило:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
No such file or directory
Пришлось создать файл: C:\ProgramData\ssh\administrators_authorized_keys и скопировать в него текст public key, например: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 А затем сохраните файл. Я сохранил файл как UTF-8 с BOM. Не тестировал ANSI.
Затем снова запустив одноразовую командную строку, в логах показывало:
debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
Authentication refused.
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.
Пример использования С# WinSCPnet.dll для подключения к серверу OpenSSH: https://winscp.net/rus/docs/library#csharp
Вот фрагмент кода для подключения с помощью WinSCPnet.dll:
static void WinSCPTest() {
SessionOptions ops = new SessionOptions {
Protocol = Protocol.Sftp,
PortNumber = 22,
HostName = "192.168.1.188",
UserName = "user123",
//Password = "Password1",
SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
};
ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";
using (Session session = new Session()) {
session.Open(ops);
MessageBox.Show("success");
}
}
Замените SshHostKeyFingerprint и SshPrivateKeyPath своими собственными значениями.
Редактировать: добавлен скриншот прав доступа к файлам administrator_authorized_keys: 
Когда OpenSSH SSH Server работает как Сервис, разрешение должно иметь только System. Однако, если запустить sshd.exe из командной строки, текущий пользователь должен быть единственным в списке (чтение разрешено, запись запрещена).
Для тех, кто получает эту ошибку от Windows Server, я получил эту же ошибку, и это была проблема с учетной записью пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку SSH-сервера и соединений. При таком типе настройки это должно быть сделано из учетной записи Local Admin. Возможно, стоит заглянуть, если вы подтвердили, что в публичном ключе нет опечаток.
В моем случае мне пришлось отключить SELinux на Centos6.6, чтобы заставить его работать:)
Измените/etc/selinux/config и установите следующее, а затем перезагрузите хост.
selinux=disabled
Кстати... забыл упомянуть, что мне пришлось установить LogLevel = DEBUG3, чтобы определить проблему.
У меня была такая же ошибка на солярии, но найдена в /var/adm/splunk -auth.log:
sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
В/etc/shadow учетная запись была заблокирована:
weblogic:*LK*UP:16447::::::3
Удалена часть "* LK *":
weblogic:UP:16447::::::3
и я мог бы использовать ssh с authorized_keys как обычно.
В моем случае это было вызвано (/etc/ssh/sshd_config):
PermitRootLogin no
Изменено на yes, перезапустили службу и вошли нормально.
Я решил эту проблему, puttygen - это стороннее программное обеспечение, ssh-ключ, который сгенерирован им, не использовался напрямую, поэтому вы должны внести некоторые изменения. Например, это выглядит так:
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ----
Я опускаю некоторые из алфавитов в середине, заменяя на *, если нет, StackOverflow сказал мне, что формат кода неверен, не позволяйте мне публиковать сообщения.
это мой ssh-ключ, сгенерированный puttygen, вы должны изменить на это
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== [email protected]
В моем случае я удалил некоторые комментарии, например
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----
и добавьте ssh-rsa в начале,
добавьте [email protected] в последнюю очередь.
note: не удалять == в последний раз, и вы должны изменить для себя "имя" и "имя хоста". В моем случае это [email protected], ваше имя - это то, что вы хотите войти в свой vps.если все это сделано, вы можете загрузить общедоступный ключ в uaskh home ~/.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, это мой первый вопрос для андерсера, я постараюсь сделать все, спасибо!
Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на моем Windows Server, когда нам нужно было создавать новые ключи для клиента. Файл private_key_name.ppk и файл open_ssh.txt должны находиться в том же каталоге для подключения к работе.
В моем случае домой на nfs было 777, необходимо было 750. Это исправило проблему.
У меня есть эта проблема, где sshd только читает из authorized_keys2.
Копирование или переименование файла исправило проблему для меня.
cd ~/.ssh
sudo cat authorized_keys >> authorized_keys2
P.S. Я использую Putty из Windows и использовал PuTTyKeygen для генерации пары ключей.
Я столкнулся с подобной проблемой при попытке войти через Mobaxterm. Закрытый ключ был сгенерирован через puttygen. Восстановление ключа помогло в моем случае.
При использовании Cpanel вы можете проверить, авторизован ли ключ в
Доступ по SSH >> Открытые ключи >> Управление >> Авторизация или деавторизация.
если вы получите эту ошибку в /var/log/secure
ошибка: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD
это означает, что у вашего ключа есть пробел, если вы сгенерировали ключ через puttgen при просмотре .ppk файла, он будет выглядеть так:
AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==
и когда вы попытаетесь вставить его, вы получите ошибку при чтении ключа, поэтому попробуйте отредактировать ключ и сделать его одной строкой, и попробуйте
это должно выглядеть как-то
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== [email protected]
Что работает для меня, так это:
На этот раз это работает для меня. Но я не знаю, почему у него нет информации о моем файле ключей при запуске экземпляра. Проверьте эту ссылку тоже https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubilityInstancesConnecting.html#TroubilityInInstancesConnectingMindTerm
В моем случае проблема была в следующем: во время генерации ключей ssh я намеренно изменил каталоги ключей по умолчанию. Поэтому вместо того, чтобы использовать местоположение ~/.ssh/authorized_keys, я решил использовать ~/home/user/folder1/.ssh/authorized_keys, чтобы эти изменения работали, я должен был сделать те же самые изменения относительно нового местоположения в этом файле /etc/ssh/sshd_config. Но пока я не осознал этого, я уже попробовал несколько решений, предложенных другими людьми, в том числе установив разрешение для домашней папки 700 и для каталога.ssh 600.
Шаги по исправлению Root mount (То, что я следовал, когда я изменил разрешение с папкой ec2-user и файлом ключа авторизации) Этот процесс будет аналогичен отсоединению и подключению флешки
Ниже приведены некоторые другие сценарии, с которыми вы можете столкнуться:
- Вы используете закрытый ключ SSH, но соответствующий открытый ключ отсутствует в файле author_keys.
- У вас нет прав для вашего файла author_keys.
- У вас нет прав для папки .ssh.
- Ваш файл author_keys или папка .ssh названы неправильно.
- Ваш файл author_keys или папка .ssh были удалены.
Шаги, чтобы исправить их
Теперь после входа в новый ec2 запустите следующие шаги
sudo mount/dev/mapper/rootvg-home/mntТеперь мы исправили наш объем с проблемой, с которой мы столкнулись. В основном это может быть проблема с правами пользователя - Размонтируйте /mnt для его размонтирования - Теперь перейдите в консоль и укажите том, подключенный к новому экземпляру, и отсоедините его - После отсоединения прикрепите его к новому тому как /dev/sda1
При этом вы должны успешно войти в систему
Исходя из моего опыта, я предлагаю вам генерировать ключи из putty, а не из linux. Потому что ключ будет старого формата PEM. Во всяком случае, только мое предложение. Я сделал, как шаги ниже, и работал хорошо со мной и со своей командой.
Создайте пару ключей с PuTTYGen.exe на локальном компьютере (тип: RSA, длина: 2048 бит).
Сохраните закрытый/открытый ключ как файлы " id_rsa.ppk/id_rsa.pub " на вашем локальном компьютере.
Создайте файл "authorized_keys" на вашем локальном компьютере, а затем введите открытый ключ в " id_rsa.pub " для " authorized_keys ". Помните, что содержимое должно начинаться с " ssh -R sa " и только одной строки.
Запустите эти команды:
чмод 700.сш
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.