Попытка SSH на удаленном компьютере, но все еще спрашивает пароль

18

Попытка SSH к удаленному компьютеру, но все еще спрашиваю пароль.

У меня есть несколько компьютеров под управлением SElinux, и только один из них затрудняет использование ssh без пароля.

Я сделал ssh-copy-id, и я вижу свой ключ в .ssh / authorized_keys.

У меня chmod 700 .ssh и chmod 600 все файлы в ./ssh/*

Если я сделаю ssh -v, это мой вывод:

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to wcmisdlin05 [10.52.208.224] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/identity type -1
debug1: identity file /home/jsmith/.ssh/id_rsa type 1
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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 'wcmisdlin05' is known and matches the RSA host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:9
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_501' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Next authentication method: publickey
debug1: Offering public key: /home/jsmith/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/jsmith/.ssh/identity
debug1: Trying private key: /home/jsmith/.ssh/id_dsa
debug1: Next authentication method: password

Может кто-нибудь сказать мне, почему это не работает на этом удаленном компьютере?

JMS1969SF
источник
5
Посмотрите в /var/log/secure(если это разрешения) & /var/log/messages(если это SELinux.) В противном случае, это несоответствие между тем, ~/.ssh/authorized_keysчто находится и что отправляется клиентом SSH.
Аарон Копли

Ответы:

17

Я часто сталкивался с подобной ошибкой на машинах CentOS 6 с участием ssh-copy-idSELinux.

Когда ssh-copy-idсоздает файлы авторизованных ключей, он создает его с соответствующими разрешениями, но с неправильной меткой SELinux. Исправление для этого восстанавливает метки к их значениям по умолчанию политики с помощью этой команды:

restorecon -R ~/.ssh

Кенни Рассчарт
источник
1
Хороший ответ. Но для новичка SELinux было бы также интересно узнать, как проверить список и проверить разрешения.
zrajm
14

Эти вещи всегда легче отлаживать со стороны сервера, если это возможно. Если вы можете запустить sshd на другом порту в режиме отладки, он сразу скажет вам, почему ключ отклонен (мое дикое предположение, что ваш домашний каталог доступен для записи группой). Вы можете, например, запустить sshd в режиме отладки на порту 2222 с /usr/sbin/sshd -d -p 2222, а затем соединиться с ssh -p 2222 user@remotehost.

тушеное мясо
источник
4
Большое спасибо за ваши дикие догадки (домашний каталог доступен для записи группой). Это был именно мой случай.
Сергей Куренков
@skwllsp - примите этот ответ, если он правильный для вашего случая.
Охотник на оленей
1
@ Deer Hunter, вопрос был задан другим человеком, а не мной. Я не могу принять этот ответ.
Сергей Куренков
@skwllsp - старший момент от меня, извините.
Охотник на оленей
chmod 744 в мой домашний каталог решил это - это было связано с этим ответом, спасибо!
Брандт Соловий
3

Постер, который ссылался на SElinux, ударил меня по голове: я не хочу использовать selinux, но забыл отключить его, и на сервере была включена selinux при загрузке.

ssh -vОтладка помогла. Ключ принимается:

debug1: Found key in /var/lib/amanda/.ssh/known_hosts:19
debug1: ssh_rsa_verify: signature correct

И тогда я получаю ошибку

debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_502' not found

Мое исправление состояло в том, чтобы выключить selinux setenforce 0и затем отключить его в / etc / selinux. Тогда SSH логин логин работал для меня.

Matt
источник
1

Я испытал это некоторое время назад на RHEL5 (я не знаю, используете ли вы этот дистрибутив), и обнаружил, что это было только тогда, когда я использовал ssh-copy-id. Попробуйте скопировать файл ключа в нужную папку и, разумеется, сбросить разрешения.

GeoSword
источник
0

В моем случае проблема была в неправильном формате authorized_keysфайла.

Там не должно быть не новой строки между определением формата ( ssh-rss, ssh-dss..) и самого открытого ключа.

Helvete
источник
0

У меня раньше были проблемы с ssh и keyfiles. В этом случае id_rsaпомогло переименование моего идентификатора в « ». К сожалению, у меня есть разные ключи для разных серверов. Так что этот подход имеет ограниченную полезность. Это может помочь как разовое.

Во-вторых, сегодня у меня снова есть эта ошибка только в одном сеансе XTerm, и все отлично работает в 6 других сеансах xterm на том же сервере / сервере. Поэтому я сравнил свои результаты envв обеих сессиях. Я обнаружил, что это рабочая сессия, которая отсутствовала на нерабочей сессии:

SSH_AUTH_SOCK=/run/user/1001/keyring/ssh 

Я вставил это назначение в нерабочий сеанс:

export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
ssh  user@host
... Welcome ...

Другими словами, это решение работало на меня.

Я немного проверил SSH_AUTH_SOCKET. Из этого ответа:

путь к файлу сокета unix, который агент использует для связи с другими процессами

Я думаю, что это важно для разрешения ключа на основе результата.

будет
источник
-1

debug1: предложение открытого ключа: /home/jsmith/.ssh/id_ rsa

...

debug1: пробуем закрытый ключ: /home/jsmith/.ssh/id_ dsa

Мне кажется, что закрытый / открытый ключ просто не совпадает. Имена ключей говорят нам, что открытый ключ - это ключ RSA, а закрытый ключ - это DSA.

Попробуйте сгенерировать новую пару и scpоткрытый ключ к серверу.

Gevial
источник
Можно проверить, действительно ли это так, сравнив отпечатки двух клавиш с помощью ssh-keygen -l -f ~/.ssh/id_rsa' and ssh-keygen -l -f ~ / .ssh / id_rsa.pub`. Я не верю, что он даже предложил бы ключи, если бы было несоответствие, как бы то ни было. Я думаю, что это просто, что один отклоняется сервером по еще не определенной причине, поэтому он пытается другой.
тушить
-2

Я рекомендую проверить права доступа к ./ssh и домашнему каталогу пользователя, к файлу ключа и к файлу author_keys, так как никто, кроме владельца, не должен иметь права писать и читать там, если вы хотите, чтобы соединение ssh без пароля работало. Это касается как исходных, так и целевых машин. Если честно, иногда это работает, даже если есть большие права, но это не должно.

Алан
источник
1
Пожалуйста, проверьте: serverfault.com/questions/464411/… . Ваш пост также является излишним, так как вы не прочитали то, что написали другие.
Охотник на оленей