Putty: получение сервера отказалось от нашей ключевой ошибки

86

Я создал пару ключей, используя 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 для файла / каталога и правильное форматирование ключа. Я сделал все это, все еще получая ошибку «отказался от нашего ключа», и у меня нет идей.

ПавелРоман
источник
2
Вы сказали Putty использовать тот же ключ? вы входите в систему с одним и тем же пользователем? это установка SSH по умолчанию, или вы изменили sshd_config?
Ноам Ратхаус
Puttygen генерирует 3 ключа: закрытый, открытый и собственную версию закрытого ключа с расширением .ppk. Я, конечно, использую .ppk с putty.exe и вставляю открытый ключ в .ssh / authorized_keys на сервере. Это установка / конфигурация SSH по умолчанию, я не менял sshd_config.
PawelRoman 01
Кстати, мне пришлось создать каталог .ssh и auhtorized_keys, потому что это свежая установка Ubuntu, а ее там не было. Может это как-то связано с проблемой?
PawelRoman 01
3
Убедитесь, что sshd_config настроен на использование открытых ключей, возможно, это не так
Ноам Ратхаус
2
Вы что-нибудь видите в /var/log/auth.log? увеличьте LogLevel журналов SSH до DEBUGи посмотрите, можете ли вы увидеть какие-либо зарегистрированные проблемы, если он по-прежнему не показывает, что вы получаете доступ, вы просматриваете неправильный файл журнала
Ноам Ратхаус,

Ответы:

61

Хорошо, в моем ключе была небольшая опечатка. Видимо при вставке в файл первая буква была обрезана и начиналась с sh-rsa вместо ssh-rsa.

nrathathaus - ваш ответ был очень полезным, большое спасибо, этот ответ зачислен вам :) Мне понравилось, что вы сказали, и установите это в sshd_conf:

LogLevel DEBUG3

Посмотрев логи, я понял, что sshd правильно читает ключ, но отклоняет его из-за неправильного идентификатора.

ПавелРоман
источник
7
Точно
такая
Какие журналы вы проверяли и где они? О каком идентификаторе вы говорите?
user1046647
3
@ user1046647 LogLevelопределен в /etc/ssh/sshd_config. Журнал по умолчанию, /var/log/auth.logесли иное не определено в sshd_config.
Axel Kemper
3
Если вы откроете authorized_key в vim и сразу попытаетесь вставить первые символы s из ssh_rsa, это будет рассматриваться как команда vim, после чего vim переключится в режим вставки, а оставшийся текст будет вставлен. вставка (например, использование i) ведущей 's' не будет вырезана.
Павел
1
! sudo service ssh restartчтобы изменения вступили в силу. В противном случае в моем лог-файле авторизации ничего не было.
hogan
30

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

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

/etc/ssh/sshd_config

и установите уровень журнала:

LogLevel DEBUG3

Затем попробуйте пройти аутентификацию, а если это не удастся, найдите файл журнала:

/var/log/secure

Там будут ошибки, которые вы ищете.

Рэнти
источник
/var/log/существует, но secureне существует. Как узнать, в какой журнал ведется запись?
aliteralmind 09
11
По умолчанию /var/log/auth.log, по крайней мере, в моем Ubuntu 14.04.1.
Axel Kemper
ДА! Спасибо! Оказывается, у моего ключевого файла pub \ n в конце был невидимый \ n
Алексцил
1
Linux / Ubuntu так разочаровывает. Потратил добрых 20 минут, пытаясь выяснить, почему не было secureфайла, прежде чем читать комментарии @axel здесь.
JYelton 02
17

В моем случае мне также пришлось изменить разрешения для / home / user с 0755 на 0700.

Атиф
источник
1
это было причиной и решением для меня
pstanton
4
и для себя папка 700 и authorized_keys 600 решили проблему
Дэвид
1
Для меня то же самое, chmod 700 в папке .ssh и chmod 600 в authorized_keys решили проблему
Иво Кухарски
Папка .ssh 700 и авторизованные ключи 600 исправили это для меня.
Deep-B
13

В моем случае это проблема с разрешением.

Я изменил уровень журнала на 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к работе. Лучше используйте другого пользователя.

WesternGun
источник
Этот ответ был недооценен. На устранение неполадок из-за пропущенных разрешений домашнего каталога может уйти целый день.
chingNotCHing
Спасибо, что проголосовали за меня. Я просто делюсь тем, что у меня есть.
WesternGun
6

При запуске Windows 8.1 я столкнулся с server refused our keyпроблемой.

Следуя руководству: https://winscp.net/eng/docs/guide_windows_openssh_server Было легко установить соединение, используя логин Windows usernameи password. Однако при аутентификации с помощью usernameв сочетании с a private 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.

После установления соединения сканирование журналов показало:

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/eng/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своими ценностями.

Изменить: добавлен снимок экрана с правами доступа к файлам administrators_authorized_keys: введите описание изображения здесь

Когда OpenSSH SSH Serverработает как служба, только тогда Systemдолжно быть разрешение. Однако при запуске sshd.exeиз командной строки текущий пользователь должен быть единственным в списке (разрешение на чтение, запрет на запись).

Ненависть
источник
3
Вы сделали здесь много полезного. Сначала запускаем sshd с флагом отладки в командной строке. Журналы системы служб Windows показывали очень мало и были совершенно бесполезны для отладки. Во-вторых, основной факт, что у администратора есть ошибка, которая просматривает только файл administrators_authorized_keys, а не ожидаемую папку Users .ssh для authorized_keys (всеобщее горе при запуске sshd в Windows). Наконец, папка ssh в ProgramData! Мне было интересно, куда он помещает сертификаты сервера и т. Д. Так что только ваша информация здесь помогла мне после того, как я почесал голову в течение дня или около того. Благодарность!
Мастер Джеймс
этот ответ был единственным, который сработал для меня на новом уровне бесплатного пользования windows 2019 ec2 instance.
yolob 21,
3

Я добавляю этот ответ, чтобы помочь любому, кто, как и я, часами безуспешно рыскал по Интернету.

ВАША ГЛАВНАЯ ПАПКА МОЖЕТ БЫТЬ ЗАШИФРОВАНА.

Или, если уж на то пошло, любую папку, в которую вложен ваш файл «authorized_keys». Черт, это сэкономило бы мне много времени. Чтобы проверить, пойдите, выполните

ls -A

в каталоге, статус шифрования которого вы хотите определить. Если папка содержит папку с именем «.encryptfs», ответ - да, эта папка зашифрована. Это помешает вам получить доступ к файлу «authorized_keys», содержащему открытый ключ ssh, необходимый для проверки.

Чтобы исправить это, поместите файл «authorized_key» в дерево каталогов, не содержащее шифрования.

Маки Мессер
источник
3

Я нашел простое решение - переместить authorized_keysфайл из скрытого каталога .ssh и поместить его в системный каталог ssh:

/etc/ssh/keys/authorized_keys

Как только я это сделал, все заработало без проблем.

mrbronz
источник
3

имея такую ​​же проблему в Windows Server 2008 R2 и много исследовал, чтобы решить, наконец, сделал это следующим образом:

откройте C: \ Program Files (x86) \ OpenSSH \ etc \ sshd_config с помощью текстовой панели или любого другого текстового редактора

удалите комментарий из следующих строк, после удаления они должны выглядеть следующим образом:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

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

Рави Ананд
источник
ssh иногда устанавливается без комментариев в строке authorizedkeysfile, поэтому он не знает, где искать файл авторизованных ключей :-(
kenyee
Какие разрешения необходимы для файла authorized_keys? И должно ли оно находиться в каталоге пользователя или в каталоге OpenSSH?
GarfieldKlon
Он должен находиться в каталоге OpenSSH или в том месте, где вы установили свой OpenSSH. вы должны найти его
Рави Ананд
Убедитесь, что вы настраиваете его с помощью учетной записи администратора.
Рави Ананд
2

Благодаря nrathaus и /var/log/auth.logисследованиям на уровне отладки происходит следующее.

Другая причина в том, что ваш домашний каталог может иметь разрешения, отличные от 755.

Intel83
источник
Ваш домашний каталог должен быть 700, это значение по умолчанию в CentOS.
karatedog
2

Сегодня я столкнулся с этой проблемой, и моя проблема заключалась в том, что при копировании открытого ключа из файла также включаются символы новой строки. Вы можете использовать ": set list" в vim, чтобы увидеть все скрытые новые строки и не забудьте удалить все новые строки, кроме последней. Кроме того, в моем ключе в начале отсутствовал ssh-rsa. Убедитесь, что у вас есть это.

Hyeuc
источник
1
Похоже здесь: при копировании из PuttyGen у меня появлялись новые строки после «ssh-rsa» и после ключа. После их удаления все заработало.
Lucian P.
1

Для тех, кто получил эту ошибку от Windows Server, я получил ту же ошибку, и это была проблема с учетной записью пользователя. Во многих организациях групповая политика для администраторов может не разрешать настройку сервера SSH и подключений. При таком типе настройки это должно выполняться из учетной записи локального администратора. Возможно, стоит посмотреть, если вы подтвердили, что в открытом ключе нет опечаток.

Эндрю Кэмпбелл
источник
1

В моем случае мне пришлось отключить SELinux на Centos6.6, чтобы он заработал :)

Отредактируйте / etc / selinux / config и установите следующее, а затем перезагрузите хост.

selinux=disabled

Кстати ... забыл упомянуть, что мне пришлось установить LogLevel = DEBUG3, чтобы идентифицировать проблему.

сагая
источник
1
Вместо отключения SELinux вы можете изменить контекст безопасности в папке .ssh. chcon -R -t ssh_home_t .ssh
palehorse
1

У меня была такая же ошибка на solaris, но в /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.

Бруно Рюсс
источник
1

В моем случае это было вызвано ( /etc/ssh/sshd_config):

PermitRootLogin no

Сменил на yes, перезапустил службу и вошел в обычном режиме.

Алекс Фортуна
источник
1

Я решил эту проблему, 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== yourname@hostname

В моем случае я удалил некоторые комментарии, например

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

и добавить 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, это мой первый раз, когда я задаю вопрос, я постараюсь сделать все, спасибо!

ядерный
источник
1
@Ronak Bhatt, Спасибо за ваши усилия, я попытался сделать коды более понятными, для всего этого кода я использовал ctrl + K, но StackOverflow сказал мне, что «ваше ответное обращение содержит коды, используйте правильный формат», и я не знаю, почему он отличается между написанным и отправленным, я не могу отправить свой ответ, что заставляет меня добавлять коды в «код» построчно. Выучу формат уценки, думает.
ядерный
В текущей версии PuttyGen будет отображать открытый ключ в правильном формате для копирования и вставки. Таким образом, больше нет необходимости вручную преобразовывать ключ putty pub в правильный формат.
Эрик Калкокен
1

Боже мой, я целыми днями пытался это исправить. Вот что у меня сработало. Я вернулся в корневую папку следующим образом: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w authorized_keys service ssh restart Итак, я использовал root для ведения журнала через Putty, и это сработало. поэтому попробуйте сделать то же самое с пользователем, которого вы хотите использовать в замазке.

Слава к славе
источник
0

Я использую файл PUTTYgen с psftp, и я столкнулся с этой проблемой на своем Windows Server, когда нам требовалось создать новые ключи для клиента. Private_key_name .PPK , и файл open_ssh.txt должен находиться в том же каталоге , для подключения к работе.

Гейр Борсе
источник
0

В моем случае home на nfs был 777, нужно было 750. Это устранило проблему.

dghadge
источник
0

У меня проблема, когда sshd только читает authorized_keys2.

Копирование или переименование файла устранило проблему для меня.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PS Я использую Putty из Windows и использую PuTTyKeygen для генерации пары ключей.

Чад Лю
источник
0

Я столкнулся с аналогичной проблемой при попытке войти в систему через Mobaxterm. Закрытый ключ был создан с помощью puttygen. В моем случае помогла регенерация ключа.

Prada
источник
0

При использовании Cpanel вы можете проверить, авторизован ли ключ в

Доступ по SSH >> Открытые ключи >> Управление >> Авторизация или деавторизация.

Tomás Cot
источник
0

если вы получите эту ошибку в /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== username@domainname

Сандип Чхабра
источник
0

Что мне подходит, так это то, что:

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

На этот раз у меня это работает. Но я не знаю, почему у него нет информации о моем ключевом файле сразу при запуске экземпляра. Также проверьте эту ссылку https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

Сохаиб Мустафа
источник
0

В моем случае проблема была такой: во время генерации ключей ssh ​​я намеренно изменил каталоги ключей по умолчанию. Поэтому вместо того, чтобы использовать местоположение ~ / .ssh / authorized_keys, которое я выбрал ~/home/user/folder1/.ssh/authorized_keys, чтобы эти изменения работали, я должен был внести те же изменения в новое местоположение в этом файле /etc/ssh/sshd_config. Но пока я не осознал это, я уже пробовал несколько решений, предложенных здесь другими людьми, включая установку разрешения для домашней папки 700и каталога .ssh на 600.

jstMusa
источник
0

Шаги по исправлению корневого монтирования (которые я выполнил, когда изменил разрешение с папкой ec2-user и файлом ключа авторизации) Этот процесс будет похож на отсоединение и присоединение флеш-накопителя

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

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

Шаги по их исправлению

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

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

  • Команда lsblk - список всех доступных монтировок
  • Выберите значение монтирования, которое вы отключаете от проблемного экземпляра.
  • От имени пользователя ec2 запустите «sudo mount / dev / mapper / rootvg-home / mnt» sudo mount /dev/mapper/rootvg-home /mnt
  • Затем смените каталог на / mnt
  • Сделайте все необходимые изменения

Теперь мы исправили наш том с проблемой, с которой столкнулись. В основном это может быть проблема с правами пользователя - Umount / mnt для его размонтирования - Теперь перейдите в консоль, укажите на том, прикрепленный к новому экземпляру, и отсоедините его - После отсоединения прикрепите его к новому тому как / dev / sda1

С учетом сказанного вы сможете успешно войти в систему

Барат Равичандер
источник
0

Исходя из моего опыта, я предлагаю вам создавать ключи из замазки, а не из Linux. Потому что ключ будет старого формата PEM. Во всяком случае, только мое предложение. Я выполнил шаги, указанные ниже, и отлично работал со мной и моей командой.

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

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

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

введите описание изображения здесь

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

введите описание изображения здесь

  1. Выполните эти команды:

    chmod 700 .ssh

    chmod 600 .ssh / authorized_keys

    chown $ USER: $ USER .ssh -R

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

введите описание изображения здесь

введите описание изображения здесь

m.nguyencntt
источник
0

проверьте свой ключ, сегодня это должен быть ключ rsa (id_rsa.pub), а не ключ dss (id_dsa.pub), используйте puttygen 0.70 и выберите RSA по типу ключа для генерации, замените открытый ключ на хосте ~ /. ssh / authorized_keys

Дон Маттео
источник
0

После добавления ключа войдите в систему, как ec2-userесли бы вы использовали машину Amazon Linux.

sachin_ur
источник
0

В моем случае это был неправильный пользователь: групповая атрибуция. Я решил установить правильного пользователя и группу:

sudo chown [user]:[group] -R /home/[user]
Fede
источник