LINUX.ORG.RU
ФорумAdmin

не логинется по ssh под пользователем


0

0

Сервер настроен, чтобы всех пускать.
делаю под рутом:
# ssh server
говорит:
Are you want to continue connecting (yes/no)?
и дальше всё логинется и всё работает без проблем.
Если же то же делаю под пользователем (любым):
# ssh server
Говорит:
Host key verification failed.
И всё.
Я уже и по публичному ключу пробовал (ложил ручками на сервер) - всё равно не работет с этой машины. (та же ошибка) С других нормально - и под пользователем и под рутом и с разной аутентификацией.

В чём трабла?

Либо почисти ~/.ssh/known_hosts, либо поменяй настройку StrictHostKeyChecking в конфигурации ssh. Смотри man ssh_config

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

known_hosts чистил. StrictHostKeyChecking поменял в no
В результате:
Но начало вываливаться другое сообщение:
Warning: Permanently added 'server,10.0.0.5' (RSA) to the list of known hosts.
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password,keyboard-interactive,hostbased).

При этом с этой машины под рутом на server логинется, при всех вариантах, которые я пробовал с настройками ssh_config

P.S: почему root может зайти без проблем, а остальным нельзя? Учитывая, что с других машин, повторюсь, на этих пользователей на сервере удалённо все логинятся. Т.е. сеть настроена правильно, ник-то ничего не рубит - проблема в клиенте получается.

progserega
() автор топика
Ответ на: комментарий от progserega

т.е. в known_hosts добавляется, но всё равно не логинется под пользователем. Под рутом - всё нормально.

progserega
() автор топика
Ответ на: комментарий от progserega

> Warning: Permanently added 'server,10.0.0.5' (RSA) to the list of known hosts.
> Permission denied, please try again.
> Permission denied, please try again.
> Permission denied (publickey,password,keyboard-interactive,hostbased).

Неужели это сообщение не наводит на кое какие мысли о ~/.ssh/known_hosts ?

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

Не root. Кто владелец этого файла у автора темы не знаю, но сомневаюсь, что root.

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

Ну, во-первых я написл выше:
> т.е. в known_hosts добавляется, но всё равно не логинется под пользователем.

Т.е. всё там в порядке.
Ради достоверности выносил ~/.ssh/* и пытался опять коннектиться к серверу.
После вышеописанных сообщений об ошибке, делаю:
# ls -l ~/.ssh/
получаем:
-rw-r--r-- 1 Serega Serega 224 Апр 19 17:50 known_hosts

Очистку настроек я в первую очередь попробовал. Если бы всё было так просто...

progserega
() автор топика
Ответ на: комментарий от bbk123

Конфиг клиентской машины (ssh_config):
-rw-r--r-- 1 root root 1292 Апр 19 14:38 ssh_config

# ssh_config(5) for more information. This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

# Host *
# ForwardAgent no
# ForwardX11 no
# RhostsAuthentication no
RhostsAuthentication yes
# RhostsRSAAuthentication no
RhostsRSAAuthentication yes
# RSAAuthentication yes
# PasswordAuthentication yes
PasswordAuthentication yes
# HostbasedAuthentication no
HostbasedAuthentication yes
# BatchMode no
# CheckHostIP yes
# StrictHostKeyChecking ask
StrictHostKeyChecking no
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~

Конфиг сервера:
-rw-r--r-- 1 root root 2525 Apr 19 14:43 sshd_config

# $OpenBSD: sshd_config,v 1.65 2003/08/28 12:54:34 markus Exp $

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

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

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#AllowUsers Serega@Serega root@Serega
Port 22
Protocol 2,1
#ListenAddress 10.0.0.1
#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 1h
#ServerKeyBits 768

# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes

RSAAuthentication yes
PubkeyAuthentication no
AuthorizedKeysFile .ssh/authorized_keys

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

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

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCreds yes

# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM no

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#KeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
#Subsystem sftp /usr/libexec/openssh/sftp-server

progserega
() автор топика
Ответ на: комментарий от progserega

На сервере замени yes -> no

HostbasedAuthentication yes

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

# HostbasedAuthentication no

HostbasedAuthentication yes

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

Возможно ему нужна именно host based authentication. Чтобы она работала и в случае, когда клиент запускается не root-ом, видимо нужно добавить "EnableSSHKeysign yes" в конфигурацию клиента.

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

У клиента сделал:
HostbasedAuthentication no
# HostbasedAuthentication yes

На сервере сделал:
HostbasedAuthentication no

Результат тот же.

Переустановил openssh openssl openssl-solibs (думал, может побились файлы...). Ноль реакции.
На соседней машине ssh_config полностью состоит из комментов, очистил там ~/.ssh/ и нормально логинится на сервер.
На испытуемой же машине тоже пробую закомменченный конфиг с чистой дирректорией ~/.ssh/ вываливется бага.
Логиниться пытаюсь на одного и того же пользователя.
Ради чистоты экспиремента очистил ~/.ssh/ для пользователя, на которого логинюсь на стороне сервера.
Тот же результат.

При этом, повторюсь, если с испытуемой машины пытаться логинится из под рута на рутовский аакаунт сервера - то всё нормально работает.
Мистика какая-то.

P.S.
Сервер - debian-sarge,
клиент, который логинится нормально - slackware 10.0
клиент, который не хочет логиниться на пользовательские аккаунты - slackware 9.0

progserega
() автор топика
Ответ на: комментарий от bbk123

ssh ругается на EnableSSHKeysign в конфиге. Посмотрел в мане - нет такой опции в версии ssh в девятой слаквари. В 10-й слаквари в мане такая опция есть.
Сейчас попробую ssh от десятого поставить на 9-ю слакварь. Может быть клиент староват для сервера?

progserega
() автор топика
Ответ на: комментарий от bbk123

Более детальная информация:
#ssh server -v
вывод:
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to dasha [10.0.0.5] port 22.
debug1: Connection established.
debug1: identity file /home/Serega//.ssh/identity type -1
debug1: identity file /home/Serega//.ssh/id_rsa type 1
debug1: identity file /home/Serega//.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1 Debian-8.sarge.4
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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 'dasha' is known and matches the RSA host key.
debug1: Found key in /home/Serega//.ssh/known_hosts:1
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: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: password
debug1: Authentications that can continue: password,keyboard-interactive
Permission denied, please try again.
debug1: Authentications that can continue: password,keyboard-interactive
Permission denied, please try again.
debug1: Authentications that can continue: password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (password,keyboard-interactive).


При логировании от рута:

Последние строки:
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: password,keyboard-interactive
debug1: Next authentication method: password
root@server's password:

Ясно что где-то нет доступа, но где и кому?!

progserega
() автор топика
Ответ на: комментарий от progserega

первый пример - залогинивание пользователея, - неудачное.
второй - от рута - удачное.

P.S. обновление openssl, openssl-solibs, openssh - не помогло. :-(

progserega
() автор топика
Ответ на: комментарий от progserega

># Port 22

># Protocol 2,1

># Cipher 3des

># Ciphers s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

Почему у тебя закомментированны строки с портом и протоколом?

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

Всё по дефолту
На соседней машине так же - всё работает по дефолту.

progserega
() автор топика
Ответ на: комментарий от VPF

Фактически, ключевой момент в том, почему под рутом работает, а под пользоватлелем нет?
Такая ситуация говорит о том, что по части сети, протокола, алгоритмов шифрования - всё нормально.

progserega
() автор топика
Ответ на: комментарий от progserega

И мы возвращаемся к этому:

     /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key,
             /etc/ssh/ssh_host_rsa_key
             These three files contain the private parts of the host keys and
             are used for RhostsRSAAuthentication and HostbasedAuthentication.
             If the protocol version 1 RhostsRSAAuthentication method is used,
             ssh must be setuid root, since the host key is readable only by
             root.  For protocol version 2, ssh uses ssh-keysign(8) to access
             the host keys for HostbasedAuthentication.  This eliminates the
             requirement that ssh be setuid root when that authentication
             method is used.  By default ssh is not setuid root.

Тоесть к "EnableSSHKeysign yes" или установке ssh с setuid root.

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

> Сейчас попробую ssh от десятого поставить на 9-ю слакварь.

Ты чо, дурень? Даже не думай так делать.

Deleted
()

> bbk123 * (*) (19.04.2006 15:30:56)

Видимо то, что нужно:

#/etc/ssh/ssh_host_key

#/etc/ssh/ssh_host_dsa_key

#/etc/ssh/ssh_host_rsa_key

EnableSSHKeysign yes

Раскомментируй приведённые строки, а последнюю просто добавь

VPF
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.