На старом серваке настроен SSH. Работает. Переношу на новый сервак sshd_config. Не работает. В PUTTY выдает: Server refused our public key.
Межет знает кто-нибудь, в чем дело?

Suse 8.1
sshd_config:
#    $OpenBSD: sshd_config,v 1.42 2001/09/20 20:57:51 mouring Exp $

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# This is the sshd server system-wide configuration file.  See sshd(8)
# for more information.

Port 4333
#Protocol 2,1
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO
#obsoletes QuietMode and FascistLogging

# Authentication:

LoginGraceTime 600
PermitRootLogin no
StrictModes yes

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

# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
ChallengeResponseAuthentication no

# Uncomment to enable PAM keyboard-interactive authentication
# Warning: enabling this may bypass the setting of 'PasswordAuthentication'
#PAMAuthenticationViaKbdInt yes

# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

#X11Forwarding yes
#X11DisplayOffset 10
PrintMotd yes
#PrintLastLog no
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

#Subsystem    sftp    /usr/lib/ssh/sftp-server

• Наcтройка SSH,akeeper, 23:19 , 03-Авг-03
• Наcтройка SSH,lavr, 11:20 , 04-Авг-03
  • Наcтройка SSH,Nik, 11:43 , 04-Авг-03
    • Наcтройка SSH,lavr, 12:45 , 04-Авг-03
      • Наcтройка SSH,Zorro, 04:42 , 11-Авг-03

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

wbr, akeeper.

>На старом серваке настроен SSH. Работает. Переношу на новый сервак sshd_config. Не
>работает. В PUTTY выдает: Server refused our public key.
>Межет знает кто-нибудь, в чем дело?

голова дана человеку чтобы думать, читать, учиться, и переводы есть
и руководства - читай не хочу:

http://unix1.jinr.ru/~lavr/

>>На старом серваке настроен SSH. Работает. Переношу на новый сервак sshd_config. Не
>>работает. В PUTTY выдает: Server refused our public key.
>>Межет знает кто-нибудь, в чем дело?
>
>голова дана человеку чтобы думать, читать, учиться, и переводы есть
>и руководства - читай не хочу:
>
>http://unix1.jinr.ru/~lavr/

Уважаемый lavr! Полностью с Вами согласен по поводу головы, но все эти переводы и руководства на Вашей страничке уже зачитаны до дыр... (

>>>На старом серваке настроен SSH. Работает. Переношу на новый сервак sshd_config. Не
>>>работает. В PUTTY выдает: Server refused our public key.
>>>Межет знает кто-нибудь, в чем дело?
>>
>>голова дана человеку чтобы думать, читать, учиться, и переводы есть
>>и руководства - читай не хочу:
>>
>>http://unix1.jinr.ru/~lavr/
>
>
>Уважаемый lavr! Полностью с Вами согласен по поводу головы, но все эти
>переводы и руководства на Вашей страничке уже зачитаны до дыр... (
>

http://unix1.jinr.ru/~lavr/lavr_ssh.html - здесь описано ВСЕ что нужно,
хоть и писалось для SSH-Protocol-1, тем не менее там черным по белому
есть про технологию и про КЛЮЧИ ХОСТОВ, которые генерятся как и ключи
пользователей, SSH пытается выполнить ВСЕ технологически доступные проверки аутентикации, сверка ключей, проверка соответствия hostname <-> ip (DNS, соответственно и проверка-сравнение ключей в known_hosts) и тд
и тп, после проверок клиент-сервер для хостов, идет проверка всевозможных
авторизаций пользователя.

http://unix1.jinr.ru/~lavr/lavr-ssh.1.txt

Возможно там и нет КОНКРЕТНО про генерацию ключей для хостов, но косвенно,
она точно присутствует и потом man sshd (раздел SSH_KNOWN_HOSTS FILE FORMAT):

ssh-keygen -t типключа -f /путь/ssh_host_типключа -N ""

типключа: rsa, dsa для SSH2, rsa1 для SSH1, итого генерим все нужные
ключи для хоста:

SSH1:
-----
ssh-keygen -t rsa1 -f /path/ssh_host_key -N "" (получаем приватный и публичный ключи хоста)
и тд и тп.

SSH2:
-----
ssh-keygen -t rsa -f /path/ssh_host_rsa_key -N ""
ssh-keygen -t dsa -f /path/ssh_host_dsa_key -N ""

Все верхнее справедливо для OpenSSH (Коммерческий не рассматривается по
известным причинам).

Обычные правила:

- производим upgrade OpenSSH, просто сохраняем /path/ssh_host_* - приватные и публичные ключи и используем ИХ ЖЕ после upgrade'а чтобы
клиенты работали с теми же известными ключами

- производим upgrade или перенос сервера, так как одна из авторизаций на
уровне хостов, сохраняем и переносим ключи хоста

прим: понятно что одновременно два сервера НЕ МОГУТ иметь одинаковых
ключей, в случае если мы забыли про ключи хостов, придется их вычишать
из собранных в локалке(плюс к ним доверительных) ssh_known_hosts или
на уровне пользователей из своих known_hosts.

>>>>На старом серваке настроен SSH. Работает. Переношу на новый сервак sshd_config. Не
>>>>работает. В PUTTY выдает: Server refused our public key.
>>>>Межет знает кто-нибудь, в чем дело?
>>>
>>>голова дана человеку чтобы думать, читать, учиться, и переводы есть
>>>и руководства - читай не хочу:
>>>
>>>http://unix1.jinr.ru/~lavr/
>>
>>
>>Уважаемый lavr! Полностью с Вами согласен по поводу головы, но все эти
>>переводы и руководства на Вашей страничке уже зачитаны до дыр... (
>>
>
>http://unix1.jinr.ru/~lavr/lavr_ssh.html - здесь описано ВСЕ что нужно,
>хоть и писалось для SSH-Protocol-1, тем не менее там черным по белому
>
>есть про технологию и про КЛЮЧИ ХОСТОВ, которые генерятся как и ключи
>
>пользователей, SSH пытается выполнить ВСЕ технологически доступные проверки аутентикации, сверка ключей, проверка соответствия hostname <-> ip (DNS, соответственно и проверка-сравнение ключей в known_hosts) и тд
>и тп, после проверок клиент-сервер для хостов, идет проверка всевозможных
>авторизаций пользователя.
>
>http://unix1.jinr.ru/~lavr/lavr-ssh.1.txt
>
>Возможно там и нет КОНКРЕТНО про генерацию ключей для хостов, но косвенно,
>
>она точно присутствует и потом man sshd (раздел SSH_KNOWN_HOSTS FILE FORMAT):
>
>ssh-keygen -t типключа -f /путь/ssh_host_типключа -N ""
>
>типключа: rsa, dsa для SSH2, rsa1 для SSH1, итого генерим все нужные
>
>ключи для хоста:
>
>SSH1:
>-----
>ssh-keygen -t rsa1 -f /path/ssh_host_key -N "" (получаем приватный и публичный ключи
>хоста)
>и тд и тп.
>
>SSH2:
>-----
>ssh-keygen -t rsa -f /path/ssh_host_rsa_key -N ""
>ssh-keygen -t dsa -f /path/ssh_host_dsa_key -N ""
>
>Все верхнее справедливо для OpenSSH (Коммерческий не рассматривается по
>известным причинам).
>
>Обычные правила:
>
>- производим upgrade OpenSSH, просто сохраняем /path/ssh_host_* - приватные и публичные ключи
>и используем ИХ ЖЕ после upgrade'а чтобы
>клиенты работали с теми же известными ключами
>
>- производим upgrade или перенос сервера, так как одна из авторизаций на
>
>уровне хостов, сохраняем и переносим ключи хоста
>
>прим: понятно что одновременно два сервера НЕ МОГУТ иметь одинаковых
>ключей, в случае если мы забыли про ключи хостов, придется их вычишать
>
>из собранных в локалке(плюс к ним доверительных) ssh_known_hosts или
>на уровне пользователей из своих known_hosts.

Положи куданить все SSH ключи и покажи Putty где они лежат... вот в принципе и все... я сам пользуюсь Putty ... оч удобный клиент..
С уважением  Zorro ...