Помилка аутентифікації без паролів SSH

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

Примітка: Мій сервер debian.

Нижче - що я зробив.

1. Я створив ключ:

   ssh-keygen -t dsa
   

2. Скопіювали id_dsa.pub на ~ / .ssh віддаленого сервера

3. ssh-add -D для видалення старих ключів. Здається, вони мені не потрібні

4. ssh-add ~ / .ssh / id_dsa, щоб додати приватний id 5.спробував підключитися до зовнішнього сервера як

   ssh root @ remote-ip

5. Я все-таки вирішив отримати пароль навіть після мого прийняття на додавання до відомих хостів.
6. Спробуваний ssh ​​-vvv root @ remote-ip та отримання журналу розміщено нижче.

OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 вересня 2011 року
debug1: зчитування даних конфігурації / etc / ssh / ssh_config
debug1: Застосування параметрів для *
debug2: ssh_connect: needpriv 0
debug1: Підключення до 184.154.191.58 [184.154.191.58] порт 18765.
debug1: З'єднання встановлено.
debug1: файл посвідчення /home/eclipse/.ssh/id_rsa тип -1
debug1: файл посвідчення /home/eclipse/.ssh/id_rsa-cert тип -1
debug1: файл посвідчення /home/eclipse/.ssh/id_dsa тип 2
debug1: Перевірка файлу чорного списку /usr/share/ssh/blacklist.DSA-1024
debug1: Перевірка файлу чорного списку /etc/ssh/blacklist.DSA-1024
debug1: файл посвідчення /home/eclipse/.ssh/id_dsa-cert тип -1
debug1: файл посвідчення /home/eclipse/.ssh/id_ecdsa тип -1
debug1: файл посвідчення /home/eclipse/.ssh/id_ecdsa-cert type -1
debug1: Віддалений протокол версії 2.0, віддалена версія програмного забезпечення OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4 *
debug1: Увімкнення режиму сумісності для протоколу 2.0
debug1: рядок локальної версії SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug2: fd 3 налаштування O_NONBLOCK
debug3: put_host_port: [184.154.191.58]: 18765
debug3: load_hostkeys: завантаження записів для хоста "[184.154.191.58]: 18765" з файлу "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: знайдено ключ типу RSA у файлі /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: завантажено 1 клавішу
debug3: order_hostkeyalgs: віддайте перевагу hostkeyalgs: ssh-rsa-cert-v01 @ openssh.com, ssh-rsa-cert-v00 @ openssh.com, ssh-rsa
debug1: SSH2_MSG_KEXINIT надіслано
debug1: отримано SSH2_MSG_KEXINIT
debug2: kex_parse_kexinit: ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group-exchange-sha256, diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01 @ openssh.com, ssh-rsa-cert-v00 @ openssh.com, ssh-rsa, ecdsa-sha2-nistp256-cert-v01 @ openssh.com, ecdsa-sha2- nistp384-cert-v01 @ openssh.com, ecdsa-sha2-nistp521-cert-v01 @ openssh.com, ssh-dss-cert-v01 @ openssh.com, ssh-dss-cert-v00 @ openssh.com, ecdsa- sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-dss
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aesc, ces, ces lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aesc, ces, ces lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, umac-64 @ openssh.com, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, umac-64 @ openssh.com, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: none, zlib @ openssh.com, zlib
debug2: kex_parse_kexinit: none, zlib @ openssh.com, zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follow 0 
debug2: kex_parse_kexinit: зарезервовано 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa, ssh-dss
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aesc, ces, ces lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, aes192-cbc, aesc, ces, ces lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5, hmac-sha1, hmac-ripemd160, hmac-ripemd160 @ openssh.com, hmac-sha1-96, hmac-md5-96
debug2: kex_parse_kexinit: немає
debug2: kex_parse_kexinit: немає
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follow 0 
debug2: kex_parse_kexinit: зарезервовано 0 
debug2: mac_setup: знайдено hmac-md5
debug1: kex: server-> client aes128-ctr hmac-md5 none
debug2: mac_setup: знайдено hmac-md5
debug1: kex: client-> сервер aes128-ctr hmac-md5 none
debug1: надіслано SSH2_MSG_KEX_DH_GEX_REQUEST (1024-1024-8192)
debug1: очікує SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: набір ключових бітів priv: 125/256
debug2: набір бітів: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT надіслано
debug1: очікує SSH2_MSG_KEX_DH_GEX_REPLY
debug1: ключ хоста сервера: RSA 5d: ce: fb: 75: de: 6f: 52: f9: ad: 41: e3: 92: 9a: 53: ee: f0
debug3: put_host_port: [184.154.191.58]: 18765
debug3: put_host_port: [184.154.191.58]: 18765
debug3: load_hostkeys: завантаження записів для хоста "[184.154.191.58]: 18765" з файлу "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: знайдено ключ типу RSA у файлі /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: завантажено 1 клавішу
debug3: load_hostkeys: завантаження записів для хоста "[184.154.191.58]: 18765" з файлу "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: знайдено ключ типу RSA у файлі /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: завантажено 1 клавішу
debug1: Host '[184.154.191.58]: 18765' відомий і відповідає сумісному ключу RSA.
debug1: знайдено ключ у /home/eclipse/.ssh/known_hosts:3
debug2: набір бітів: 514/1024
debug1: ssh_rsa_verify: підпис правильний
debug2: kex_derive_keys
debug2: set_newkeys: режим 1
debug1: SSH2_MSG_NEWKEYS надіслано
debug1: очікує SSH2_MSG_NEWKEYS
debug2: set_newkeys: режим 0
debug1: отримано SSH2_MSG_NEWKEYS
debug1: Роумінг заборонено сервером
debug1: SSH2_MSG_SERVICE_REQUEST надіслано
debug2: service_accept: ssh-userauth
debug1: отримано SSH2_MSG_SERVICE_ACCEPT
debug2: ключ: /home/eclipse/.ssh/id_rsa ((нуль))
debug2: ключ: /home/eclipse/.ssh/id_dsa (0x21b20e18)
debug2: ключ: /home/eclipse/.ssh/id_ecdsa ((нуль))
debug1: Аутентифікації, які можна продовжувати: пароль, інтерактивна клавіатура
debug3: почати заново, передав інший список списку, інтерактивну клавіатуру
debug3: кращий gssapi-keyex, gssapi-with-mic, publickey, інтерактивна клавіатура, пароль
debug3: authmethod_lookup клавіатура-інтерактивна
debug3: залишився бажаний: пароль
debug3: authmethod_is_enabled клавіатура-інтерактивна
debug1: Наступний метод аутентифікації: інтерактивна клавіатура
debug2: userauth_kbdint
debug2: ми надіслали інтерактивний клавіатурний пакет, чекаємо відповіді
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Пароль: 

Добро, хтось допоможе.

Ви поставите відкритий ключ у неправильне місце. На сервері дозволені ключі зберігаються у файлі ~/.ssh/authorized_keys, по одній клавіші на рядок. Сервер SSH ігнорує всі інші файли в ~/.ssh.

(Ви можете легко авторизувати ключ.)ssh-copy-id <server>

По-друге, ти справді бігав sshd -Dі sshd id_dsa? Команда така ssh-add:

ssh-add -D
ssh-add ~/.ssh/id_dsa

Я витрачав занадто багато часу на налагодження без паролів ssh auth з відкритим ключем протягом багатьох років, тому хотів опублікувати кілька пропозицій для інших, хто зустрічається:

• Як розміщено mgorven, переконайтесь, що дозволи на файли встановлені правильно на віддаленому хості. Це найпоширеніша проблема в моєму досвіді.

    $ chown -R ім'я користувача: ім'я користувача ~ / .ssh
    $ chmod -R 700 ~ / .ssh

• Запуск ssh від клієнта з "-v", "-vv" або "-vvv" дав мені багато результатів, але він ніколи не сказав мені, яка конфігурація неправильна на віддаленій машині. Це, мабуть, не дозволяє злі h4x0rs отримувати занадто багато інформації або щось подібне.

• Якщо у вас є фізичний (не-ssh) доступ до віддаленої машини, ви можете спробувати зупинити службу sshd і запустити sshd вручну за допомогою прапора "-d", щоб вивести інформацію про налагодження на консоль.

• Налаштування авторизації без паролів для root - це головний захист - ні, але якщо ви все-таки хочете це зробити, спробуйте спочатку налаштувати некористувального користувача. Тоді, якщо у вас виникнуть проблеми з включенням цього корінця, ви будете знати, що відповідальність за налаштування root / sysadmin несе.

• Перевірте, чи ввімкнено SELinux. Якщо це так, це може заважати. Особливо, якщо ви намагаєтесь встановити безпечний пароль для облікового запису суперпользователя.

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

OpenSSH дуже аналогічний щодо прав доступу до файлів. Переконайтесь, що /root/.sshі все, що знаходиться в ньому, належить правильному користувачеві, і його читає та записує лише власник.

chown -R root:root /root/.ssh
chmod -R u=rwX,g=,o= /root/.ssh

Якщо це все ще не працює, вставте вміст /var/log/auth.logі, можливо, /var/log/syslogна сервер, намагаючись увійти.

спробуйте

ssh-copy-id [user@]hostname

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

* також перевірте дозволи файлів, як зазначено в інших відповідях.

сподіваюся, що це допомагає