не працює паролем ssh


35

Я намагався налаштувати ssh b / w без паролів Aна Bі Bдо A. Створено відкритий та приватний ключ, використовуючи ssh-keygen -trsaна обох машинах. Використовував ssh-copy-idутиліт для копіювання Державно-ключів від Aдо B, а також Bдо A.

Безпечний ssh ​​працює від Aдо, Bале notвід Bдо A. Я перевірив дозволи папки ~ / ssh / і, здається, є нормальним.

A's .ssh Дозволи на папки:

-rw-------  1 root root 13530 2011-07-26 23:00 known_hosts
-rw-------  1 root root   403 2011-07-27 00:35 id_rsa.pub
-rw-------  1 root root  1675 2011-07-27 00:35 id_rsa
-rw-------  1 root root   799 2011-07-27 00:37 authorized_keys
drwxrwx--- 70 root root  4096 2011-07-27 00:37 ..
drwx------  2 root root  4096 2011-07-27 00:38 .

B's .ssh Дозволи на папки:

-rw------- 1 root root  884 2011-07-07 13:15 known_hosts
-rw-r--r-- 1 root root  396 2011-07-27 00:15 id_rsa.pub
-rw------- 1 root root 1675 2011-07-27 00:15 id_rsa
-rw------- 1 root root 2545 2011-07-27 00:36 authorized_keys
drwxr-xr-x 8 root root 4096 2011-07-06 19:44 ..
drwx------ 2 root root 4096 2011-07-27 00:15 .

Aє ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 березня 2009) B- це машина debian (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 жовтня 2007)

Від A:

#ssh B

працює чудово.

Від B:

#ssh -vvv A 
...
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f1581f23a50)
debug2: key: /root/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1127
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.122.1's password: 

Що по суті означає, що це не аутентифікація за допомогою файлу /root/id_rsa. Я керував ssh-addкомандою в обох машинах.

Частина аутентифікації /etc/ssh/sshd_configфайлу є

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files

Мені не вистачає ідей. Будь-яка допомога буде вдячна.


Що таке установка PermitRootLoginв /etc/ssh/sshd_configна А?
taneli

@taneli: yesінакше користувачеві не буде запропоновано ввести пароль.
Лекенштейн

У моєму випадку мені довелося прокоментувати "IgnoreUserKknownHosts так" у файлі "/ etc / ssh / sshd_config" в ubuntu 12.04
Мартін Магакіян

Відповіді:


24

Просто переконайтесь, що ви дотримувались наступної процедури:

На машині A

відкрийте термінал і введіть команди наступним чином:

root@aneesh-pc:~# id

Просто для того, щоб переконатися, що ми є коренем.

Якщо вищевказана команда виводить щось на кшталт нижче, ми root ще переходимо на root за допомогою suкоманди

uid=0(root) gid=0(root) groups=0(root)

1) Створіть ключі.

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
49:7d:30:7d:67:db:58:51:42:75:78:9c:06:e1:0c:8d root@aneesh-pc
The key's randomart image is:
+--[ RSA 2048]----+
|          ooo+==B|
|         . E=.o+B|
|        . . .+.*o|
|       . . .  ...|
|        S        |
|                 |
|                 |
|                 |
|                 |
+-----------------+

Я не використовував жодної фрази. Якщо вам потрібен такий, ви можете ним скористатися.

2) Скопіюйте відкритий ключ у .ssh/authorized_keysфайл машини B

root@aneesh-pc:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@mylap
root@mylap's password: 

Тепер спробуйте увійти в машину за допомогою ssh 'root@mylap'та зареєструватися:

~/.ssh/authorized_keys

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

Замініть mylap на ім'я хоста або ip машини, на яку ви хочете увійти (тобто машина B)

3) Увійти в B без пароля

root@aneesh-pc:~# ssh root@mylap
Warning: Permanently added 'mylap,192.168.1.200' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Wed Jul 27 15:23:58 2011 from streaming-desktop.local
aneesh@mylap:~$

На машині B

4) Створіть ключі для повернення до машини A

root@mylap:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
35:9f:e7:81:ed:02:f9:fd:ad:ef:08:c6:4e:19:76:b1 root@streaming-desktop
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|          o   .  |
|         . + + o |
|        S o * E  |
|           = O . |
|            O +  |
|           + o o.|
|            . o+=|
+-----------------+

5) Скопіюйте відкритий ключ у .ssh/authorized_keysфайл файлу А

root@mylap:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
root@aneesh-pc's password: 

Тепер спробуйте увійти в машину за допомогою ssh 'root@aneesh-pc'та зареєструватися:

.ssh/authorized_keys

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

6) Увійти до A без пароля

ssh root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/


Last login: Tue Jul 26 18:52:55 2011 from 192.168.1.116

Якщо ви зможете виконати ці кроки, ви закінчили. Тепер у вас є дві машини з ввімкненим входом у систему ssh-ключ (відкритий ключ).


зробив усі 6 кроків, як зазначено, перевірив усі речі, пов’язані до кроку 5, але якось крок 6 не працює
лютий

Чи можете ви надати висновок цієї команди: 'ssh -v root @ aneesh-pc'. замініть ім’я користувача та ім’я хоста на ваше.
aneeshep

15
виявив винуватця, що дозволи /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. були занадто відкритими. Змінено дозволи drwxr-xr-xта зараз він працює. Не уявляю, що дозвіл батьківського каталогу впливає на ssh.
Лютий

1
@Cuurious Хороший улов, мій домашній каталог 770також встановив, змінив на a, 750і все в порядку зі світом :) Я завжди, здається, забуваю, що Linux-прем'єри можуть працювати в зворотному порядку.
комплістичний

1
Невдача на кроці 3. ssh-copy-id запускається після введення пароля, однак я все ще не можу увійти, не запрошуючи пароль, мій файл із дозволеними ключами містить текст мого .pub, і я пропоную ключ для входу . Безрезультатно. Дозвіл у всіх каталогах правильний.
Метт Кларк

44

Після налаштування ssh без пароля мене все ще запитали пароль користувача. Дивлячись /var/log/auth.logна віддалену машину, ми вказали на проблему:

sshd[4215]: Authentication refused: bad ownership or modes for directory /home/<user>

Отже, переконайтеся, що це правильно:

chmod o-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

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

Також /etc/ssh/ssd_configпереконайтеся, що параметри RSAAuthenticationта PubkeyAuthenticationпараметри не вимкнено. За замовчуванням yesтак, що не повинно бути проблем.


також переконайтесь, що ці перелічені вище папки належать правильному користувачеві
GoalBased

Я потрапив у цю ситуацію, вилучивши погано створений архів драйверів realtek. Він змінив власника в каталозі, в який я його знімав.
Пол Макміллан

2
Ваша домашня папка не може бути доступною для запису, тому що якщо вона була, то я можу просто перейменувати вашу ~/.sshна щось інше, а потім створити нову зі своїм власним ключем.
Кевін Панько

2
приголомшливий! не думав шукати журнали на хост-машині. Спасибі!
користувач3099609

14

Можливо, лише проблема дозволів більш високого рівня. Потрібно видалити дозволи на запис із групи та інших до домашнього каталогу та .ssh каталогу. Щоб виправити ці дозволи, запустіть chmod 755 ~ ~/.sshабо chmod go-w ~ ~/.ssh.

Якщо у вас все ще виникають проблеми, напишіть у своєму журналі наступний текст:

sudo egrep -i 'ssh.*LOCAL_USER_NAME' /var/log/secure

(замініть LOCAL_USER_NAMEсвоїм місцевим іменем користувача ...)

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

DATE HOSTNAME sshd [1317]: Відхилена автентифікація: неправильне володіння або режими для каталогу / шляху / до / деякого / каталогу

Це проблема, описана вище, і вам потрібно знайти відповідний каталог і видалити дозволи на запис з групи та інших.

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

TLDNR : Якщо дозволити запис для групи та / або іншого до вашого домашнього каталогу, вхід в систему запустить пароль.


2

ви використовуєте кореневий рахунок на кожній машині? Зазвичай на Ubuntu ви б користувались обліковим записом користувача та надавали йому привілеї sudo за потребою.

Якщо використання некористуючого користувача sudo chown $USER -R ~/.sshможе вирішити вашу проблему

Інші речі для перевірки:

подвійна перевірка , що B це id_rsa.pubзнаходиться в - х authorized_keys.

чек А /etc/ssh/sshd_configмістить

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes

Так, я включив кореневий обліковий запис на машині Ubuntu, отже, працював як користувач root в обох системах
лютий

Так, я зрозумів, додав ще кілька пропозицій, які ви, можливо, не помітили. Цей результат справді марний, хоча це не так, нічого про те, чому rsa не була прийнята.
Smithamax

1
ти правдива, причина, чому ключ rsa не був прийнятий, є найважливішим елементом тут, я думаю :). sshd_config містить вищезазначені елементи, я відредагував питання про включення вмісту /etc/ssh/sshd_configфайлу
лютий

-3

в / etc / ssh / sshd_config при зміні цілі

PermitRootLogin немає

до

PermitRootLogin так

тоді вбийте -HUP ваш sshd PID:

root @ dzone2 # ps -ef | grep ssh root 28075 27576 0 17 листопада? 6:11 / usr / lib / ssh / sshd

root 17708 20618   0 10:09:30 pts/37      0:00 grep ssh root@dzone2 # kill -HUP 28075 root@dzone2 # ps -ef|grep ssh
root 17861 20618   0 10:09:44 pts/37      0:00 grep ssh
root 17852 27576   0 10:09:42 ?           0:00 /usr/lib/ssh/sshd

1
Це не допоможе. Проблема полягає в тому, що вхід без пароля SSH (автентифікація за допомогою пари ключів RSA) не працює. Наведені вами інструкції стосуються rootроботи входу в SSH. Це абсолютно не пов'язане з тим, про що йдеться у цьому питанні. Крім того, якщо rootобліковий запис увімкнено (це не за замовчуванням в Ubuntu), включення rootвходу в SSH може бути досить небезпечним.
Елія Каган
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.