Не могу зайти под root'ом (после зависания системы)

[bartram]

Система: FreeBsd 7.1
Ситуация следующая. Вчера сидя под рутом в системе, попытался динамически подгрузиться модуль ipfw к ядру, после чего система наглухо повисла. Перезагрузил комп (reset), после чего я не смог зайти под пользователем root, пишет: Access denied. Хотя под обычным пользователем я зайти могу, и su тоже работает.

auth.log

Код: Выделить всё

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

В чем может быть проблема? Как лечить?
P.S. fsck -y делал для все файловых систем
Перед перезагрузкой я ещё сменил оболочку для рута на bash, но сейчас уже вернул обратно....

[*Sasha*]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

[bartram]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

да. Раньше заходил

[*Sasha*]

На всякий случай покажи вывод cat /etc/ssh/sshd_config | grep PermitRootLogin

[AlexNT]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

да. Раньше заходил

Судя по всему произошла потеря файла sshd_config, т.е. он обнулился (по причине внезапной перезагрузки) и разрешение заходить руту более не действует.
Кстати разрешать заход рутом по ssh это несколько небезопасно и повышает риск взлома системы...

[ivan2ksusr]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

да. Раньше заходил

Судя по всему произошла потеря файла sshd_config, т.е. он обнулился (по причине внезапной перезагрузки) и разрешение заходить руту более не действует.
Кстати разрешать заход рутом по ssh это несколько небезопасно и повышает риск взлома системы...

по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута

[Shura]

ivan2ksusr
А ты всё-таки проверь

[*Sasha*]

по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута

то есть конфиг ssh сам не может измениться, а модуль pam ни с того ни с сего может заблокировать учетку рута?

[ivan2ksusr]

по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута

то есть конфиг ssh сам не может измениться, а модуль pam ни с того ни с сего может заблокировать учетку рута?

Ну да, вдруг откуда не возьмись пропала строчка из конфига PermitRootLogin(именно она) или вдруг встал # перед этой строчкой(за свою практику я не встречал такого ни разу что бы из конфига пропадали строчки, понимаю если конфиг перекалечило бы, а может быть это чьи то шаловливые ручки? :-) ), конфига я не видел, автор топика его не выложил, и даже не написал присутствует ли эта строчка или нет, в мое случае еще в конфиге была поддержка pam,я могу и ошибаться, я же написал что "может быть", у меня похожая ситуация была на FreeBSD 5.4, после жесткого ресета именно так и было то что по ssh не мог попасть из под учетки root(свет отключали, благо сервер был тестовый). Если по гуглить, то можно найти много интересных тем связанных с pam и ssh и блокировки учетки или к примеру не корректной работы модуля pam.

[AlexNT]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

да. Раньше заходил

Судя по всему произошла потеря файла sshd_config, т.е. он обнулился (по причине внезапной перезагрузки) и разрешение заходить руту более не действует.
Кстати разрешать заход рутом по ssh это несколько небезопасно и повышает риск взлома системы...

по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута

Вы уважаемый ivan2ksusr этими словами "по поводу конфига полный бред" демонстрируете лишь, как бы это сказать...
В общем вот вам скриншот если не верите. Обнулил sshd_config, запустил sshd - все прекрасно работает. Рута не пускает конечно же.
Можете попробовать самостоятельно произвести сей примитивный эксперимент.

При сбое по питанию иногда возникает ситуация обнуления открытого на запись файла...
Я всего лишь предположил что потерян sshd_config и никакого "бреда" как Вы выразились я в этом не вижу.

В логе сервера куда мы долбимся рутом, пишется именно вот это:
Jul 8 23:13:25 CRAZY1 sshd[3746]: error: PAM: authentication error for root from 200.100.0.7

[ivan2ksusr]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

да. Раньше заходил

Судя по всему произошла потеря файла sshd_config, т.е. он обнулился (по причине внезапной перезагрузки) и разрешение заходить руту более не действует.
Кстати разрешать заход рутом по ssh это несколько небезопасно и повышает риск взлома системы...

по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута

Вы уважаемый ivan2ksusr этими словами "по поводу конфига полный бред" демонстрируете лишь, как бы это сказать...
В общем вот вам скриншот если не верите. Обнулил sshd_config, запустил sshd - все прекрасно работает. Рута не пускает конечно же.
Можете попробовать самостоятельно произвести сей примитивный эксперимент.

При сбое по питанию иногда возникает ситуация обнуления открытого на запись файла...
Я всего лишь предположил что потерян sshd_config и никакого "бреда" как Вы выразились я в этом не вижу.

как есть так и говорите, завтра на работе проверю,и потом отпишу

[AlexNT]

как есть так и говорите, завтра на работе проверю,и потом отпишу

Обратите внимание я добавил что в /var/log/messages пишется:
Jul 8 23:13:25 CRAZY1 sshd[3746]: error: PAM: authentication error for root from 200.100.0.7

Что воссоздает ситуацию как у автора темы один в один.

[bartram]

Уважаемый AlexNT был прав! Действительно конфиг перезаписался. Когда открыл, конфиг был таким:

Код: Выделить всё

#    $OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $
#    $FreeBSD: src/crypto/openssh/sshd_config,v 1.47.2.2.2.1 2008/11/25 02:59:29 kensmith Exp $

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

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

# 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.

# Note that some of FreeBSD's defaults differ from OpenBSD's, and
# FreeBSD has a few additional options.

#VersionAddendum FreeBSD-20080901

#Port 22
#Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

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

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

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

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

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

# 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
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Change to yes to enable built-in password authentication.
#PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable PAM authentication
#ChallengeResponseAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'no' to disable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes

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

# no default banner path
#Banner none

# override default of no subsystems
Subsystem    sftp    /usr/libexec/sftp-server
IgnoreRhosts yes
IgnoreUserKnownHosts no
PrintMotd yes
StrictModes yes
PubkeyAuthentication yes
RSAAuthentication yes
PermitRootLogin yes
PermitEmptyPasswords no
PasswordAuthentication yes

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    ForceCommand cvs server

и ничего не работало, хотя внизу стояло незакоментированным

Код: Выделить всё

PermitRootLogin yes

Потом я вначале файла где

Код: Выделить всё

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes

Расскоментил эту строчку и все заработало.... Странно....
Всем спасибо за ответы, разобрался наконец. Но почему такой глюк с конфигом произошел не могу понять

[ivan2ksusr]

sshd[892]: error: PAM: authentication error for root from 192.168.0.100
sshd[892]: error: PAM: authentication error for root from 192.168.0.100

а в конфиге ssh разрешено рутом заходить?

да. Раньше заходил

Судя по всему произошла потеря файла sshd_config, т.е. он обнулился (по причине внезапной перезагрузки) и разрешение заходить руту более не действует.
Кстати разрешать заход рутом по ssh это несколько небезопасно и повышает риск взлома системы...

по поводу конфига полный бред, если бы слетел конфиг или как вы выразились обнулился(как это я вообще не представляю)то вообще ни кто не смог зайти, дело заключается в модуле pam который может быть блокирнул учетку рута

Вы уважаемый ivan2ksusr этими словами "по поводу конфига полный бред" демонстрируете лишь, как бы это сказать...
В общем вот вам скриншот если не верите. Обнулил sshd_config, запустил sshd - все прекрасно работает. Рута не пускает конечно же.
Можете попробовать самостоятельно произвести сей примитивный эксперимент.

При сбое по питанию иногда возникает ситуация обнуления открытого на запись файла...
Я всего лишь предположил что потерян sshd_config и никакого "бреда" как Вы выразились я в этом не вижу.

В логе сервера куда мы долбимся рутом, пишется именно вот это:
Jul 8 23:13:25 CRAZY1 sshd[3746]: error: PAM: authentication error for root from 200.100.0.7

FreeBSD g1.vifiteh 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

сделал бекап конфига и обнулил конфиг
total 142
-rw-r--r-- 1 root wheel 125811 1 ??? 2009 moduli
-rw-r--r-- 1 root wheel 1610 1 ??? 2009 ssh_config
-rw------- 1 root wheel 668 25 ??? 14:21 ssh_host_dsa_key
-rw-r--r-- 1 root wheel 605 25 ??? 14:21 ssh_host_dsa_key.pub
-rw------- 1 root wheel 530 25 ??? 14:21 ssh_host_key
-rw-r--r-- 1 root wheel 334 25 ??? 14:21 ssh_host_key.pub
-rw------- 1 root wheel 1675 25 ??? 14:21 ssh_host_rsa_key
-rw-r--r-- 1 root wheel 397 25 ??? 14:21 ssh_host_rsa_key.pub
-rw-r--r-- 1 root wheel 0 9 ??? 12:20 sshd_config
-rw-r--r-- 1 root wheel 3492 9 ??? 12:19 sshd_config.backup

Далее
делаю рестарт sshd демона
пытаемся залогинится:
mbp-nbbv:~ nb-bv$ ssh anton@192.168.0.202
далее зависон и больше ни чего)

далее делаем обратную операцию:
и получаем:
mbp-nbbv:~ nb-bv$ ssh anton@192.168.0.202
Password:
Last login: Wed Jul 8 18:43:31 2009 from 192.168.0.220
Copyright © 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.

FreeBSD 7.1-RELEASE (GENERIC) #0: Thu Jan 1 14:37:25 UTC 2009

Welcome to FreeBSD!

Before seeking technical support, please use the following resources:

o Security advisories and updated errata information for all releases are
at http://www.FreeBSD.org/releases/ - always consult the ERRATA section
for your release first as it's updated frequently.

o The Handbook and FAQ documents are at http://www.FreeBSD.org/ and,
along with the mailing lists, can be searched by going to
http://www.FreeBSD.org/search/. If the doc distribution has
been installed, they're also available formatted in /usr/share/doc.

If you still have a question or problem, please take the output of
`uname -a', along with any relevant error messages, and email it
as a question to the questions@FreeBSD.org mailing list. If you are
unfamiliar with FreeBSD's directory layout, please refer to the hier(7)
manual page. If you are not familiar with manual pages, type `man man'.

You may also use sysinstall(8) to re-enter the installation and
configuration utility. Edit /etc/motd to change this login announcement.

%

В общем итоге при 0м конфиге как в вашем случае у меня ни чего не вышло, может быть я не так что делаю. А автор топика молодец, разобрался в чем дело, но и я так же был прав, когда еще написал то что перекалечило конфиг) В общем как говорится "век живи век учись"

[AlexNT]

В общем итоге при 0м конфиге как в вашем случае у меня ни чего не вышло, может быть я не так что делаю. А автор топика молодец, разобрался в чем дело, но и я так же был прав, когда еще написал то что перекалечило конфиг) В общем как говорится "век живи век учись"

Для чистоты эксперимента проверил уже на другой машине...
Зашел с винды через putty на свою машину с обнуленным конфигом.

В вашем случае зависание происходит по причине каких то настроек со стороны клиента (ключи, аутентификация которая отличается от "по умолчанию" какие то настройки в ~/.ssh/), т.е. у вас sshd тоже запускается и работает, если вы подцепитесь клиентом с настройками по умолчанию, то у Вас нормально произойдет подключение по публичному ключу через 22 порт.
Хотя не исключено что у Вас что либо еще дополнительно настроено в отличии от меня.

А то, что произошло у автора, несколько странно... Возможно все же fsck не отработал, и файл был частично испорчен?! Новички запускают fsck как правило вручную на уже смонтированной файловой системе и игнорируют вывод (NO WRITE) и думают что проверка прошла успешно. Может в этом причина таких странностей с конфигом?

[ivan2ksusr]

А разве FreeBSD не должна ли грузиться в безопасном режиме только с / разделом? И дальше предложить выполнить проверку системы с помощью fsck? Или проверять разделы автоматически(что то я этот момент как то упустил), в solaris к примеру при таком раскладе когда сервер падает по питанию, то загружается соляра в так называем milestone режиме(кажись так, сейчас точно не помню) и дальше предлагает выполнить проверку системы, и только потом сделать рестарт ее)

(ключи, аутентификация которая отличается от "по умолчанию" какие то настройки в ~/.ssh/)

да возможно так и есть

[AlexNT]

А разве FreeBSD не должна ли грузиться в безопасном режиме только с / разделом? И дальше предложить выполнить проверку системы с помощью fsck? Или проверять разделы автоматически(что то я этот момент как то упустил), в solaris к примеру при таком раскладе когда сервер падает по питанию, то загружается соляра в так называем milestone режиме(кажись так, сейчас точно не помню) и дальше предлагает выполнить проверку системы, и только потом сделать рестарт ее)

(ключи, аутентификация которая отличается от "по умолчанию" какие то настройки в ~/.ssh/)

да возможно так и есть

Если я не ошибаюсь, то система в так называемом безопасном режиме грузиться не будет, если монтирование разделов хоть как то проходит (после единичного сбоя питания допустим) если же ничего толком не смонтируется из за сбоев (фактически невозможно прочитать системные области разделов из за сбоев, при монтировании ), тогда система выпадет в однопользовательском режиме, где и можно будет провести проверку.

По умолчанию в FreeBSD fsck отрабатывает в фоне, что лично для меня крайне неприятно. Поэтому в rc.conf у меня:
fsck_y_enable="YES"
background_fsck="NO"
Что включает возможность автоматической проверки дисков при старте системы только если разделы отмонтировались некорректно (допустим при внезапном откл. питания) и исключает запуск fsck в фоне на работающей системе.

Если же запустить fsck -y в обычном рабочем режиме на уже смонтированных фс, то проверка пройдет но ошибки исправлены не будут.

[KiWi]

пытаемся залогинится:
mbp-nbbv:~ nb-bv$ ssh anton@192.168.0.202
далее зависон и больше ни чего)

А подождать пару минут?

[ivan2ksusr]

fsck_y_enable="YES"
background_fsck="NO"

вот это полезно будет

Если же запустить fsck -y в обычном рабочем режиме на уже смонтированных фс, то проверка пройдет но ошибки исправлены не будут.

Это понятно и так) хотя не многие знаю об этом

[ivan2ksusr]

пытаемся залогинится:
mbp-nbbv:~ nb-bv$ ssh anton@192.168.0.202
далее зависон и больше ни чего)

А подождать пару минут?

дальше connect timeout и все