SSH без пароля не работает

35

Я пытался настроить без пароля с б / ш 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

У меня заканчиваются идеи. Любая помощь будет оценена.

Cuurious
источник
Что такое установка PermitRootLoginв /etc/ssh/sshd_configна А?
Танели
@taneli: в yesпротивном случае пользователю не будет предложено ввести пароль.
Лекенштейн
В моем случае мне пришлось раскомментировать «IgnoreUserKnownHosts yes» в файле «/ etc / ssh / sshd_config» в Ubuntu 12.04
Мартин Магакян,

Ответы:

24

Просто убедитесь, что вы выполнили следующую процедуру:

На машине А

откройте терминал и введите команды следующим образом:

root@aneesh-pc:~# id

Просто чтобы убедиться, что мы root.

Если вышеприведенная команда выдает что-то похожее на приведенное ниже, мы являемся пользователем 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) Авторизуйтесь без пароля

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-ключом (открытым ключом).

aneeshep
источник
сделал все 6 шагов, как указано, проверил все вещи, связанные до шага 5, но почему-то шаг 6 не работает
Cuurious
Можете ли вы предоставить вывод этой команды: 'ssh -v root @ aneesh-pc'. замените имя пользователя и имя хоста на ваше.
Aneeshep
15
выяснил, что виновник разрешения /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. был слишком открытым. Поменял разрешения drwxr-xr-xи теперь он работает. Не могу представить тот факт, что разрешение родительского каталога влияет на ssh.
Cuurious
1
@Cuurious Хороший улов, мой домашний каталог также был 770установлен, изменен на a 750и все в порядке с миром :) Кажется, я всегда забываю, что prem для Linux может работать в обратном порядке.
Жестко
1
Ошибка на шаге 3. ssh-copy-id запускается после того, как я ввожу пароль, однако я все еще не могу войти в систему без запроса пароля, мой файл authorized_keys содержит текст моего .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
здорово! не думал о том, чтобы посмотреть в журналах на хост-машине. Благодарность!
user3099609
14

Вероятно, просто проблема с разрешениями более высокого уровня. Вам нужно удалить разрешения на запись из группы и других в ваш домашний каталог и каталог .ssh. Чтобы исправить эти разрешения, запустите chmod 755 ~ ~/.sshили chmod go-w ~ ~/.ssh.

Если у вас все еще есть проблемы, введите в журнал следующую команду grep:

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

(замените LOCAL_USER_NAMEсвоим локальным именем пользователя ...)

Надеемся, что это расскажет вам больше о вашей проблеме, если предположить, что информация аутентификации sshd заносится в защищенный журнал, что должно быть по умолчанию. Если вы видите ошибки, которые выглядят так:

DATE HOSTNAME sshd [1317]: аутентификация отклонена: неправильное владение или режимы для каталога / path / to / some / directory

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

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

TLDNR : Разрешение доступа на запись для группы и / или другого к вашему домашнему каталогу заставит ssh принудительно войти в систему с паролем.

KTBiz
источник
2

Вы используете учетную запись root на каждой машине? Обычно в Ubuntu вы используете учетную запись пользователя и при необходимости предоставляете ей привилегии sudo.

Если вы используете некорневого пользователя, это sudo chown $USER -R ~/.sshможет решить вашу проблему

Другие вещи, чтобы проверить:

двойная проверка , что B это id_rsa.pubнаходится в - х authorized_keys.

проверка /etc/ssh/sshd_configсодержит

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
Smithamax
источник
Да, я включил корневую учетную запись на компьютере с Ubuntu, поэтому в обеих системах
она
Да, я понял, добавил несколько других предложений, которые вы, возможно, не заметили. Этот вывод действительно бесполезен, хотя и не о том, почему rsa не была принята.
Smithamax
1
Вы правы, причина того, почему ключ rsa не был принят, является важным элементом здесь, я думаю :). sshd_config содержит вышеупомянутые элементы, я отредактировал вопрос, чтобы включить содержимое содержимого /etc/ssh/sshd_configфайла
Cuurious
-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 может быть довольно опасным.
Элия ​​Каган