Перестала работать авторизация в 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 не работает. Что еще забыл сделать?
Сгенерировал на домашней машине пару ключей (от пользователя 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 выставляются. И если всё работает, тот такие как ты кричат «так и надо!». В данном случае — не надо. Может и задумается…
а ещё меня забавляет ваша потребность объяснить мне то, что я только что вам объяснил.
Источник