Шпаклівка: Сервер відмовився від нашої ключової помилки


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, дозвіл файлу санкціонованих клавіш - 600. І каталог, і файл, що належать фактичному користувачеві, до якого я намагаюся увійти.

Коли я намагаюся підключитися, я отримую, 'server refused our key'і сервер запитує пароль. Це все. Нічого не реєструється /var/log/auth.logпри спробі входу за допомогою ключа.

Я переглядав скрізь, і у всіх статтях та підказках згадується встановлення chmod 600 та 700 для файлу / каталогу та правильне форматування ключа. Я зробив все це, все ще отримуючи помилку "відмовився від нашого ключа", і я втратив ідеї.


2
Ви сказали Путті використовувати той самий ключ? Ви входите з тим самим користувачем? це установка SSH за замовчуванням, чи ви змінили sshd_config?
Noam Rathaus

Puttygen генерує 3 ключі: приватний, відкритий та власну версію приватного ключа з розширенням .ppk. Я, звичайно, використовую .ppk із putty.exe та вставляю відкритий ключ у .ssh / санкціоновані_клавіші на сервері. Це стандартна установка / конфігурація SSH, я не змінював sshd_config.
PawelRoman

До речі, мені довелося створити каталог .ssh та auhtorized_keys, оскільки це свіжа інсталяція Ubuntu, і її там не було. Можливо, це має щось спільне з проблемою?
PawelRoman

3
Переконайтеся, що sshd_config налаштовано на використання відкритих ключів, можливо, це не так
Noam Rathaus

2
Ви бачите щось у /var/log/auth.log? збільшити LogLevel журналів SSH до DEBUGі подивитися, чи не бачите ви зареєстрованих проблем, якщо все одно не відображається доступ, ви шукаєте в неправильному файлі журналу
Noam Rathaus

Відповіді:


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.
Аксель Кемпер

3
Якщо ви відкриєте у vim утверджений_ключ і негайно спробуєте вставити перші символи з "ssh_rsa", це обробляється як команда vim, після чого vim перемикається в режим вставки, а інший текст вставляється. Якщо ви введете режим вставки раніше вставка (наприклад, використання i) провідних
Павел

1
! sudo service ssh restartщоб зміни набули чинності. В іншому випадку в моєму лог-файлі auth не було нічого.
Хоган

30

Додавання кількох думок, як інші відповіді, допомогло, але вони не точно відповідали.

Перш за все, як зазначено у прийнятій відповіді, відредагуйте

/etc/ssh/sshd_config

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

LogLevel DEBUG3

Потім спробуйте виконати автентифікацію, а коли вона не вдасться, знайдіть файл журналу:

/var/log/secure

У ньому будуть помилки, які ви шукаєте.


/var/log/існує, але secureне існує. Як дізнатись, в який журнал пишеться?
aliteralmind

11
За замовчуванням /var/log/auth.log, принаймні в моєму Ubuntu 14.04.1.
Аксель Кемпер

ТАК! Дякую! виявляється, у моєму файлі ключа пабу був невидимий \ n в кінці
alextsil

1
Linux / Ubuntu так розчаровує. Провів добрі 20 хвилин, намагаючись зрозуміти, чому не було secureфайлу, перш ніж читати тут коментарі @axel.
JYelton,

17

У моєму випадку мені довелося також змінити дозволи / home / user з 0755 на 0700.


1
це було причиною та рішенням для мене
пстантон

4
а для мене папка 700 та санкціоновані_клавіші 600 вирішили проблему
Девід Соусан

1
Для мене те саме вирішили проблему chmod 700 у папці .ssh та chmod 600 на авторизованих клавішах
Iwo Kucharski

Папка .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до роботи. Краще використовувати іншого користувача.


Ця відповідь була недостатньо голосованою. Пропущені дозволи домашнього каталогу можуть коштувати вам цілого дня для усунення несправностей.
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 Service System показували дуже мало і були абсолютно марними для налагодження. По-друге, головний факт, що як адміністратор існує помилка, яка виглядає лише у файлі administrators_authorized_keys, а не в очікуваній папці .ssh Users для авторизованих клавіш (загальна точка печалі, що запускається sshd у Windows). Нарешті, папка 'ssh' у ProgramData! Мені було цікаво, куди він ставив сертифікати сервера тощо. Отже, лише ваша інформація тут допомогла мені після того, як я почухав голову протягом дня або близько того. Дякую!
Майстер Джеймс

ця відповідь була єдиною, яка працювала для мене на новому екземплярі ec2 з безкоштовним рівнем Windows 2019.
yolob 21

3

Я додаю цю відповідь, щоб допомогти всім, як я, хто годинами гортав Інтернет без успіху.

ВАША ДОМАШНЯ ПАПКА МОЖЕ БУТИ ЗАШИФРОВАНА.

Або з цього приводу будь-яка папка, в яку вкладений ваш файл "санкціоновані_клавіші". Чоловіче, це заощадило б мені багато часу. Щоб перевірити, йдіть виконувати

ls -A

у каталозі, статус шифрування якого ви хочете визначити. Якщо папка містить папку з іменем ".encryptfs", відповідь так, так, ця папка зашифрована. Це заважатиме Вашій можливості отримати доступ до файлу авторизованих ключів, що містить загальнодоступний ключ ssh, необхідний для перевірки.

Щоб виправити це, помістіть файл "санкціонований_ключ" у дерево каталогів, яке не містить шифрування.


3

Найпростішим рішенням, яке я знайшов, було перенести authorized_keysфайл з прихованого каталогу .ssh і помістити його в системний каталог ssh:

/etc/ssh/keys/authorized_keys

Як тільки я це зробив, це спрацювало без проблем.


3

маючи ту саму проблему в Windows Server 2008 r2 і дослідив багато для вирішення, нарешті зробив це, виконавши такі дії:

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

видалити коментар із наступних рядків, після видалення вони повинні виглядати наступним чином:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

збережіть його та спробуйте увійти за допомогою приватного ключа зараз. весело провести час.


ssh іноді встановлюється з коментованим рядком дозволеного файлу, тому він не знає, де шукати файл авторизованих ключів :-(
kenyee

Які дозволи потрібні для файлу auth_keys? І чи має це бути в каталозі користувача або в каталозі OpenSSH?
GarfieldKlon

Він повинен знаходитися в каталозі OpenSSH або там, де ви встановили OpenSSH. ви зможете його знайти
Раві Ананд

Переконайтеся, що ви налаштовуєте його за допомогою облікового запису адміністратора.
Раві Ананд

2

Завдяки nrathaus та /var/log/auth.logдослідженню на рівні налагодження приходить наступне.

Інша причина полягає в тому, що ваш домашній каталог може мати дозволи, що відрізняються від 755.


Ваш домашній каталог повинен мати 700, що є типовим для CentOS.
karatedog

2

Я зіткнувся з цією проблемою сьогодні, і моя проблема полягала в тому, що при копіюванні відкритого ключа з файлу також включаються нові символи рядка. Ви можете використовувати ": set list" у vim, щоб переглянути всі приховані нові рядки та не забудьте видалити всі нові рядки, крім останнього. Крім того, на початку в моєму ключі не вистачало "ssh-rsa". Переконайтеся, що у вас є і це.


1
Подібне тут: під час копіювання з PuttyGen у мене з’явилися нові рядки після "ssh-rsa" та після ключа. Після їх видалення це спрацювало.
Lucian P.

1

Для тих, хто отримує цю помилку від Windows Server, я отримав цю саму помилку, і це була проблема облікового запису користувача. У багатьох організаціях групова політика для адміністраторів може не дозволяти налаштування SSH-сервера та з’єднань. При такому типі налаштування це потрібно робити з облікового запису Local Admin. Можливо, варто розглянути, якщо ви підтвердили, що у відкритому ключі немає жодної помилки.


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 з санкціонованими клавішами, як зазвичай.


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. коли все це зробили, ви можете завантажити загальнодоступне -key додому uaskh в ~/.ssh/authorized_keysна cat public-key >> ~/.ssh/authorized_keysте sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keysтоді ви повинні змінити / і т.д. / SSH / sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keysмоя операційна система CentOS 7, Це мій перший раз anwser питання, я буду намагатися мої зусилля , щоб зробити, спасибі!


1
@Ronak Bhatt, Дякую за ваші зусилля, я намагався зробити коди чіткішими, для всього цього коду я використовував ctrl + K, але StackOverflow сказав мені, що "ваше звернення до відповіді містить коди, будь ласка, використовуйте правильний формат", і я не знаю, чому це різниться між написаним та поданим, я не можу подати свою відповідь, що призводить до того, що мені доводиться додавати коди в "код" рядок за рядком. Я вивчу формат націнки, думає.
ядерний

У поточній версії PuttyGen покаже відкритий ключ у правильному форматі для копіювання та вставлення. Тому більше немає необхідності вручну перетворювати ключ pub pub у правильний формат.
Ерік Калкокен

1

Боже мій, я цілими днями намагався це виправити. Отже, ось що мені вдалося. Я повернувся до кореневої згини так: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w дозволений_сервіс ssh restart ssh. Отже, я використовував root для реєстрації через Putty, і це спрацювало. тому спробуйте зробити те саме з користувачем, якого ви хочете використовувати в шпаклівці.


0

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


0

У моєму випадку вдома на nfs було 777, потрібно було 750. Це вирішило проблему.


0

У мене ця проблема, звідки sshd лише читає authorized_keys2 .

Копіювання або перейменування файлу вирішило проблему для мене.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PS Я використовую Putty від Windows і використовував PuTTyKeygen для генерації пари ключів.


0

Я зіткнувся з подібною проблемою при спробі входу через Mobaxterm. Приватний ключ був сформований за допомогою puttygen. Регенерація ключа допомогла в моєму випадку.


0

Під час використання Cpanel ви можете перевірити, чи авторизований ключ

Доступ до SSH >> Відкриті ключі >> Керувати >> Авторизувати або скасувати авторизацію.


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
  • вмонтувати том в якусь тимчасову папку
  • перевірив файл у каталозі mount_point / home / ec2-user / .ssh / allowed_keys
    • В ідеалі цей файл повинен мати нашу ключову інформацію, але для мене цей файл був порожнім
  • скопіював старий екземпляр файлу санкціонованих ключів до нещодавно змонтованого тому
  • відключити пристрій
  • повторно приєднати до оригінального екземпляра ec2
  • запустіть його і дайте йому пройти перевірку стану здоров'я

Цього разу це працює для мене. Але я не знаю, чому спочатку в ньому немає інформації про мої ключові файли, коли екземпляр запускався. Перевірте це посилання теж https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInsistanceConnecting.html#TroubleshootingInsistanceConnectingMindTerm


0

У моєму випадку проблема була така, під час генерації ключів ssh я навмисно змінив каталоги ключів за замовчуванням. Отже, замість того, щоб використовувати розташування ~ / .ssh / санкціоновані_ключі, яке я вирішив використовувати ~/home/user/folder1/.ssh/authorized_keys, для роботи цих змін я мав внести ті самі зміни щодо нового розташування у цьому файлі /etc/ssh/sshd_config. Але поки я цього не зрозумів, я вже спробував кілька рішень, запропонованих іншими людьми, включаючи встановлення дозволу домашньої папки 700та каталогу .ssh 600.


0

Кроки для виправлення кореневого монтування (що я виконував, коли змінював дозвіл за допомогою папки ec2-користувача та файлу ключа авторизації) Цей процес буде подібним до від'єднання та підключення накопичувача

Нижче наведено деякі інші сценарії, з якими ви можете зіткнутися -

  1. Ви використовуєте приватний ключ SSH, але відповідний відкритий ключ відсутній у файлі санкціонованих ключів.
  2. У вас немає дозволів для вашого файлу санкціонованих ключів.
  3. У вас немає дозволів на папку .ssh.
  4. Ваш файл санкціонованих ключів або папка .ssh названий неправильно.
  5. Ваш файл санкціонованих ключів або папку .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. Створіть у своєму локальному файлі файл "дозволені_клавіші", а потім введіть відкритий ключ у " id_rsa.pub " на " авторизовані ключі ". Пам'ятайте, вміст повинен починатися з " ssh-rsa " і лише одним рядком .

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

  1. Скористайтеся WinScp (або командою putty), щоб скопіювати "auth__key & id_rsa.pub " з вашого локального пристрою в ваш linux-user-home " /home/$USER/.ssh/ ".

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

  1. Виконайте такі команди:

    chmod 700 .ssh

    chmod 600 .ssh / дозволені_клавіші

    chown $ USER: $ USER .ssh -R

  2. Перевірте налаштування підключення, завантаживши приватний ключ " id_rsa.ppk " у профілі PuTTY.exe, а потім натисніть "Відкрити" (поставте свою парольну фразу, якщо є).

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

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


0

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


0

Після додавання ключа увійдіть так, ec2-userніби використовуєте машину Amazon Linux


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.