Я создал пару ключей, используя 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, разрешение файла author_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
из скрытого каталога .ssh и поместить его в системный каталог ssh:
/etc/ssh/keys/authorized_keys
Как только я это сделал, все заработало без проблем.
Я добавляю этот ответ, чтобы помочь любому, как я, который часами безуспешно рыскал в интернете.
ВАША ДОМАШНЯЯ ПАПКА МОЖЕТ БЫТЬ ЗАПИСАНА.
Или, если на то пошло, любая папка, в которую вложен ваш файл authorized_keys. Чувак, это сэкономило бы мне много времени. Чтобы проверить, иди выполнить
ls -A
в каталоге, статус шифрования которого вы хотите определить. Если папка содержит папку с именем «.encryptfs», ответ - да, эта папка зашифрована. Это помешает вам получить доступ к файлу «author_keys», содержащему открытый ключ ssh, необходимый для проверки.
Чтобы это исправить, поместите файл «author_key» в дерево каталогов, которое не содержит шифрования.
Спасибо!
Спасибо за LogLevel DEBUG3
(в моем случае CentOS 7
журнал находится в /var/log/secure
)
Оказывается, мой режим .ssh/authorized_keys
был 644
, а не 600
, и sshd
чувствовал, что в одиночку это было пустым ходом, что я наконец обнаружил, читая этот файл журнала!
имея ту же проблему в Windows Server 2008 r2 и исследуя многое, чтобы решить, наконец, сделал это следующим образом:
откройте C:\Program Files (x86)\OpenSSH\etc\sshd_config с помощью текстовой панели или любого другого текстового редактора.
удалите комментарий из следующих строк, после удаления они должны выглядеть следующим образом:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
сохраните его и попробуйте войти с закрытым ключом. повеселись.
Благодаря nrathaus и /var/log/auth.log
расследованию на уровне отладки приходит следующее.
Другая причина в том, что ваш домашний каталог может иметь разрешения, отличные от 755.
Я столкнулся с этой проблемой сегодня, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются символы новой строки. Вы можете использовать «: set list» в vim, чтобы увидеть все скрытые новые строки и убедиться, что удалили все новые строки, кроме последней. Кроме того, мой ключ отсутствовал в начале "ssh-rsa". Убедитесь, что у вас это тоже есть.
В моем случае мне пришлось отключить 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 с авторизованным ключами, как обычно.
В моем случае это было вызвано (/etc/ssh/sshd_config
):
PermitRootLogin no
Изменен на yes
, перезапустил службу и вошел нормально.
Для тех, кто получил эту ошибку от Windows Server, я получил эту же ошибку, и это была проблема с учетной записью пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку SSH-сервера и подключений. При таком типе настройки это должно быть сделано из учетной записи локального администратора. Возможно, стоит обратить внимание, если вы подтвердите, что в открытом ключе нет опечаток.
Я решил эту проблему, 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]
в последний . примечание : не удаляйте ==
в последнем, и вы должны изменить «ваше имя» и «имя хоста» для вас, в моем случае это [email protected]
, ваше имя, что вы хотите войти в свой 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, это мой первый вопрос, я попробую усилия, спасибо!
У меня есть проблема, когда sshd читает только из authorized_keys2
.
Копирование или переименование файла решило проблему для меня.
cd ~/.ssh
Sudo cat authorized_keys >> authorized_keys2
Постскриптум Я использую PuTTY из Windows и использовал PuTTyKeygen для генерации пары ключей.
В моем случае дом на NFS был 777, нужно было 750. Это решило проблему.
Я столкнулся с подобной проблемой при попытке войти через Mobaxterm. Закрытый ключ был сгенерирован через puttygen. Восстановление ключа помогло в моем случае.
Шаги по исправлению Root mount (То, что я следовал, когда я изменил разрешение с помощью папки ec2-user и файла ключа авторизации) Этот процесс будет аналогичен отсоединению и подключению флешки
Ниже приведены некоторые другие сценарии, с которыми вы можете столкнуться -
- Вы используете закрытый ключ SSH, но соответствующий открытый ключ отсутствует в файле author_keys.
- У вас нет прав для вашего файла author_keys.
- У вас нет прав для папки .ssh.
- Ваш файл author_keys или папка .ssh названы неправильно.
- Ваш файл author_keys или папка .ssh были удалены.
Шаги, чтобы исправить их
Теперь после входа в новую систему ec2 выполните следующие шаги
Sudo mount /dev/mapper/rootvg-home /mnt
»Теперь мы исправили наш объем с проблемой, с которой мы столкнулись. В основном это может быть проблема с правами пользователя - Umount/mnt для его размонтирования - Теперь перейдите к консоли и укажите том, подключенный к новому экземпляру, и отсоедините его - После отсоединения прикрепите его к ваш новый том как/dev/sda1
С учетом сказанного вы должны быть в состоянии успешно войти в систему
Под управлением Windows 8.1 я столкнулся с проблемой server refused our key
.
Следуя руководству: https://winscp.net/rus/docs/guide_windows_openssh_server Было легко установить соединение с помощью входа в Windows username
и password
. Однако при аутентификации с помощью username
в сочетании с private key
был получен ответ server refused our key
.
Работа с открытым ключом сводилась к разрешениям на файл: 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
C # пример того, как использовать 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
запускается из командной строки, текущий пользователь должен быть единственным в списке (чтение разрешено, запись запрещена).
проверьте ваш ключ, сегодня это должен быть ключ rsa (id_rsa.pub), а не ключ dss (id_dsa.pub), используйте puttygen 0.70 и выберите RSA для типа генерируемого ключа, замените открытый ключ на Host ~ /. SSH/authorized_keys
При использовании Cpanel вы можете проверить, авторизован ли ключ в
Доступ по SSH >> Открытые ключи >> Управление >> Авторизация или деавторизация.
Что работает для меня, так это:
На этот раз это работает для меня. Но я не знаю, почему у него нет информации о моем файле ключей при запуске экземпляра. Проверьте эту ссылку тоже https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/TroubleshoInstancesConnecting.html#TroubleshoInInancesSnectingMindTerm
Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на моем Windows Server, когда нам потребовалось создать новые ключи для клиента. Файл private_key_name . Ppk и файл open_ssh.txt должны находиться в одном каталоге, чтобы соединение работало.
если вы получите эту ошибку в /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]
В моем случае проблема была в следующем: во время генерации ключей ssh я намеренно изменил каталоги ключей по умолчанию. Поэтому вместо использования местоположения ~/.ssh/авторизованного ключа я выбрал ~/home/user/folder1/.ssh/authorized_keys
, чтобы эти изменения работали, я должен был внести те же изменения в новое местоположение в этом файле /etc/ssh/sshd_config
. Но пока я не осознал это, я уже попробовал несколько решений, предложенных здесь другими людьми, включая установку разрешения для домашней папки на 700
и каталога .ssh на 600
.
Исходя из моего опыта, я предлагаю вам генерировать ключи из PuTTY, а не генерировать со стороны Linux. Потому что ключ будет старого формата PEM. Во всяком случае, только мое предложение. Я сделал, как шаги ниже, и работал хорошо со мной и со своей командой.
Создайте пару ключей с PuTTYGen.exe на локальном компьютере (тип: RSA, длина: 2048 бит).
Сохраните закрытый/открытый ключ как файлы " id_rsa.ppk/id_rsa.pub " на вашем локальном компьютере.
Создайте файл "authorized_keys" в вашем локальном компьютере, затем введите открытый ключ в " id_rsa.pub " to " authorized_keys ". Помните, что содержимое должно начинаться с " ssh-rsa " и только одна строка .
Запустите эти команды:
чмод 700 .сш
chmod 600 .ssh/authorized_keys
chown $ USER: $ USER .ssh -R
Проверьте настройки подключения, загрузив закрытый ключ " id_rsa.ppk " в профиле PuTTY.exe, затем нажмите кнопку "Открыть" (введите пароль, если он есть).