LINUX.ORG.RU
Форум — Admin  

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


0

1

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

ssh-keygen -t rsa -C 'myuser@mail.ru'

В результате в каталоге пользователя ~/.ssh появилось два файла:

id_rsa
id_rsa.pub

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

id_rsa_home.pub

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

RSAAuthentication yes               
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/id_rsa.pub
AuthorizedKeysFile      .ssh/id_rsa_home.pub

Перезапустил sshd:

service sshd restart

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

ssh -l myuser 92.38.233.222

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

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


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

★★★★★
← пароль
Ipv6 для PPPtP →
 ← 1 2

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

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

надо было просто его содержимое скопировать в ~/.ssh/authorized_keys

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

Hoodoo ★★★★★
()

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

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

testuser123 ★
()

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

leave ★★★★★
()

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

true_admin ★★★★★
()

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

Bers666 ★★★★★
()

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

ssh-copy-id myuser@92.38.233.222
ssh myuser@92.38.233.222

samarin
() 
AuthorizedKeysFile      %h/.ssh/id_rsa.pub
AuthorizedKeysFile      %h/.ssh/id_rsa_home.pub

Рестарт ssh.

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

tazhate ★★★★★
()
Ответ на: комментарий от tazhate

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от DELIRIUM

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

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

tazhate ★★★★★
()
Ответ на: комментарий от DELIRIUM 
taz@think ~ $ ssh 127.0.0.1
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ECDSA key fingerprint is 87:68:d7:d9:45:b9:b3:07:25:db:1c:1a:5d:aa:8c:82.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
Password: 
Last login: Tue Jan  8 02:08:08 MSK 2013 on :0.0
taz@think ~ $ exit
logout
Connection to 127.0.0.1 closed.
taz@think ~ $ ssh-copy-id 127.0.0.1
Password: 
Now try logging into the machine, with "ssh '127.0.0.1'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

taz@think ~ $ ssh 127.0.0.1
Last login: Sun Jan 13 22:44:52 MSK 2013 from localhost on ssh
taz@think ~ $ exit
logout
Connection to 127.0.0.1 closed.
taz@think ~ $ ls -lah .ssh/known_hosts 
-rw-r--r-- 1 taz taz 8,6K янв.  13 22:44 .ssh/known_hosts
taz@think ~ $ chmod 775 .ssh/known_hosts 
taz@think ~ $ ssh 127.0.0.1
Last login: Sun Jan 13 22:44:55 MSK 2013 from localhost on pts/2
taz@think ~ $ exit
logout
Connection to 127.0.0.1 closed.
tazhate ★★★★★
()
Последнее исправление: tazhate (всего исправлений: 1)
Ответ на: комментарий от maloi 

[del@centos-vbox ~]$ cat id_rsa.pub >> .ssh/authorized_keys # создаём файл
[del@centos-vbox ~]$ ls -l ./.ssh
total 8
-rw-rw-r--. 1 del del  394 Jan 13 22:49 authorized_keys # видим 664
-rw-r--r--. 1 del del 1471 Sep 25 19:51 known_hosts


[del@centos-vbox ~]$ ls -la|grep .ssh
-rw-------.  1 del  del        148 Sep 24 20:15 .lesshst
drwxr-xr-x.  2 del  del       4096 Jan 13 22:49 .ssh # видим 755
[del@centos-vbox ~]$ chmod 700 .ssh


[del@centos-vbox ~]$ logout
Connection to 192.168.1.5 closed. # вышли

del@del-lmde:~$ ssh del@192.168.1.5
del@192.168.1.5's password: # пароль спросили

Last login: Sun Jan 13 22:49:45 2013 from 192.168.1.2
[del@centos-vbox ~]$ chmod 600 .ssh/authorized_keys 
[del@centos-vbox ~]$ logout
Connection to 192.168.1.5 closed. # вышли

del@del-lmde:~$ ssh del@192.168.1.5
Last login: Sun Jan 13 22:50:17 2013 from 192.168.1.2 # пароль не спросили

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

DELIRIUM ☆☆☆☆☆
()
Последнее исправление: DELIRIUM (всего исправлений: 1)
Ответ на: комментарий от DELIRIUM

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

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

tazhate ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

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

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

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

maloi ★★★★★
()
Ответ на: комментарий от tazhate

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

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

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от maloi

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

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

DELIRIUM ☆☆☆☆☆
()
Последнее исправление: DELIRIUM (всего исправлений: 1)
Ответ на: комментарий от post-factum

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

     ~/.ssh/authorized_keys
             Lists the public keys (DSA/ECDSA/RSA) that can be used for logging in as this user.  The format of this file is described above.  The content of the file is not highly sensitive, but the recommended permis‐
             sions are read/write for the user, and not accessible by others.

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

maloi ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

maloi ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

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

drBatty ★★
()
Ответ на: комментарий от maloi

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

выполни chmod 0777 /

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

drBatty ★★
()
Ответ на: комментарий от maloi

тыц

- 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. Видимо, у тебя в конфиге что-то отличается от дефолтного. Конкретную настройку искать лень.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от drBatty

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

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

Должен проверять.

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

Т.ч. поздравляю: у тебя РЕШЕТО.

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

maloi ★★★★★
()
Ответ на: комментарий от drBatty

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

maloi ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

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

maloi ★★★★★
()
Ответ на: комментарий от DELIRIUM

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

И мою прочитай.

     StrictModes
             Specifies whether sshd(8) should check file modes and ownership
             of the user's files and home directory before accepting login.
             This is normally desirable because novices sometimes accidentally
             leave their directory or files world-writable.  The default is
             “yes”.  Note that this does not apply to ChrootDirectory, whose
             permissions and ownership are checked unconditionally.

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

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от DELIRIUM

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

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

drBatty ★★
()
Ответ на: комментарий от drBatty

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

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

maloi ★★★★★
()
Последнее исправление: maloi (всего исправлений: 1)
Ответ на: комментарий от maloi

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от drBatty

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

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

drBatty ★★
()
Ответ на: комментарий от drBatty

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

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

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от drBatty

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

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

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

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

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

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

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

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

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

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

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

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

drBatty ★★
()
Ответ на: комментарий от drBatty

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

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

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

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

почему нет?

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

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

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

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

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

дык какие права НАДО ставить?

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← пароль
Admin
Ipv6 для PPPtP →