Проблема с ssh-авторизацией по ключам

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

1 . А здесь ты что сделал?

2. Неправильные права на директории/файлы в ~/.ssh

3. vi /etc/ssh/sshd_config

selinux

Убери комменты в /etc/ssh/sshd_config

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile     .ssh/authorized_keys

Надо в sshd_config убрать остальные варианты авторизации.

tail /var/log/auth.log

Сразу после попытки авторизации и запроса пароля на клиенте и сервере покажи.

Надо в sshd_config убрать остальные варианты авторизации.

ага, чтоб он вообще войти не смог?

авторизация по ключу и паролю может вполне спокойно существовать параллельно.

Подскажите пожалуйста в чем могут быть грабли?

Неверные настройки sshd, отключена авторизация, неверно указан файл ключей

Не передал публичный ключ на сервер, вместо последовательности команд советую использовать просто ssh-copy-id логин@сервер

Неверные права на файлы в ~/.ssh как клиента, так и сервера

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

selinux

Какие-нибудь проблемы в /etc/pam.d/

Забыл ребутнуть sshd после указания настроек



хватит? или еще с десяток назвать?

в таких случаях обычно делают ssh -vv и вдумчиво читают простыню.

так же, зайди по паролю, и посмотри, что у тебя творится в ~/.ssh/authorized_keys

Спасибо за ответы. Вот содержание /etc/ssh/sshd_config:

http://pastebin.com/6K1RZUV0

tail /var/log/auth.log:

Dec 20 13:10:55 fileserver sshd[5578]: Did not receive identification string from 10.168.х.х

Ставил права 777 на .ssh и файлы внутри его, ситуация не меняеться..

Ставил права 777 на .ssh и файлы внутри его, ситуация не меняеться..

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

дружок, как у тебя дело обстоит с чтением букв?

ssh -vv user@remote_host
результат вдумчиво читаешь. там ответ.

с 777 всё только хуже.

avstudia# ssh -v root@10.168.x.x OpenSSH_5.2p1 FreeBSD-20090522, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to 10.168.xx [10.168.xx port 22.

debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type 1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-4ubuntu4
debug1: match: OpenSSH_5.5p1 Debian-4ubuntu4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2p1 FreeBSD-20090522
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '10.168.xx' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/identity
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
root@10.168.8.xx's password: 

Кстати, какие права лучше поставить на папку .ssh и на файлы в ней?

на локальной машине выполни ls -la /root/.ssh
так же, сравни содержимое /root/.ssh/id_rsa на локальной машине и /root/.ssh/authorized_keys на удалённой.

P.S.: да, я предлагал именно -vv, но сейчас это уже не особо важно

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

На сервере:

root@fileserver:~# ls -la .ssh
total 20
drw-------  2 root root 4096 2012-12-20 13:37 .
drwx------ 15 root root 4096 2012-12-20 09:42 ..
-rw-------  1 root root 1766 2012-12-20 13:36 id_rsa
-rw-r--r--  1 root root  397 2012-12-20 13:36 id_rsa.pub
-rw-r--r--  1 root root  442 2012-12-20 13:37 known_hosts

comp# ls -la .ssh
total 8
drwx------  2 root  wheel   512 Dec 20 13:33 .
drwxr-xr-x  7 root  wheel  1024 Dec 20 09:17 ..
-rw-r--r--  1 root  wheel   397 Dec 20 13:32 authorized_keys
-rw-r--r--  1 root  wheel   394 Dec 20 13:33 known_hosts

делал все под рутом.

при такой конфигурации у тебя будет беспарольный вход с fileserver на root@comp. тебе это надо? и именно это не работает?

drwx------ 2 root wheel 512 Dec 20 13:33 .

chgrp root

-rw-r--r-- 1 root wheel 397 Dec 20 13:32 authorized_keys

сделай 600 лучше и группу поменяй так же, как выше.

так работает. вот это я олень... Перепутал все. Тоесть ssh-keygen нужно делать на клиенте, а authorized_keys бросать на сервер?

делал все под рутом.

гугли ССЗБ

да

оу, йессс..

так работает. вот это я олень... Перепутал все. Тоесть ssh-keygen нужно делать на клиенте, а authorized_keys бросать на сервер?

да.

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

все, понял:)))) Спасибо огромное за помощь!!!

в таких случаях обычно делают ssh -vv и вдумчиво читают простыню.

И что ты увидел в его выводе ssh -v ?

И что ты увидел

многого не увидел, потому, что v было меньше задуманного ;)

Все-равно бы не увидел, сервер отлуп дал бы и объяснение клиенту не показал. Сколько раз уже проходили, пока дебаг лог в sshd не включишь ничего не увидишь

for whom how (c)...

ну-ну