Замазка: При получении Сервер отказался от нашего ключа Ошибка

Добавление нескольких мыслей в качестве других ответов помогло, но не совсем точно.

Прежде всего, как указано в принятом ответе, отредактируйте

/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 ~/.sshSudo chmod 600 ~/.ssh/authorized_keys, затем вам нужно изменить/etc/ssh/sshd_config, RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile .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 и файла ключа авторизации) Этот процесс будет аналогичен отсоединению и подключению флешки

Ниже приведены некоторые другие сценарии, с которыми вы можете столкнуться -  

1. Вы используете закрытый ключ SSH, но соответствующий открытый ключ отсутствует в файле author_keys.
2. У вас нет прав для вашего файла author_keys.
3. У вас нет прав для папки .ssh.
4. Ваш файл author_keys или папка .ssh названы неправильно.
5. Ваш файл author_keys или папка .ssh были удалены.

Шаги, чтобы исправить их

• Остановите проблемный экземпляр Ec2 
• Отключить корневой том (/ dev/sda1)
• Создайте экземпляр ec2 или используйте работающий
• Смонтируйте отдельный том (/ dev/sdvf) в новый экземпляр ec2 

Теперь после входа в новую систему ec2 выполните следующие шаги  

• Команда Lsblk - вывести список всех доступных монтировок
• Выберите значение монтирования, которое вы размонтируете из проблемного экземпляра. 
• Как пользователь ec2, запустите «монтирование Sudo/dev/mapper/rootvg-home /mnt договорSudo mount /dev/mapper/rootvg-home /mnt»
• Затем измените каталог на/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 >> Открытые ключи >> Управление >> Авторизация или деавторизация.

Что работает для меня, так это:

• Остановил экземпляр ec2
• отсоединить громкость
• подключить том со старым экземпляром, используя тот же ключ и смог SSH
• смонтировать громкость в какую-нибудь временную папку
• проверил файл в каталоге mount_point/home/ec2-user/.ssh/authorized_keys
  • В идеале, этот файл должен иметь нашу ключевую информацию, но для меня этот файл был пуст
• скопировал старый экземпляр файла author_keys на вновь смонтированный том
• размонтировать устройство
• подключите к исходному экземпляру ec2
• запустите его и дайте ему пройти проверку здоровья

На этот раз это работает для меня. Но я не знаю, почему у него нет информации о моем файле ключей при запуске экземпляра. Проверьте эту ссылку тоже 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. Во всяком случае, только мое предложение. Я сделал, как шаги ниже, и работал хорошо со мной и со своей командой.

1. Создайте пару ключей с PuTTYGen.exe на локальном компьютере (тип: RSA, длина: 2048 бит).

2. Сохраните закрытый/открытый ключ как файлы " id_rsa.ppk/id_rsa.pub " на вашем локальном компьютере.

3. Создайте файл "authorized_keys" в вашем локальном компьютере, затем введите открытый ключ в " id_rsa.pub " to " authorized_keys ". Помните, что содержимое должно начинаться с " ssh-rsa " и только одна строка .

4. Используйте WinScp (или команду PuTTY), чтобы скопировать " authorized_keys & id_rsa.pub " из вашей локальной системы в вашу linux-user-home " /home/$USER/.ssh/ ".

5. Запустите эти команды:

   чмод 700 .сш

   chmod 600 .ssh/authorized_keys

   chown $ USER: $ USER .ssh -R

6. Проверьте настройки подключения, загрузив закрытый ключ " id_rsa.ppk " в профиле PuTTY.exe, затем нажмите кнопку "Открыть" (введите пароль, если он есть).