LINUX.ORG.RU
ФорумAdmin

не логинится root через ssh, а через su - ok

 


0

2

почему если зайти по ssh юзером и потом su, то всё ок
а если напрямую через ssh root@1.2.3.4, то «Permission denied»...

в логах это:

Jun 16 11:39:08 asterisk sshd[11166]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.56  user=root
Jun 16 11:39:08 asterisk sshd[11166]: pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
Jun 16 11:39:10 asterisk sshd[11166]: Failed password for root from 192.168.1.56 port 50128 ssh2

что ещё за uid >= 1000


Потому что настроено либо в конфиге sshd либо средствами pam для sshd ограничение разрешающее авторизовываться через ssh пользователям чей uid больше или равен 1000.

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

Дистрибутив укажи.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 2)
Ответ на: комментарий от tip78

я с рута лезу…

И что?

граничение разрешающее авторизовываться через ssh пользователям чей uid больше или равен 1000.

Что тебе не понятно в этом предложении?

У root uid = 0, 0 меньше 1000. В условие не попадает.

По умолчанию в sshd разрешена авторизация root только по ключам.

grep 1000 /etc/pam.d -Rnl
kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 2)
Ответ на: комментарий от kostik87

в /etc/pam.d на удалённом хосте:

grep succeed *

fingerprint-auth:account     sufficient    pam_succeed_if.so uid < 1000 quiet
fingerprint-auth:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
fingerprint-auth-ac:account     sufficient    pam_succeed_if.so uid < 1000 quiet
fingerprint-auth-ac:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
password-auth:auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
password-auth:account     sufficient    pam_succeed_if.so uid < 1000 quiet
password-auth:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
password-auth-ac:auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
password-auth-ac:account     sufficient    pam_succeed_if.so uid < 1000 quiet
password-auth-ac:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
postlogin:session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet
postlogin-ac:session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet
smartcard-auth:account     sufficient    pam_succeed_if.so uid < 1000 quiet
smartcard-auth:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
smartcard-auth-ac:account     sufficient    pam_succeed_if.so uid < 1000 quiet
smartcard-auth-ac:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
su:account              sufficient      pam_succeed_if.so uid = 0 use_uid quiet
system-auth:auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
system-auth:account     sufficient    pam_succeed_if.so uid < 1000 quiet
system-auth:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
system-auth-ac:auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
system-auth-ac:account     sufficient    pam_succeed_if.so uid < 1000 quiet
system-auth-ac:session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

tip78
() автор топика
Последнее исправление: tip78 (всего исправлений: 1)
Ответ на: комментарий от tip78
Failed password for root from 192.168.1.56 port 50128 ssh2

Повторяю, по умолчанию в конфигурационном файле /etc/ssh/sshd_config отсутствует опция ‘PermitRootLogin yes’, разрешающая автризовываться под root по паролю.

Без этой опции разрешена авторизация под root только по ключам.

А ты как раз авторизовываешься через ввод пароля.

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

Включи опцию разрешающую авторизовываться по паролю для пользователя root, а лучше авторизовывайся по ssh ключам.

kostik87 ★★★★★
()
21 июля 2022 г.
Ответ на: комментарий от kostik87

чё-то опять эта херня приключилась
причём даже su не пускает на рута...
юзер с рутовыми правами может залезть, но и то почему-то через раз... (из дома удалённо через сервер залезть не смог, а из офиса локально могу), но su ему не даёт
а рут вообще никак не лезет...
при этом каждую ночь туда лазает скрипт через scp по этому рутовуму паролю

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

по ключу рута пустило
хотя Permit включён, но по паролю БЕЗ ключа теперь не пускает, а раньше пускало

tip78
() автор топика
Последнее исправление: tip78 (всего исправлений: 1)
Ответ на: комментарий от tip78
     PermitRootLogin
             Specifies whether root can log in using ssh(1).  The argument must be yes, prohibit-password,
             forced-commands-only, or no.  The default is prohibit-password.

             If this option is set to prohibit-password (or its deprecated alias, without-password), password and
             keyboard-interactive authentication are disabled for root.

             If this option is set to forced-commands-only, root login with public key authentication will be
             allowed, but only if the command option has been specified (which may be useful for taking remote
             backups even if root login is normally not allowed).  All other authentication methods are disabled
             for root.

             If this option is set to no, root is not allowed to log in.
vbr ★★★
()
Ответ на: комментарий от anc

я его всегда отключаю
если у них в дистрибутиве он есть, то он может решать про запрет рута в ssh БЕЗ ключа?

tip78
() автор топика
Последнее исправление: tip78 (всего исправлений: 1)
Ответ на: комментарий от pfg

в ssh заходить по ключу жутко удобно

весьма... очень весьма относительно.

и более секурно.

orly ?
1. ключ в голове не помещается.
2. следствие пункта 1. его надо хранить на носителе
3. с носителя он может «уплыть» в недобрые руки

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от tip78

ключ хранишь в бекапах. енто ж просто маленький файл.
по идее, на каждой машине с линуксом для каждого пользователя есть свой уникальный ключ. открытую часть ключа прописываешь на сервер в /home/%user%/.ssh/authorized_keys и таким образом можешь на сервере регулировать доступ каждого пользователя.
стандартно добавлю, что заходить в root не надо, лучше пользоваться sudo из-под обычного пользователя.

pfg ★★★★★
()
Ответ на: комментарий от anc
  1. пароль нормального размера хранить в голове сложно. с уникальностью обычно тоже очень трудно. пароль обычно это максимум десяток символов осмысленного текста, которые достаточно быстро перебираются.
  2. ключ один для каждого пользователя каждой машины. его не надо с собой носить, для подключение каждого пользователя ключ надо прописывать в authorized_keys целевой машины. и по окончанию допуска оттуда удалять
  3. ректальный термокриптоанализатор сделает такое и с обычным паролем.
pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 2)
Ответ на: комментарий от pfg

пароль обычно это максимум десяток символов осмысленного текста, которые достаточно быстро перебираются.
десяток символов
максимум

Ппц... где мои 16 лет...
С

осмысленного

согласен. Только есть нюанс в определении «осмысленный», мой пароль для вас покажется полным бредом и не будет даже отдаленно предполагать наличие какого-то смысла, а он есть :)

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

очень рад за тебя, умение запоминать длинные строки произвольных буковок весьма пользительно в современном мире бессмысленных данных :)
и, как думаешь, сколько таких на мильёны паролей 1234567890 ??

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

и, как думаешь, сколько таких на мильёны паролей 1234567890 ??

проблемы индейцев идиотус, шерифа меня не волнуют. Вы бы ещё сказали, сколько мамашек с колясками мкад переходят. Да-да, я своими глазами видел парочку таких, через разделитель пересекали, одно с детём лезло, другое коляску перекидывало.
ЗЫ Вспомнил несколько личных паролей пользаков, умеют учится, сами пароли вполне осмысленны, но! но блинааа фиг подберешь не зная человека :) оно имеет смысл только для него и при этом приправлено рандомом. :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от pfg

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

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

а в данном случае на этот centos ходит ещё и тех.поддержка по впн через ссх

tip78
() автор топика
Последнее исправление: tip78 (всего исправлений: 2)
Ответ на: комментарий от tip78

где даёт раз в 3 сек воткнуть пробу

Корень проблемы newfags, верят в то что «оно даёт» и отмеряют от этого как от эталона. А то что «оно даёт» таще-то сильно разное, мозг не включают, они же в одной реализации увидели что оно так... значит ну вот точно везде так...
«Я увидел кучу зеленых елок» значит не могут они(елки) быть «голубыми». Аналогия понятна?

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

ну вы то, как олдфаг, конечно выдернете /etc/passwd (вместе с диском) и зарашите его по миллиарду проб в сек - базару ноль, верю в вас
или для вас какой-то порт специальный открыт, где висит нечто как раз для брутфорса

селинуха там нет, кстати, так что загадка становится всё загадочнее

tip78
() автор топика
Последнее исправление: tip78 (всего исправлений: 2)
Ответ на: комментарий от tip78

ну вы то, как олдфаг, конечно выдернете /etc/passwd

мда, молодеж не только не способна в «читать», но ещё и способна на «фантастические произведения». Для не очень остроумных поясню, /etc/passwd потерял актуальность ещё в прошлом тысячелетии с появлением shadow.

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

а что ж ЧСВ до сих пор не отрастил, на форумах добираешь )

в общем, ломайте пароли хоть через shadow, а вариант с русскими словами всё равно насуёт палок не хуже, чем просто набор букв
только запомнить его проще

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

а вариант с русскими словами всё равно насуёт палок не хуже, чем просто набор букв

Это плюс 33 символа. Не сильно напряжно.
ЗЫ Брутфорс не сильно напряжное занятие, рекомендую в качестве факультатива погонять в эту «гамку», что бы развеялись «мифические мысли» рождаемые только прочитанным в этих ваших интернетах. Это без всяких подколов, правда попробуйте.
ЗЫЫ И если вы вдруг не в курсе, то полученный пасс скорее всего не будет соответствовать именно вашему паролю, но не пугайтесь, он подойдет :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от tip78

еще и с планшета, и на телефон доступ поставлен.
да пусть хоть кто ходит, хоть с сотни машин :)
коль потеряю телефон - залезу на сервер, удалю соответствующий открытый ключ из авторизированных и ок.
о вскрытиях ssh методом подбором, даже считающегося уже устаревающим, 4к-RSA ключа чегойто даже не слышал.

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

в локальной сети и телнета хватит.

разве что в этой локальной сети кроме вас и вашего кота больше никто не обитает.
Но плюс телнета уже описывал. При определенных условиях робит с «отсутствующим»(отправившемся в лучший мир, где все харды без бэдблоков) хардом, sshd так не умеет. :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от tip78

Тебе выше кинули кусок мана, там:

PermitRootLogin

If this option is set to prohibit-password (or its deprecated alias, without-password), password and keyboard-interactive authentication are disabled for root.

Соответственно есть подозрения, что твой sshd поднимается с конфигом, в котором стоит prohibit-password.

Неужели так сложно ps ax | grep sshd или systemctl status sshd сделать, вместо того, чтобы гадать?

agentgoblin
()