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

Попытка 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

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

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

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

restorecon -R ~/.ssh

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

Постер, который ссылался на 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 логин логин работал для меня.

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

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

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

У меня раньше были проблемы с 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. Из этого ответа:

• Как SSH_AUTH_SOCK настраивается и используется ssh-agent?

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

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

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

...

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

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

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

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