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

Helo,

У меня проблема с 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

Спасибо

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

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

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

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

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

• Кажется, здесь участвуют два разных пользователя. /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). Итак, убедитесь, что ваши настройки установлены правильно. Смотрите это: /unix/131886/ssh-public-key-wont-send-to-server

• Что касается третьей ошибки: Permission denied (public key).есть пара вещей, которые нужно проверить.

  • Неправильное имя пользователя
  • Неправильная пара ключей

  • Неправильный целевой хост

    • Вот более подробная информация: /programming/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

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

1. Клиент начинает с отправки идентификатора для пары ключей, которую он хотел бы аутентифицировать на сервере.
2. Проверка сервера - это файл author_keys учетной записи, в которую клиент пытается войти для идентификатора ключа.
3. Если в файле обнаружен открытый ключ с соответствующим идентификатором, сервер генерирует случайное число и использует открытый ключ для шифрования номера.
4. Сервер отправляет клиенту это зашифрованное сообщение.
5. Если у клиента действительно есть связанный закрытый ключ, он сможет расшифровать сообщение, используя этот ключ, показывая исходный номер.
6. Клиент объединяет расшифрованный номер с общим ключом сеанса, который используется для шифрования связи, и вычисляет хэш MD5 этого значения.
7. Затем клиент отправляет этот хэш MD5 обратно на сервер в качестве ответа на сообщение с зашифрованным номером.
8. Сервер использует тот же общий ключ сеанса и исходный номер, который он отправил клиенту, чтобы самостоятельно рассчитать значение MD5. Он сравнивает свой собственный расчет с тем, который клиент отправил обратно. Если эти два значения совпадают, это доказывает, что клиент обладал закрытым ключом и клиент прошел проверку подлинности.

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

Я надеюсь, что это поможет вам понять проблемы и решить их.

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

Папка .ssh -> 700

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

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

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

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

Чтобы исправить проблему, было бы правильнее сгенерировать новый ключ на компьютере с Linux, а не повторно использовать ключ с другого компьютера. Вы можете просто добавить новый открытый ключ в файл author_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-ный ТОГО ключ 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на удаленном сервере, потому что это определенно приведет к сбою.