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

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

когда 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. Попробуйте скопировать ключевой файл в нужную папку и, конечно же, сбросить разрешения

Проблема может быть вызвана изменением меток SE-Linux, например параметрами: Z или: z для привязки докеров.

Попробуйте запустить эти:

chcon --recursive unconfined_u:object_r:user_home_dir_t:s0 ${HOME}
chcon --recursive unconfined_u:object_r:ssh_home_t:s0 ${HOME}/.ssh

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

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

Раньше у меня были проблемы с ssh и ключевыми файлами. В этом случае я переименовал свой ключ id в "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 и домашнему каталогу пользователя, к ключевому файлу и к файлу authorized_keys, поскольку никому, кроме владельца, не должно быть разрешено писать и читать там, если вы хотите, чтобы соединение ssh работало без пароля. Это касается как исходных, так и целевых машин. Если честно, иногда срабатывает, даже если есть права побольше, но не должно.