Ssh авторизация ключу не работает

Перестала работать авторизация в SSH по ключу

Внезапно сервер перестал принимать авторизацию по ключу, при попытке логина начал спрашивать пароль. Генерация новых ключей не помогла, с других компов так же не пускает. Смена прав на .ssh/authorized_keys не помогает. Как лечить?

debug3: Could not load «/home/sasha/.ssh/id_rsa» as a RSA1 public key

debug2: key_type_from_name: unknown key type ‘——BEGIN’

очевидно не верный формат ключа.

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

попробуй отключить GSSAPIAuthentication

есть чего в /var/log/secure? MTU пробовал менять?

права на файл ключа какие? вроде раньше ssh ругался на права, выставленные не так, как ему надо. authorized_keys на сервере и id_rsa на клиенте должны иметь права -rw——-

Я пробовал разные варианты прав. Ну не могли они внезапно поменяться (перед первым запросом пароля была успешная авторизация по ключам).

ну вот видишь — проблема все-таки в правах. чини

Сменил с 775 на 755 и все заработало. Спасибо всем.

ЩИТО? А зачем на ключи ставить exec-права? Во всех хаутушках пишут, что надо так:
chmod 600 authorized_keys

/.ssh не должно быть прав для других на чтение.

У меня была идентичная проблема месяц назад.

1 Вариант: попробуй отменить авторизацию о ключам и верни стандартную. когда заработает, верни ключи.

2 Вариант: если не помог первый (мне не помог, зато помог приятелю, который его советовал), переустанови ssh. Времени на 20 минут со всеми настройками. Мне это помогло. При чем, почему возникает этот сбой, я так и не понял((

Все починилось после смены прав на домашнюю директорию пользователя.

Источник

SSH. Не работает авторизация через ключ. Просит пароль

Обычный хостинг. У хостера несколько серверов. На первом сервере авторизация через ключ работает. На втором нет, просит пароль.

Аккаунт на втором сервере, где НЕ работает:

Первый сервер, где работает:

Кто сталкивался, почему так происходит?

Как то у меня было такое. Помогло пересоздание пары ключей

Раз 10 уже как минимум проделал процедуру, и с RSA и с DSA. Даже генерировал ключ на 1 сервере, закачивал на второй, подключался с 1го ко 2му, просит пароль.

права проверь на каталог и файлы в .ssh, должны быть даны только пользователю на всё.

а, еще че вспомнил! посмотри внутрь id_rsa.pub

отредактируй его вот так:

и перезалей на оба хоста в authorized_keys

Глупый вопрос: а если ввести неправильный пароль — столько раз, сколько попросит? Как-то не понял, тот сервер пропускает аутентификацию по ключу, или просто применяет в другом порядке?

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

Возмножно, что на втором сервере у хостера просто sshd настроен по другому, допустим AuthorizedKeysFile указывает на другой файл. Вы в техподдержку обращались?

И на всякий случай, ключ не от рута надо генерить, а от обычного пользователя, если ты собираешься использовать ключ кем-то кроме рута

Судя по логам, сертификатid_dsa_p2011 или не соответствует закрытому ключу пользователя, или, что более вероятно, этот сертификат недоступен для OpenSSH. Проверьте права на файл /home/user/.ssh/id_dsa_p2011

В чём именно проблема крылась не знаю, но техподдержка еле еле с 3 раза починила/включила авторизацию по ключу.

Источник

Настройка SSH авторизации по ключам

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

Введение

Пару слов о чем тут пойдет речь. Для подключения по ssh можно использовать связку логин-пароль, а можно логин-сертификат. В интернете всюду рассказывают о том, что сертификат это безопасно и надо обязательно использовать его для авторизации на сервере. Все, что не по сертификату — дурной тон и дилетантство. Я совершенно не разделяю это мнение и сам всегда использую связку логин-пароль, более того, я чаще всего захожу сразу под root. Я искренне не понимаю, зачем заходить под обычным пользователем и каждый раз вводить sudo и пароль. Я захожу на сервер для совершения административных действий и мне всегда нужны полные права. Что мне там делать под обычным пользователем ума не приложу.

За все время моей работы с серверами у меня никогда не было проблем, связанных с авторизацией по паролю, поэтому я считаю пустой тратой времени какие-то дополнительные действия в этом плане, если нет особой необходимости. Доводы о том, что пароль могут сбрутить выглядят несостоятельными. Пароль должен быть сложным, и брутить его никто не будет. Даже если будут, то есть fail2ban, который быстро отключит желающих побаловаться. Хотя я сомневаюсь, что сейчас кто-то занимается брутом ssh.

Об одном таком нюансе я и расскажу. Мне понадобилось настроить авторизацию ssh по сертификату. Причем авторизовываться будет сразу пользователь root. Заходить будут как по паролю, так и по сертификату. Мне необходимо вести учет того, кто по какому сертификату подключился по ssh к серверу.

Создание ssh ключей для putty

Для управления серверами я использую windows машину и ssh клиент putty. В составе программного комплекса putty есть утилита для генерации ключей — puttygen. Скачивайте ее по ссылке с официального сайта — https://the.earth.li/

sgtatham/putty/latest/x86/puttygen.exe. После запуска нажимайте на кнопку Generate и двигайте мышкой, пока не сформируется пара ключей — открытый и закрытый.

Key passphrase	Можно задать пароль для приватного ключа. Ставить или нет на ваше усмотрение.
Save public key	Кнопка сохранения публичного ключа. Он размещается на удаленном сервере.
Save private key	Кнопка сохранения приватного ключа. Ключ хранится у клиента и используется для подключения к серверу.
SSH-2 RSA 2048	Тип ключа и его длинна. Значения по-умолчанию подходят в полной мере для нашей задачи.

Формат ключей, которые создает puttygen не подходит для openssh, который стоит на сервере, поэтому содержимое открытого ключа в нужном формате копируем из окна puttygen. Я указал этот ключ стрелочкой на скриншоте. Именно это содержание пойдет на сервер. Сохраняйте ключ в формате openssh, а так же два других с помощью кнопок Save key.

Настройка ssh на сервере для авторизации по сертификатам

Здесь все просто. Во всех известных мне дистрибутивах авторизация по сертификатам уже настроена, нужно просто добавить этот сертификат на сервер. Сделаем это.

В файл authorized_keys вставляйте скопированный ключ из окна puttygen. Сохраняйте и подключайтесь с помощью сертификата. В putty сертификат нужно указать в разделе Connection -> SSH -> Auth.

Выбрать нужно приватный ключ, у которого расширение .ppk. Напоминаю, что на сервер мы отправили публичный ключ. Этот ключ можно использовать на множестве серверов, так что нет необходимости для каждого сервера генерировать новую пару ключей. Везде можно использовать один и тот же.

Теперь можно подключаться, необходимости перезапускать службу ssh нет.

Логирование ssh подключений по сертификату

Мне необходимо знать, когда и какой сертификат подключался к серверу. По-умолчанию такой информации чаще всего в логах не остается. Исключение я заметил только в CentOS 7. Там с дефолтными настройками ssh и уровнем логирования INFO отображается отпечаток ключа в логе:

По отпечатку становится понятно, какой сертификат подключился. Для каждого сертификата отпечаток можно посмотреть в puttygen. В CentOS более ранних версий, в Ubuntu 12 и 14 в логах будет только такая информация:

Информации о самом ключе нет. Я так думаю, это зависит от версии OpenSSH. В первом случае 6-я версия, во втором 5-я. Специально я не проверял. Если у вас нет информации о ключе в лог файле, исправить это очень просто. В файле /etc/ssh/sshd_config меняем параметр:

и перезапускаем службу:

Пробуем снова подключиться по ssh, используя сертификат, и проверяем лог:

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

Источник

Авторизация по ключу в SSH не работает. Что еще забыл сделать?

Сгенерировал на домашней машине пару ключей (от пользователя myuser):

В результате в каталоге пользователя

/.ssh появилось два файла:

Файл id_rsa.pub скопировал на сервер, в каталог

/.ssh пользователя myuser (т.е. пользователь на сервере называется так же как и на локальной машине). Но так как в директории уже был файл id_rsa.pub (сделан на работе), то сохранил публичный ключ домашней машины под именем

Затем на сервере в файле /etc/ssh/sshd_config прописал:

Захожу под пользователем по ssh:

(-l впринципе необязательно, т.к. имена пользователей совпадают, пробовал и так и так)

И в результате все равно требуется пароль.

Вопрос. Где что еще надо крутить, чтобы заработал вход по сертификату?

Файл id_rsa.pub скопировал на сервер, в каталог

/.ssh пользователя myuser (т.е. пользователь на сервере называется так же как и на локальной машине). Но так как в директории уже был файл id_rsa.pub (сделан на работе), то сохранил публичный ключ домашней машины под именем

Затем на сервере в файле /etc/ssh/sshd_config прописал:

надо было просто его содержимое скопировать в

Икзэктли. Причём туда их можно вписать сколько угодно.

Права на файл проверь. И весь дебаг ссш есть тут.

sudo /usr/sbin/sshd -D -d -d -d -e

ssh -v для начала, и я очень не уверен, что sshd нормально воспринимает множественные AuthorizedKeysFile (собственно, что мешает скопировать ключ в дефолтный authorized_keys?)

ты можешь в один authorized keys file запихнуть несколько ключей сразу.

если машина centos/rhel, попробуй выключить selinux временно. Это может мешать при отсутствии нужного контекста для публ.ключа на сервере.

полностью согласен с Belkrr. генерируете ключи от того пользователя под которым работаете

И пытаешься войти по ssh user@host -i

надо было просто его содержимое скопировать в

Спасибо, так сработало.

sshd, по крайней мере мой, понимает только первую из AuthorizedKeysFile директив, вторую просто игнорирует. Для указания нескольких файлов надо их перечислять через пробел в одной директиве.

Не забывай ещё, что права на

/.ssh должны быть 700, а на

а ты сделай у себя на серваке chmod 755

/.ssh/authorized_keys и попробуй залогиниться по ключу. он у тебя пароль спросит, я гарантирую это.

а ты сделай у себя на серваке chmod 755

/.ssh/authorized_keys и попробуй залогиниться по ключу. он у тебя пароль спросит, я гарантирую это.

Это разве только не для самого ключа?

не спросил, что ещё расскажешь?

У тебя он уже создан был (а я ща на виртулке centos 6.3 заново создавал), подозреваю, что права sshd проверяет только при старте. Надо было наверно рестарт демона ещё сделать.

Смотри, я ниже пример привёл.

У тебя он уже создан был (а я ща на виртулке centos 6.3 заново создавал), подозреваю, что права sshd проверяет только при старте. Надо было наверно рестарт демона ещё сделать.

Прозреваю selinux, у меня ведет себя иначе, как видишь.

Не чушь. Давеча федорку настраивал — пока не выставил указанные права, ничего не работало.

права sshd проверяет только при старте.

если бы это было так, то это была бы дыра в безопасности.

Надо было наверно рестарт демона ещё сделать.

ничего не изменилось, жду ещё чудесных историй.

нет, selinux’а нету. Да у меня и при настройке sshd на других виртуалках (debian, ubuntu, netbsd, freebsd, openbsd — да, да упоротый проект, все эти системы им поддерживаются) такая же ситуация.

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

ну попробуй, как у меня в примере. Я файлик создавал заново cat’ом. я же не из головы тебе лог прислал, а из консоли скопипастил =)

Вон у post-factum такая же ситуация.

ну так это видимо федорка так настроена/пропатчена.

т.е. указанные настроки — рекомендованные, но не обязательные.

я тебе уже писал, что проверка прав при старте — дыра в безопасности, и рестарт я делал, и пересоздавал — все работает чудесно, причем не у меня одного.

А что за система и версия sshd?

debian testing/OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012
debian stable/OpenSSH_5.5p1 Debian-6+squeeze2, OpenSSL 0.9.8o 01 Jun 2010
freebsd 9.1/OpenSSH_5.8p2_hpn13v11 FreeBSD-20110503, OpenSSL 0.9.8q 2 Dec 2010

везде поведение одно и то же.

если бы это было так, то это была бы дыра в безопасности.

дыра — это если не проверяет, как у тебя. Должен проверять. Т.ч. поздравляю: у тебя РЕШЕТО.

т.е. указанные настроки — рекомендованные, но не обязательные.

выполни chmod 0777 /

у тебя всё будет работать. Хотя это и «не рекомендуется».

— I copied my public key to authorized_keys but public-key authentication still doesn’t work.

Typically this is caused by the file permissions on $HOME, $HOME/.ssh or $HOME/.ssh/authorized_keys being more permissive than sshd allows by default.

BY DEFAULT. Видимо, у тебя в конфиге что-то отличается от дефолтного. Конкретную настройку искать лень.

дыра — это если не проверяет, как у тебя

у меня — проверяет, если выставить 777, то спрашивает пароль, как и должен, если выставить 755/644 — не спрашивает.

я выше приводил выдержку из мана — не обязан authorized_keys быть с правами 600.

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

качай телепатию дальше — она у тебя плохо прокачана.

StrictModes no — вроде это нужный сеттинг в конфиге, проверь у себя, не выставлен ли он

BY DEFAULT. Видимо, у тебя в конфиге что-то отличается от дефолтного. Конкретную настройку искать лень.

конфиги самые что ни на есть дефолтные, так что ты тоже, как и drBatty идешь качать телепатию дальше.

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

У меня StrictModes стоит в yes. Да читал я твою выдержку, факт-то в том, что у меня и других воспроизводится, а у тебя нет. Мне вообще пофиг, я не админ и ссш поднимаю исключительно на тестовых виртуалках, я написал изначально ТСу, чтобы не напоролся на те же грабли, что и я.

не держать файлы world-writable — не то же самое, что держать на них права 600. прочитал твой лог выше ты делаешь права на authorized_keys 664, т.е. доступными на запись группе, а именно это — дыра в безопасности. у меня же права 644/755 — дыры нет.

я выше приводил выдержку из мана — не обязан authorized_keys быть с правами 600.

я и не спорю — не обязан. Расскажи, зачем нужны права большие, чем 0600?

я где-то утверждал, что они нужны?

странный способ неспорить — утверждать что у собеседника система — решето.

ты утверждал, что

у меня — проверяет, если выставить 777, то спрашивает пароль, как и должен, если выставить 755/644 — не спрашивает.

по моему мнению — это решето. потому как доступ группы и всех прочих юзеров к этим файлам не нужен, а если он есть, то это дыра в безопасности. Злоумышленник может например подменить наш сервер своим сервером, прочитав наш ключ из

/.ssh/authorized_keys. Для этого ему нужно всего-лишь иметь какой-то доступ (любой, хоть nobody) к этому серверу — твой .ssh/authorized_keys доступен для чтения всем подряд.

странный способ неспорить — утверждать что у собеседника система — решето.

странный способ обеспечивать безопасность объекта — ходить и смотреть может кто угодно, только ломать ничего нельзя. Если по твоемы это — охраняемый объект, то по моему — публичное место, по типу музея.

ага, т.е. подделать ключ от сервера или добавить его в known_hosts для тебя не проблема. давай, досвидания, теоретик.

ага, т.е. подделать ключ от сервера или добавить его в known_hosts для тебя не проблема. давай, досвидания, теоретик.

да без проблем. Можешь не только чтение, но и запись открыть, кому нафиг нужен твой локалхост?

Можешь не только чтение, но и запись открыть, кому нафиг нужен твой локалхост?

теоретик не в курсе, что после того как он украл закрытый ключ от сервера/подсунул свой ключ в known_hosts пользователя, он может «легко и просто» подсунуть пользователю вместо его сервера настроенный на безпарольный вход сервер, и никакой украденный authorized_keys ему уже не нужен?

может ты ещё и отпечаток gpg ключей прячешь, чтобы случайно никто вместо тебя не подписался? ты вообще в курсе как работает криптография на открытых ключах?

теоретик не в курсе, что после того как он украл закрытый ключ от сервера/подсунул свой ключ в known_hosts пользователя, он может «легко и просто» подсунуть пользователю вместо его сервера настроенный на безпарольный вход сервер, и никакой украденный authorized_keys ему уже не нужен?

в курсе. А при чём тут это?

может ты ещё и отпечаток gpg ключей прячешь, чтобы случайно никто вместо тебя не подписался? ты вообще в курсе как работает криптография на открытых ключах?

я-то в курсе. Вот только ты не совсем понимаешь небольшой разницы, между моим публичным gpg-ключом (который ты можешь посмотреть в моём профиле), и публичным ключом на моих серверах. Разница есть, и понять её не сложно:

• я хочу, что-бы кто угодно смог проверить мою подпись, воспользовавшись моим gpg ключом с сервера ключей или ещё откуда-то.
• я НЕ хочу, что-бы кто угодно проверял, я это или не я захожу на сервер. Мне необходимо, и достаточно того, что сервер проверяет, я это или не я. Мне НЕ НУЖНО, что ты будешь пускать меня на свои сервера. Потому эта ненужная возможность запрещена.

А теперь, о великий и опытный практик, расскажи, зачем ты открыл для всех ключи на твоём сервере?

при том, что такому умному хакеру, как drBatty не надо читать authorized_keys — он не имеет для него смысла. именно поэтому смысла скрывать его от всех нет — он не несет никакой информации, которая может помочь взлому.

А теперь, о великий и опытный практик, расскажи, зачем ты открыл для всех ключи на твоём сервере?

с чего ты взял, что я так делаю, теоретик?

при том, что такому умному хакеру, как drBatty не надо читать authorized_keys — он не имеет для него смысла. именно поэтому смысла скрывать его от всех нет — он не несет никакой информации, которая может помочь взлому.

выше я уже пытался тебе объяснить, какая там информация, и как её применять. Жаль, что ты не понял.

А теперь, о великий и опытный практик, расскажи, зачем ты открыл для всех ключи на твоём сервере?

с чего ты взял, что я так делаю, теоретик?

теоретически 0644 — это разрешение доступа для всех. Любой может забрать у тебя эти ключи.

Я могу провести аналогию, что-бы тебе было более проще понять теоретическую часть: Твой секретный ключ, это ключ IRL, а вот в authorized_keys лежит сам замок. Точнее его личинка (замок sshd у всех одинаковый, но вот личинка authorized_keys у всех разная). Если ты сделал доступной для всех эту личинку, то конечно это не говорит о том, что кто-то может глядя на неё сделать нужный ключ. Тут ты прав. Однако, этот кто-то может сделать точный клон такого замка. Конечно, само по себе это не смертельно — ты дверь ведь не перепутаешь, потому, кажется, что враг может хоть обделаться клонами замков, ты об этом и не узнаешь.

Однако. Я не только теоретик, я на таких как ты уже насмотрелся, «практиков». У вас ВСЁ так. Если можно доступ открыть — надо его открыть, «на всякий случай». На какой конкретно случай — вы ответить не можете. Вот и получается IRL решето.

На самом деле, если ты не знаешь, надо или нет давать доступ, то НЕ НАДО. Твоя ведь система? Ну будет надо — дашь. Зачем заранее? Именно потому права на этот файл должны быть точно 0600, и никакие другие. А права на каталог 0700.

Вот в RH и пришлось такой костыль повесить, для нерадивых одминов-практиков. В слаке например такого костыля нет. Про деб — не знаю, никогда таких прав не ставил.

вы, дорогой мой друг, фантазируете в этом топике слишком много.
сначала про то, что мой sshd не проверяет права на файлы, потом про то, что злобный хакир украдет authorized_keys и подсунет свой сервер, потом что у меня права на authorized_keys 644(для альтернативно умных — я их такими делал на время проверки, что с такими правами ssh отлично заходит).
Теперь вообще про то, что если админу в одном месте поставить костыль, то он внезапно станет лучше админить. (хотя даже по этому топику видно, что это не так — админ просто запомнит, что на этот файл надо делать определенные права, без понимания почему, и без понимания, где ещё такие права надо выставить).

а ещё меня забавляет ваша потребность объяснить мне то, что я только что вам объяснил.

сначала про то, что мой sshd не проверяет права на файлы

ты сам это сказал. Я уже цитировал. Повторить?

потом про то, что злобный хакир украдет authorized_keys и подсунет свой сервер

потом что у меня права на authorized_keys 644(для альтернативно умных — я их такими делал на время проверки, что с такими правами ssh отлично заходит).

ну тебе для статистики: в слаке тоже заходит. Я же не говорил, что плохо заходит, наоборот — хорошо. Даже слишком хорошо.

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

по дефолту права 0644 выставляются. И если всё работает, тот такие как ты кричат «так и надо!». В данном случае — не надо. Может и задумается…

а ещё меня забавляет ваша потребность объяснить мне то, что я только что вам объяснил.

Источник