Ключ ssh принят хостом, но клиент отключился

Привет,

У меня проблема с SSH после установки Fedora 23.

Когда я не хочу подключаться к удаленному хосту с закрытым ключом, мой хост находит ключ:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Но, как вы видите, мой клиент отключился сам

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

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

Есть ли у вас какие-либо идеи ?

/ и т.д. / SSH / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Спасибо

Изменить: я могу подключиться с паролем

ssh private-key

Прежде всего, существует множество хорошо написанных и подробных документов по как установить или настроить аутентификацию на основе открытого ключа доступны в Интернете. Взгляните на один из них и убедитесь, что вы все правильно выполнили. Вот является одним. Так что я не собираюсь повторять это снова.

Самая основная концепция (скопирована из Вот):

При аутентификации на основе ключей используются два ключа: один «открытый» ключ, который может видеть любой, и другой «закрытый» ключ, который может видеть только владелец. Для безопасного взаимодействия с использованием аутентификации на основе ключей необходимо создать пару ключей, надежно сохранить закрытый ключ на компьютере, с которого нужно войти в систему, и сохранить открытый ключ на компьютере, на котором необходимо войти.

Теперь из опубликованного вами журнала отладки:

Кажется, задействованы два разных пользователя. /home/theo/.ssh/authorized_keys и /home/tbouge/.ssh/id_rsa. Вы пытаетесь войти как один пользователь в домашний каталог другого пользователя?
Ошибка Postponed publickey for theo.. означает, что нежелательный метод аутентификации был испробован до метода открытого ключа. SSH будет проверять все методы аутентификации, включенные в конфигурации, один за другим. В вашем случае у вас есть GSSAPIAuthentication yes включил то, что вы не используете. Вы можете безопасно отключить его, выполнив GSSAPIAuthentication no.
debug2: we did not send a packet, disable method наиболее вероятно, что он не может обработать файл закрытого ключа (проблема с разрешением файла или с именем). SSH очень чувствителен к разрешениям каталогов и файлов как на локальных, так и на удаленных компьютерах. (chown user_name:user_group -R /home/user,chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys ). Итак, убедитесь, что ваши настроены правильно. Посмотри это: https://unix.stackexchange.com/questions/131886/ssh-public-key-wont-send-to-server
Что касается третьей ошибки: Permission denied (public key)., нужно проверить пару вещей.
- Неправильное имя пользователя
- Неправильная пара ключей
- Неправильный целевой хост
  - Вот подробности: https://stackoverflow.com/questions/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance.

Следующая часть немного сбивает с толку:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Чтобы лучше понять это, давайте рассмотрим процесс аутентификации шаг за шагом, как описано здесь на цифровой океан:

Клиент начинает с отправки идентификатора для пары ключей, с которой он хотел бы аутентифицироваться, на сервер.
Сервер проверяет файл authorized_keys учетной записи, в которую пытается войти клиент, на предмет идентификатора ключа.
Если в файле обнаружен открытый ключ с совпадающим идентификатором, сервер генерирует случайное число и использует открытый ключ для шифрования числа.
Сервер отправляет клиенту это зашифрованное сообщение.
Если у клиента действительно есть связанный закрытый ключ, он сможет расшифровать сообщение с помощью этого ключа, открыв исходный номер.
Клиент объединяет расшифрованное число с общим сеансовым ключом, который используется для шифрования связи, и вычисляет хэш MD5 этого значения.
Затем клиент отправляет этот хэш MD5 обратно на сервер в качестве ответа на зашифрованное числовое сообщение.
Сервер использует тот же общий сеансовый ключ и исходный номер, который он отправил клиенту, чтобы самостоятельно вычислить значение MD5. Он сравнивает свой расчет с расчетом, который клиент отправил обратно. Если эти два значения совпадают, это доказывает, что клиент обладал закрытым ключом, и клиент аутентифицирован.

В вашем случае, как видите, удаленный компьютер принял только ваши public key, зашифровал пакет этим ключом и отправил его обратно на клиентский компьютер. Теперь клиентскому компьютеру нужно доказать, что он имеет право private key. Имея только правильный private_key, он может расшифровать полученное сообщение и отправить ответ. В этом случае клиент не может этого сделать, и процесс аутентификации завершается безуспешно.

Надеюсь, это поможет вам разобраться в проблемах и решить их.

Правильны ли права доступа к вашим файлам ssh?

Папка .ssh -> 700

открытый ключ -> 644

закрытый ключ -> 600

Также проверьте пользователя и группу

Вы говорите, что у вас такой же ключ на машине с Windows; Вы уверены, что файл закрытого ключа на вашем компьютере с Linux правильный? Возможно, закрытый ключ находится в формате замазки, который ssh не легко понимает. В любом случае, если я помещаю неверный или недействительный файл закрытого ключа, я получаю точно такую же ошибку, что и у вас.

Чтобы исправить эту проблему, было бы правильнее сгенерировать новый ключ на машине Linux, а не повторно использовать ключ с другой машины. Вы можете просто добавить новый открытый ключ в файл authorized_keys на хосте, а затем использовать как ключ Windows из Windows, так и новый ключ Linux из Fedora.

Ваша проблема кажется довольно распространенной и, как я уже сказал, ясной.

 Permission denied (publickey).

это что-нибудь значит для вас? для меня это очень много значит для меня.

Вы можете проверить на стороне сервера, есть ли у вас selinux runnin в принудительном режиме, пожалуйста? если нет, скажите, в каком режиме работает selinux.

Кроме того, если вы можете сделать еще одну попытку, захватить журналы аудита этой попытки и опубликовать здесь, мы обязательно расскажем, почему:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Это проблема с разрешением, которая очевидна, но не с разрешением файла :-)

Кажется, проблема (в моем случае ...) была вызвана типом ключа.

Я только что решил это, добавив в локальный ~/.ssh/config файл (клиентская машина Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Хотя я добавил эту строку как в файл конфигурации сервера, так и в файл конфигурации клиента, только клиентская сторона имела значение. Обратите внимание, что разрешения должны быть 600 для чтения файла конфигурации.

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

Как оказалось, проблема заключалась (для меня) не в SSH, а в том, как PAM настраивал мои ключи. Конфигурация в /etc/pam.d был устаревшим (хотя он работал должным образом через Fedora 22), и в результате при входе в систему [больше] не выполнялись правильные действия, чтобы получить мои ключи от $HOME/.ssh/. Выполнение этой команды:

# sudo authconfig --updateall

правильно перестроил конфигурацию /etc/pam.d. При следующей перезагрузке, после того как я вошел в систему, когда я впервые попытался подключиться к серверу по ssh, в диалоговом окне меня попросили ввести кодовую фразу для моего ключа ssh ($HOME/.ssh/id_rsa). Я так и сделал, поставил галочку в поле «Автоматически разблокировать при входе в систему» и вуаля! Моя способность выходить по ssh с ноутбука была восстановлена.

Задний план

Ключ, который привел меня к решению этой проблемы, пришел, когда я импортировал ключ RSA из внешнего источника. (USB-ключ, который я ношу с собой, с ключом «удаленного доступа» для моей домашней сети. Я отключил PasswordAuth для моего внешнего сервера много лет назад после вторжения.) После ssh-add-ing КОТОРЫЙ Ключ RSA, в отличие от того, что сидит в $HOME/.ssh/id_rsa, удаленный сервер принял его без проблем.

Затем я сделал то, что должно было быть лишним ssh-add, подобрать $HOME/.ssh/id_rsa. Я заметил, что после того, как я это сделал, ssh-add -l содержал два записи для того же ключа:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

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

Я считаю, что именно это и происходило, и PAM передавал агенту SSH «плохие ключи», которые не были разблокированы с помощью парольной фразы. Итак, когда ssh попытался аутентифицироваться с помощью ключа, у него фактически не было (разблокированной) частной половины пары ключей, и поэтому аутентификация не удалась.

Этот последний бит является предположением, но независимо от того, есть ли у кого-то проблемы с ключами ssh, которые не принимаются удаленными хостами (где они были раньше) после обновления до F23, перестраивая /etc/pam.d/ каталог с использованием authconfig стоит попробовать как решение.

Проверьте права доступа к домашнему каталогу пользователя. Это важно. Должно быть 755. 700 или 770 работать не будут.

В твоем ssh_config, попробуйте раскомментировать и / или добавить / удалить / добавить к Cipher, Ciphers, или MACs линия (и).

Мне кажется, что sshd ищет определенный шифр какого-то типа, который не включается в запрос, который можно добавить, настроив его в вашем ssh_config.

... и я предполагаю, что у вас случайно нет PubkeyAuthentication установлен в no на удаленном сервере, потому что это определенно приведет к сбою.