Я пытался настроить без пароля с б / ш 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
на А?yes
противном случае пользователю не будет предложено ввести пароль.Ответы:
Просто убедитесь, что вы выполнили следующую процедуру:
На машине А
откройте терминал и введите команды следующим образом:
Просто чтобы убедиться, что мы root.
Если вышеприведенная команда выдает что-то похожее на приведенное ниже, мы являемся пользователем root, иначе переключитесь на root с помощью
su
команды1) Создайте ключи.
Я не использовал парольную фразу. Если вам нужен, вы можете использовать его.
2) Скопируйте открытый ключ в
.ssh/authorized_keys
файл машины BТеперь попробуйте войти в систему с помощью
ssh 'root@mylap'
и проверить:чтобы убедиться, что мы не добавили дополнительные ключи, которые вы не ожидали.
Замените mylap на имя хоста или IP-адрес компьютера, на котором вы хотите войти (например, компьютер B)
3) Войти в B без пароля
На машине B
4) Создайте ключи для входа обратно на компьютер A
5) Скопируйте открытый ключ в
.ssh/authorized_keys
файл машины АТеперь попробуйте войти в систему с помощью
ssh 'root@aneesh-pc'
и проверить:чтобы убедиться, что мы не добавили дополнительные ключи, которые вы не ожидали.
6) Авторизуйтесь без пароля
Если вы можете выполнить эти шаги, вы сделали. Теперь у вас есть две машины с включенным ssh-ключом (открытым ключом).
источник
/root
(770)drwxrwx--- 70 root root 4096 2011-07-27 00:37 ..
был слишком открытым. Поменял разрешенияdrwxr-xr-x
и теперь он работает. Не могу представить тот факт, что разрешение родительского каталога влияет наssh
.770
установлен, изменен на a750
и все в порядке с миром :) Кажется, я всегда забываю, что prem для Linux может работать в обратном порядке.После настройки ssh без пароля у меня все еще спрашивали пароль пользователя. Посмотрев на
/var/log/auth.log
удаленную машину указал на проблему:Итак, убедитесь, что это правильно:
Хотя запретить другим пользователям переписывать вашу
.ssh
папку очевиден, иметь такое же требование для вашей домашней папки было сложнее.Кроме того,
/etc/ssh/ssd_config
убедитесь, чтоRSAAuthentication
иPubkeyAuthentication
параметры не отключены. По умолчанию этоyes
так, что не должно быть проблемой.источник
~/.ssh
во что-то другое, а затем создать новую с моим собственным ключом.Вероятно, просто проблема с разрешениями более высокого уровня. Вам нужно удалить разрешения на запись из группы и других в ваш домашний каталог и каталог .ssh. Чтобы исправить эти разрешения, запустите
chmod 755 ~ ~/.ssh
илиchmod go-w ~ ~/.ssh
.Если у вас все еще есть проблемы, введите в журнал следующую команду grep:
(замените
LOCAL_USER_NAME
своим локальным именем пользователя ...)Надеемся, что это расскажет вам больше о вашей проблеме, если предположить, что информация аутентификации sshd заносится в защищенный журнал, что должно быть по умолчанию. Если вы видите ошибки, которые выглядят так:
Это проблема, описанная выше, и вам нужно найти соответствующий каталог и удалить права на запись для группы и других.
Что касается причины, по которой вам нужно будет ограничить права на запись для вашего домашнего каталога (даже если разрешения уже ограничены для вашего .ssh и последующих каталогов), это позволит другим пользователям переименовать ваш каталог .ssh и создать новый - хотя это было бы непригодным, поскольку (из-за неправильных разрешений) исправление для большинства пользователей, вероятно, будет состоять в том, чтобы изменить разрешения, а не проверять содержимое каталога ...
TLDNR : Разрешение доступа на запись для группы и / или другого к вашему домашнему каталогу заставит ssh принудительно войти в систему с паролем.
источник
Вы используете учетную запись root на каждой машине? Обычно в Ubuntu вы используете учетную запись пользователя и при необходимости предоставляете ей привилегии sudo.
Если вы используете некорневого пользователя, это
sudo chown $USER -R ~/.ssh
может решить вашу проблемуДругие вещи, чтобы проверить:
двойная проверка , что B это
id_rsa.pub
находится в - хauthorized_keys
.проверка
/etc/ssh/sshd_config
содержитисточник
/etc/ssh/sshd_config
файлав / etc / ssh / sshd_config по изменению цели
в
тогда убей -HUP твой sshd PID:
источник
root
работать SSH. Это совершенно не связано с тем, о чем этот вопрос. Кроме того, еслиroot
учетная запись включена (это не по умолчанию в Ubuntu), включениеroot
входа по SSH может быть довольно опасным.