t:~$ ssh localhost
Linux tt 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Oct 23 14:42:20 2009 from xxx.xxx.xxx.xxx
t:~$
Зачем снести? У меня авторизация по паролю закрыта. Даже если я её для проверки временно включу, что это поменяет? В рабочем режиме нужен доступ по ключу.
Права на ~/.ssh/ и ~/.ssh/authorized_keys именно такие и стоят.
Как ни странно, помогло chmod -R go-rw ~. В чём было дело, так и не понял, т.к. на ~/.ssh/ и ~/.ssh/* права несколько раз проверял: они тоже на обеих машинах были одинаковые.
Значит что-то ещё, связанное с правами доступа, в системе отличалось - имя пользователя, под которым запускался клиент SSH, ACL, SELinux и т.д. - что-то запрещало клиенту прочитать ключ из ~/.ssh/
Значит что-то ещё, связанное с правами доступа, в системе отличалось - имя пользователя, под которым запускался клиент SSH, ACL, SELinux и т.д. - что-то запрещало клиенту прочитать ключ из ~/.ssh/
ну да)) будем гадать на кофейной гуще "значит что то еще О_о, что же такое произошло "
2 t.t
Интересен 1н момент: ключик то как переносили через ssh-copy-id? или использовали scp, а потом выставляли нужные значения?? у меня вот как раз и возникла данная проблема если делать по 2му варианту, если по первому используя ssh-copy-id то проходит нормально
Значит что-то ещё, связанное с правами доступа, в системе отличалось - имя пользователя, под которым запускался клиент SSH, ACL, SELinux и т.д. - что-то запрещало клиенту прочитать ключ из ~/.ssh/
См. выше: изменяя _только_ права доступа для группы на всё в ~ кроме .ssh, получаю разный результат. Права на сам каталог ~ не влияют.
Пока выбрал такой способ: аккуратно меняю права только на те конкретные файлы, которые нужны -- пока всё работает. С утилитарной точки зрения можно на этом и остановиться (хоть это и не очень удобно в данной ситуации), но остаётся ещё академический интерес: что может проявляться столь странным образом?
2 t.t
Интересен 1н момент: ключик то как переносили через ssh-copy-id? или использовали scp, а потом выставляли нужные значения?? у меня вот как раз и возникла данная проблема если делать по 2му варианту, если по первому используя ssh-copy-id то проходит нормально
Ключ переносился с 15 на 14; т.е. проблема на источнике -- на приёмнике всё нормально. Учитывая, что проблема проявляется в том числе и при попытке входа с 15 на 15, причина явно не в этом. Да и чёткая корреляция с правами (см. выше) на то же указывает.
ну да)) будем гадать на кофейной гуще "значит что то еще О_о, что же такое произошло smile.gif "
Пардон, но из лога клиента SSH прекрасно видно, что он не находит ключ... Искать причну, по которой он её не находит - это не то же самое, что менять наугад что-то на ФС. )
Добавлю домыслов. Права к ~ — это довольно вероятная причина.
Если я, не рут и не владелец ~/.ssh, то я, вероятно могу удалить старый, истинный .ssh и создать свой, фейковый. При этом владелец почти ничего не заметит.
При использовании sftp и chroot, например, openssh требует не только того, чтобы директрия, в которую "чрутится" принадлежала только руту, но и все выщестоящие директории — тоже. Возможно, тут аналогично...
.
P.S. Удалите плз поторопился напсать, вздор это.
Сам, кстатт, частенько испытываю подобные проблемы с правами на ключи.
Публичный ключ должен быть доступен для чтения для всех (на сервере). Это понятно, иначе сервер не сможет его прочитать.
Приватный ключ (на клиенте) должен быть доступен только пользователю, но не группе (иначе он уже не приватный).
Права на ~/.ssh жёстко не оговариваются, только в рекомендательной форме.
Красная площадь — это не только точное время, но и культурная программа с цирком и зоопарком.
Причина отказа лежит в /var/log/auth.log на сервере.
Дело в том, что проблемная машина -- это не сервер, а кпк; там нет логов. Да и вряд ли там будет лежать что-то более осмысленное, чем в выводе самого ssh.
/etc/ssh/sshd_config и ~/.ssh/ на обеих машинах одинаковые
есть ещё и /etc/ssh/ssh_config
p.s. насколько понимаю, разница в версиях и/или опциях сборки ssh и/или sshd на этих двух машинах. на той, которая «кпк», вероятно, чуть более параноидальная сборка.
p.s. насколько понимаю, разница в версиях и/или опциях сборки ssh и/или sshd на этих двух машинах. на той, которая «кпк», вероятно, чуть более параноидальная сборка.
Не усмотрел, там действительно своя сборка. Да, не исключено, что проблема именно в этом.
Да, один момент.. Не "не усмотрел", а "забыл" -- т.е. я уже об этом думал. Вопрос в другом: можно ли как-то понять "по-вчёному", в каких именно файлах проблема? Или только методом научного тыка?
Загадка природы.. Методом научного тыка выяснил, что как раз влияют:
n810
$ ssh localhost
Permission denied (publickey).
$ chmod g-w ~
$ ssh localhost
BusyBox v1.6.1 (2008-09-18 09:43:17 EEST) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
$
Есть подозрение, что дело даже и не в сборке. На ноуте сейчас проверить не могу, но не исключаю, что там будет то же.
Одно непонятно: почему оно в этом случае ругается на public key? Особенно интересны вот эти две строчки:
n810
debug3: no such identity: /home/t/.ssh/id_dsa
[...]
debug1: No more authentication methods to try.
Дело в том, что id_dsa там действительно нет -- есть id_rsa. И на него, как и на всё остальное содержимое ~/.ssh/ и на сам каталог, права не менялись -- только на ~.
Это не баг. При дебаг аутпуте просто выдаётся сообщение, что id_dsa не был найден. id_rsa был найден и сообщения не было. Просто сервер не может передать клиенту сообщение, что он отказал в доступе по ключу из-за наличия прав записи на хомяк кем либо помимо юзера. Это сообщение он может лишь записать в свой лог.
Если сообщение на стороне клиента о слишком больших правах на сервере не уместно (что имеет свои резоны), то всё равно здесь правильнее было бы рапортовать об абстрактной server-side problem, а не ругаться на publickey, который к этой проблеме совершенно ни при чём.
The file permissions should be locked down to prevent other users from being able to read the key pair data. OpenSSH may also refuse to support public key authentication if the file permissions are too open. These fixes should be done on all systems involved.
Permision denied (publickey). — это довольно неопределенное сообщение сервера об ошибке, если, например, на сервере разрешено логиниться только по ключу и запрещено логиниться какому-нибудь конкретному пользователю, то при попытке залогиниться именно им появится именно это сообщение
Permision denied — означает просто невозможность залогиниться по любой причине.
(publickey) — возможные способы аутентификации. Если разрешить просто заходить и по паролю, то при невозможности логина будет написано (publickey, password).
То есть, (publickey) не означает, что ошибка именно в ключе, может быть в чём угодно.
Красная площадь — это не только точное время, но и культурная программа с цирком и зоопарком.
В том-то и дело, что не во всех: на всё содержимое каталога Mail стоит g+rw и всё работает.
гхм. видимо, я уже чего-то совсем в тему не въезжаю. r, w, g, o — это я говорил про ~/.ssh и его содержимое. ну да ладно…
А, извини, это я из контекста. Нет с этими правами всё нормально (я их возвращал в исходное состояние после изменения прав на весь домашний каталог).
Вообще, в целом картина довольно интересная. Права на домашний каталог влияют и на дебиановской машине -- т.е. сборка ssh тут действительно ни при чём. Но ещё интереснее другое: если разрешить вход по паролю, то при тех же правах пускает; по ключу -- нет. Слишком либеральные права, специально отмечу, выставлены только на ~, не рекурсивно: на всё содержимое, включая .ssh/, права стоят правильные. Т.е. чем обусловлена такая разница (между входом по паролю и по ключу), мне непонятно.
" 
