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

9

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

Спасибо

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

Preovaleo
источник
Вы проверяли этот вопрос и ответы на сервере ? Может быть, это ошибка в вашем shadow.conf
Хенрик
Вы видите какие-либо сообщения об отказах SELinux или сообщения SECCOMP в ходе аудита? ausearch -m SECCOMPили ausearch -m AVC? В последнее время произошли некоторые изменения, которые могут повлиять на некоторые настройки.
Jakuje
1
Привет, Спасибо за все ваши ответы, но я не нашел, что случилось. Я понижаю до f22, и теперь это работает. хорошего дня
Preovaleo
какие-нибудь логи в sshd?
нейтринус
1
Главное, чего здесь не хватает - это логи с сервера. Журналы клиента никогда не могут рассказать всю историю. Если вы добавите соответствующие журналы сервера, вероятность получения ответа значительно возрастет.
Дженни Д

Ответы:

3

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

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

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

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

  • Кажется, здесь участвуют два разных пользователя. /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).есть пара вещей, которые нужно проверить.

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

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, он может расшифровать полученное сообщение и отправить ответ обратно. В этом случае клиент не может это сделать, и процесс аутентификации завершается безуспешно.

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

ромб
источник
2

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

Папка .ssh -> 700

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

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

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

встроенный
источник
Спасибо за ваш ответ, но я уже проверю это.
Preovaleo
2

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

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

Law29
источник
Спасибо за ваш ответ, но да, закрытый ключ хорош (забавный факт: 1 час, чтобы найти, как использовать его в шпатлевке !!).
Preovaleo
Согласно вашему (очень аргументированному) решению проблемы, закрытый ключ был хорошим, но клиент не мог его использовать, хотя и думал, что сможет. Я подозреваю, что могло быть что-то, что должно было спросить у вас пароль, но не удалось. Это объясняет, почему это работало до обновления; обновление либо неправильно настроило процедуру запроса парольной фразы, либо испортило ее, если она уже была там, и sudo authconfig --updateallисправило ее.
Law29
2

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

 Permission denied (publickey).

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

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

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

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

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

ostendali
источник
+1 Видел это и на RHEL7.1. Пожалуйста, расширяться с audit2allow:)
kubanczyk
1

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

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

PubkeyAcceptedKeyTypes=+ssh-dss

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

Йерун
источник
это не вариант. Вопрос в том, что ключом является RSA.
Jakuje
@Jakuje Да, казалось бы, я не заметил. Ну, может быть, это помогает другим людям, так как у меня была та же проблема после обновления вчера.
Jeroen
@jeroen, по умолчанию он использует rsaключ. См. Ссылку Fedora здесь , если она не настроена. Конечно, можно выбрать тип ключа для настройки и использования.
Бриллиант
2
@jeroen В дальнейшем тестировании я не рекомендую; К сожалению, gnome-keyring-daemon не получает файлы $ HOME / .ssh / id_ecdsa, поэтому эти ключи не будут разблокированы и автоматически добавлены в ssh-agent сеанса при входе в систему. Во всяком случае, с тех пор я обновил свой сервер до F23, и между ним и оставшимся клиентом F22 (в любом направлении) нет проблем с использованием ключей RSA. В то время как ключ ECSDA действительно предоставляет обходной путь для моего единственного ноутбука, который нуждается в этом (где любые попытки использовать ключи RSA терпят неудачу), корневая проблема, кажется, является чем-то другим.
15:56
1
Спасибо за полезный ответ. Обратите внимание, что вам нужно будет внести те же изменения на сервере, если сервер обновлен до OpenSSH 7.0 или новее (например, если он обновлен до Fedora 23 или выше). См. Superuser.com/q/1016989/93541 .
DW
1

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

Проблема, как выясняется, не была (для меня) вообще с 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стоит попробовать в качестве решения.

FERD
источник
0

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

NoAngel
источник
0

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

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

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

rubynorails
источник