пропала авторизация по ключу ssh

[Saltty]

Как вариант: проверьте права доступа к файлам ключей...

[Zeka13]

zeka@Satellite:~$ chmod 600 .ssh/authorized_keys
zeka@Satellite:~$ chmod 700 .ssh/           
zeka@Satellite:~$ ls -l .ssh/
итого 4
-rw------- 1 zeka zeka 393 окт.   7 19:45 authorized_keys
zeka@Satellite:~$ ls -l .ssh/authorized_keys
-rw------- 1 zeka zeka 393 окт.   7 19:45 .ssh/authorized_keys
zeka@Satellite:~$

[Saltty]

-rw-r--r-- 1 user user  395 2011-10-24 13:28 authorized_keys
-rw-r--r-- 1 user user 1326 2012-02-21 14:22 known_hosts

[ArcFi]

Zeka13, я бы сделал так:
1) бэкап текущего конфига openssh-server;
2) переустановка openssh-server и сброс конфига в дефолт;
3) рестарт сервиса ssh;
4) проверка конфигурации iptables;
5) проверка и установка обновлений пакетов, если есть;
6) ребут сервера.

[Zeka13]

Saltty, не понял Вас

arcfi, у меня сервер не на мастдае, а на Linux, нету способа "понять, что не работет"?. По логу совсем ничего не видно? Ну я конечно попробую мастдай способ завтра, спасибо

[ArcFi]

Zeka13, пардон, упустил из виду логирование на стороне сервера:

LogLevel
Gives the verbosity level that is used when logging messages from sshd(8 ).  The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3.

По логу совсем ничего не видно?

По логу клиента видно, что клиент доходит до метода аутентификации по ключу, отправляет ключ на сервер, сервер игнорит, и клиент переходит к следующему методу.
Причина игнора, возможно, осядет в логе сервера.

[Zeka13]

arcfi, заодно посмотрю лог сервера, сегодня погуглю как

[Saltty]

Saltty, не понял Вас

У меня права доступа отличаются от ваших и у меня все работает. Правда не факт что дело в этом...

[ii343hbka]

вообще в логах было про кривой RSA и файл ключа
Пользователь решил продолжить мысль 08 Октября 2012, 20:32:38:
аа, извиняюсь, то про RSA1


я вот всегда копировал ключ так cat ~/.ssh/id_rsa.pub | ssh user@host "cat >> ~/.ssh/authorized_keys"
Пользователь решил продолжить мысль 08 Октября 2012, 20:38:04:
вот у Вас

Код: [Выделить]

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/zeka13/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply


вот у меня

Код: [Выделить]


debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/ii343hbka/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp fb:f0:c9:6c:c7:4a:dd:b8:96:a8:83:a5:
debug3: sign_and_send_pubkey: RSA fb:f0:c9:6c:c7:4a:dd:b8:96:a8:83:a5:
debug1: Authentication succeeded (publickey).
Authenticated to alkaida.dyndns.org ([109.62.190.36]:22).
поэтому могу предположить, что косяк в конфигурации сервера


я вот еще всегда указывал

Код: [Выделить]


RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
хотя, оно, вроде, по дефолту включено и так

[Zeka13]

сделал
sudo apt-get purge openssh-server
sudo apt-get install openssh-server -y
reboot

собственно это ничего не исправило, IPTABLES на сервере
firewall.sh

(Нажмите, чтобы показать/скрыть)

#!/bin/bash
iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
#Minecraft
iptables -A INPUT -p udp -m udp --dport 25565 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 25565 -m state --state NEW -m hashlimit --hashlimit 100/s --hashlimit-burst 100 --hashlimit-mode srcip --hashlimit-name TF -j ACCEPT
iptables -A INPUT -p udp --dport 25565 -j DROP

root@Satellite:/home/zeka# iptables -L

(Нажмите, чтобы показать/скрыть)

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:25565 state RELATED,ESTABLISHED
ACCEPT     udp  --  anywhere             anywhere             udp dpt:25565 state NEW limit: up to 100/sec burst 100 mode srcip htable-expire 1
DROP       udp  --  anywhere             anywhere             udp dpt:25565

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@Satellite:/home/zeka#

IPTABLES на роутере, который раздаёт инет

(Нажмите, чтобы показать/скрыть)

#ssh туннель на Maincraft
iptables -t nat -A PREROUTING -p tcp -d 10.0.52.96 --dport 1026 -j DNAT --to-destination 192.168.1.55:22
iptables -A FORWARD -i eth0 -d 192.168.1.55 -p tcp --dport 22 -j ACCEPT

может тут собака зарыта?
хотя вроде всё нормально ...

[Zeka13]

стал смотрел лог сервера, увидел
Oct 12 05:13:46 Satellite sshd[4220]: Authentication refused: bad ownership or modes for directory /home/zeka

поставим права 700 на домашнюю папку и всё заработало 
Как всегда в Linux работает только Linux-way, всем спасибо!