Сервер OpenSSH відмовляється приймати аутентифікацію ключа


13

Я спробував використовувати автентифікацію відкритих ключів на своєму новому сервері, і я зіткнувся з цією проблемою.

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

і тоді я повинен ввести свій пароль, щоб увійти.

Але якщо у мене вже є один сеанс, підключений до цього сервера (який підключений паролем), то для наступного з'єднання використовується ключ авторизації, щоб уникнути введення пароля.

Якщо з'єднання SSH вже не встановлено, я не можу підключитися без пароля введення.

Це дійсно дивно для мене, я перевірив MD5 /usr/sbin/sshdміж новим сервером та іншим нормальним сервером, це те саме. Потім я просто скопіював /etc/ssh/sshd_configз іншого звичайного сервера на новий сервер і побіг service ssh restart. Проблема все ще існує.

Як я повинен це виправити?

Відповіді:


10

Переконайтеся, що вашу .sshпапку та файли, що знаходяться всередині неї на клієнтській машині, читає тільки власник ( chmod -R 600 .ssh) та чи власник правильно відповідає папці та файлам ( chownпри необхідності використовуйте команду).

Також перевірте authorized_keysпапку та файл на сервері (можливо, у /root/.sshдомашній папці користувача, який намагається увійти), щоб переконатися, що їх дозволи та власник встановлені однаково.


Редагувати: виходячи з додаткових відгуків (і деяких здогадок!) - чи можете ви перевірити, /etc/ssh/sshd_configчи встановлено наступний параметр, як показано нижче. Якщо ні, спробуйте її відредагувати.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Зауважте, це передбачає, що ви не входите віддалено в систему як корінь


мій .ssh - 700, а файлів у .ssh - 600, і я двічі перевірив ~ / .ssh / санкціоновані_кеї на віддаленій машині. Налаштування автентичності відкритого ключа - це перше, що я роблю після встановлення системи, тому інша операція, швидше за все, не зіпсується. btw, проблема все ж ..
lxyu

Гаразд - я додаю щось до своєї відповіді на основі цього.
Linker3000

є рядок "#AuthorizedKeysFile% h / .ssh / санкціонований_кейс". Я спробував прокоментувати це, але без користі .. btw, той же '/ usr / sbin / sshd' з тим же 'sshd_config', як вони поводяться по-різному?
lxyu

Нарешті я перевстановив ubuntu, потім за одну хвилину я встановив openssh-сервер і він працює нормально ... Досі не знаю, що не так. :(
lxyu

Іноді дійсно важко з’ясувати, в чому проблема. Я одного разу вводив в оману авторизовані ключі як авторизовані_ ключі. Щоб вирішити це, мені знадобилося близько години. Ви бачили неправильну помилку? Це справді хитро! :-)
напів

4

Я виправив власний випадок цієї помилки, видаливши id_rsa.pubз .ssh.

Я скопіював id_rsaз іншої машини і розповсюдив її на декілька клієнтів-манекенів. Тому id_rsaі id_rsa.pubнасправді були різні клавіші, які id_rsaвзагалі заважали використовувати .

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


3

З мого висновку, найменший дозвіл директора будинку цілі 750. Якщо біт у світі немає 0, він не спрацює.

Напр. для каталогу root:

drwxr-x--- 3 root root 4096 Jul 20 11:57 root

Далі є /root/.ssh

drwx------  2 root root  4096 Jul 17 03:28 .ssh

Потім /root/.ssh/authorized_keys

-rw------- 1 root root 1179 Jul 17 03:28 authorized_keys

3

У моєму випадку дозволи на домашній каталог були 775замість 0755або нижчі.

Весь шлях до файла дозволеного_кейса, тобто /home/user/.ssh/повинен бути 0755або меншим.


ДЯКУЙТЕ Вам Це щойно прочитав головний біль у мене вже тиждень. Більшість людей згадують лише папку .ssh (700) та санкціоновані_кейси (600)
Джонатан Комар

2

Після багато проблем, я отримав рішення проблеми:

Домашня директорія користувача не повинна мати дозволу 777або для запису у всьому світі. У такому випадку перевірка ключа SSH не вдасться, і вам доведеться ввести пароль для входу.


1

Просто переконайтеся, що обліковий запис, на який ви намагаєтеся ssh, - це користувач із паролем на віддаленому сервері. Я просто стукнув головою об стіну півгодини, перш ніж знайти тут цю відповідь: /programming//a/14421105/758174


1

Якщо ваш /etc/ssh/sshd_configнаступний рядок не коментований, то ваша конфігурація SSH дозволяє лише фіксованому списку користувачів ssh в систему, і вам потрібно додати до списку будь-які нові облікові записи:

AllowUsers root user1 user2 user3

Будь-які інші користувачі, ніж перелічені вище, намагаються увійти через SSH, отримуватимуть такі криптові повідомлення про помилки:

Roaming not allowed by server

0

Я з’ясував, що після зміни свого імені користувача та групи (але не ідентифікаторів) у /etc/passwdта /etc/group, але забувши змінити /etc/shadowвідповідно, я отримав те саме повідомлення «Не дозволено роумінгу».

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