Error received null username or password for unpwd check - Исправление ошибок и поиск оптимальных решений проблем

Describe the issue you are experiencing

Fresh new installation of HA.
Supervisor 2022.08.3
Operating System 8.4

The first and the only addon installed is Mosquitto broker.

It does not matter if I’m configuring it with or without username & password in settings.
It does not matter if I have other user in HA & typing his logon details in addon config.
It does not matter if I configuring ACL for mosquitto.

Every 5 seconds have same line in log of the broker:
Client disconnected, not authorised.
New connection from 172.30.32.1:49688 on port 1883.

Always same thig just different source port number.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

Mosquitto broker

What is the version of the add-on?

6.1.2

Steps to reproduce the issue

Install Home Assistant OS
Create user for the first run
Install add-on
Run add-on without config
After few seconds starting receive a error message in log.

Also tried one more fresh install of HaOS.

Install Home Assistant OS
Create user for the first run
Install add-on
Config username and password in add-on
Run add-on
After few seconds starting receive a error message in log.
…

Anything in the Supervisor logs that might be useful for us?

Anything in the add-on logs that might be useful for us?

1661014441: New connection from 172.30.32.1:46798 on port 1883.
error: received null username or password for unpwd check
1661014441: Client <unknown> disconnected, not authorised.
1661014446: New connection from 172.30.32.1:60876 on port 1883.
error: received null username or password for unpwd check
1661014446: Client <unknown> disconnected, not authorised.
1661014451: New connection from 172.30.32.1:60882 on port 1883.
error: received null username or password for unpwd check
1661014451: Client <unknown> disconnected, not authorised.
1661014456: New connection from 172.30.32.1:43568 on port 1883.
error: received null username or password for unpwd check
1661014456: Client <unknown> disconnected, not authorised.
1661014461: New connection from 172.30.32.1:43576 on port 1883.
error: received null username or password for unpwd check
1661014461: Client <unknown> disconnected, not authorised.
1661014466: New connection from 172.30.32.1:56066 on port 1883.
error: received null username or password for unpwd check
1661014466: Client <unknown> disconnected, not authorised.
1661014471: New connection from 172.30.32.1:56072 on port 1883.
error: received null username or password for unpwd check
1661014471: Client <unknown> disconnected, not authorised.
1661014476: New connection from 172.30.32.1:55242 on port 1883.
error: received null username or password for unpwd check
1661014476: Client <unknown> disconnected, not authorised.
1661014481: New connection from 172.30.32.1:55250 on port 1883.
error: received null username or password for unpwd check
1661014481: Client <unknown> disconnected, not authorised.
1661014486: New connection from 172.30.32.1:39940 on port 1883.
error: received null username or password for unpwd check

Additional information

after checking issue, the source IP is the docker gateway address.
HaOS installed on VM running on windows pc

Источник

after updating HA to 2022.10.1 my zigbee devices acting strange. i get this error in my MQTT broker

2022-10-08 10:20:50: Client <unknown> disconnected, not authorised.
2022-10-08 10:20:55: New connection from 172.30.32.1:47652 on port 1883.
error: received null username or password for unpwd check
2022-10-08 10:20:55: Client <unknown> disconnected, not authorised.
2022-10-08 10:20:56: Client nodered_66435ef5e245f9ac disconnected.
2022-10-08 10:20:57: New connection from 192.168.1.47:33488 on port 1883.
2022-10-08 10:20:57: New client connected from 192.168.1.47:33488 as NODE RED (p2, c1, k60, u'MQTT').
2022-10-08 10:21:00: New connection from 172.30.32.1:47664 on port 1883.
error: received null username or password for unpwd check
2022-10-08 10:21:00: Client <unknown> disconnected, not authorised.
2022-10-08 10:21:05: New connection from 172.30.32.1:57232 on port 1883.
error: received null username or password for unpwd check
2022-10-08 10:21:05: Client <unknown> disconnected, not authorised.
2022-10-08 10:21:10: New connection from 172.30.32.1:57246 on port 1883.
error: received null username or password for unpwd check

and i think is also the reason my Node red is not working

8 Oct 10:21:41 - [red] Uncaught Exception:
8 Oct 10:21:41 - [error] UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "#<Object>".
[10:21:41] WARNING: Node-RED crashed, halting add-on
[10:21:41] INFO: Node-RED stopped, restarting...
s6-rc: info: service legacy-services: stopping
[10:21:42] INFO: Node-RED stopped, restarting...
s6-svwait: fatal: supervisor died
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
[10:21:42] INFO: nginx stopped, restarting...
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

How do i fix the username or password for unpwd check? i have password in my Node red mqtt broker settings

Источник

Message Queuing Telemetry Transport is een protocol waarmee gegevens tussen IoT devices kunnen worden uitgewisseld. Het is ontworpen voor verbinding met externe locaties waar een “kleine code footprint” wordt vereist. Externe locaties hebben vaak geen stroomvoorziening of snelle internetverbinding. De dataoverdracht moet dus efficiënt, energiezuinig en betrouwbaar zijn. Het MQTT protocol is om deze reden ook zeer geschikt voor domotica toepassingen omdat deze ook uit veel sensoren met batterijen bestaat.

Er bestaat twee verschillende apparaten namelijk:

MQTT Client
MQTT Broker of Message Broker

De broker zorgt voor de verwerking van berichten. Clients kunnen berichten naar een broker sturen onder een bepaald topic (onderwerp). Dit kan bijvoorbeeld de temperatuur zijn of het energieverbruik van de Smart Gateways slimme meter WiFi gateway:

Slimme meter wifi gateway met display

Slimme meter wifi gateway

Andere clients kunnen zich abonneren op een topic om de data uit te lezen. Dit kan bijvoorbeeld Home Assistant zijn die de sensordata verder verwerkt. MQTT gebruikt voor het versturen van data twee poorten, namelijk tcp/1883 voor clear-text en tcp/8883 voor versleutelde berichten via TLS (Transport Layer Security). Aanmelden op de server kan anoniem, met een gebruikersnaam en wachtwoord of met client certificaten. Het vaakst wordt hiervoor een gebruikersnaam en wachtwoord gebruikt.

Een MQTT server kan op een aparte server worden geïnstalleerd of in de cloud. Binnen Home Assistant wordt de MQTT broker vaak geïnstalleerd op de Home Assistant server zelf. De software die hiervoor het meest geschikt is is de Mosquitto MQTT Broker van Eclipse. Hierna volgt een stap instructie hoe de Mosquitto MQTT Broker binnen Home Assistant geïnstalleerd kan worden.

Installatie van Mosquitto MQTT Broker binnen Home Assistant

Home Assistant biedt standaard een integratie van Mosquitto die eenvoudig geïnstalleerd kan worden. Hiervoor is het nodig om eerst een gebruiker aan te maken die de Mosquitto service kan gebruiken om gegevens uit te wisselen binnen Home Assistant. De Mosquitto gebruiker is een normale gebruiker zoals alle andere gebruikers.

Aanmaken Mosquitto gebruiker

Klik binnen Home Assistant op Instellingen -> Gebruikers -> Add User. De naam en gebruikersnaam mogen hetzelfde zijn. Vul het wachtwoord in en bevestig het wachtwoord. De gebruiker hoeft geen beheerder te zijn.

Selecteer nu Maken. De Mosquitto gebruiker is nu aangemaakt.

Installeren van de Mosquitto Broker Add-on

Je kunt nu verder met de installatie van de Mosquitto broker Add-on. Ga hiervoor naar Supervisor -> Add-on Store en zoek op Mosquitto broker.

Selecteer nu INSTALL en wacht tot de installatie voltooid is.

Zet vervolgens “Start on boot”, “Watchdog” en “Auto update” aan. Druk nog niet op START, er moeten eerst nog wat instellingen worden gedaan.

Configureren van Mosquitto MQTT Broker

Voordat de MQTT broker gebruikt kan worden dient deze eerst nog te worden voorzien van configuratie. Selecteer hiervoor Configuration in het menu boven in de browser. Het volgende scherm wordt weergegeven:

Vul nu bij username: en password: de gebruikersnaam en het wachtwoord in die eerder zijn aangemaakt. Klik vervolgens op SAVE.

De MQTT broker kan nu gestart worden door op het Info scherm op START te klikken.

MQTT Logging controleren

Mosquitto houdt een logbestand bij. Deze kan via het Log tabblad ingezien worden. Deze zou er ongeveer uit moeten zien zoals in onderstaande schermafbeelding.

Clients instellen

De installatie is nu voltooid. Nieuwe clients kunnen data versturen door gebruik te maken van de volgende gegevens:

mqtt server: ip adres van de mqtt server (in veel gevallen het ip adres van het systeem waar Home Assistant op draait)

mqtt port: 1883

mqtt user: mosquitto

mqtt password: <wachtwoord van de mosquitto gebruiker>

Probeer ook eens deze Zigbee led dimmer die geschikt is voor alle A-merken afdekmateriaal. Een bijkomend voordeel is dat deze gebruikt kan worden met 2 draden, dus geen nuldraad of bypass vereist.

Источник

11.04.2022

Добрый день.

Подскажите в чем может быть проблема, накатываю свежую систему на ПК, ядро generic, ставлю по инструкции sssd, ввожу в домен, пишет что все успешно, перезагружаю ПК и пытаюсь войти доменным пользователем, на секунду происходит вход и потом выбрасывает на экран логона, и так каждый раз, не пускает никаким доменным пользователем, sssd при этом сообщает что ПК в домене, по логам видно что авторизация вроде как происходит:

Код:

Apr 11 09:21:22 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_unix(fly-dm:auth): authentication failure; logname= uid=0 euid=0 tty=localhost:100 ruser= rhost=localhost  user=test@zakaz.local
Apr 11 09:21:22 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_sss(fly-dm:auth): authentication success; logname= uid=0 euid=0 tty=localhost:100 ruser= rhost=localhost user=test@zakaz.local
Apr 11 09:21:23 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_unix(fly-dm:session): session opened for user test@zakaz.local by (uid=0)
Apr 11 09:21:23 ADMWS-UMZ003 systemd-logind[904]: New session 740 of user test.
Apr 11 09:21:23 ADMWS-UMZ003 systemd: pam_unix(systemd-user:session): session opened for user test by (uid=0)
Apr 11 09:21:23 ADMWS-UMZ003 fly-dm: localhost:100[15075]: pam_unix(fly-dm:session): session closed for user test@zakaz.local
Apr 11 09:21:23 ADMWS-UMZ003 systemd-logind[904]: Removed session 740.

kinit вообще лезет в другой домен, а после перенастройки вечно в ошибку падает:

Код:

kinit: KDC reply did not match expectations while getting initial credentials

oko

11.04.2022

imho, вначале разберитесь с проблемами kinit. Из-за него вся свистопляска. Грубо говоря, не может юзер по Kerberos авторизоваться в домене и, как следствие, в ОС…
Ориентируйтесь по указанной ошибке kinit как, например, тут…

12.04.2022

С kinit разобрался, пришлось полностью настраивать krb5.conf
Но вход в систему все еще не осуществляется, так же не входит даже в консольный режим

oko

12.04.2022

В графике/консоли авторизация невозможна для доменных юзеров или для локальных тоже? Если локальных тоже не пускает, то дело в работе подсистемы pam-аутентификации — нужно копать в эту сторону…
Так-то логи бы посмотреть как syslog, так и на стороне сервера-контроллера домена…

12.04.2022

Не пускает только доменных пользователей, и только при настройке sssd, winbind работает.
Скажите какие именно, скину, заодно и сам может пойму куда смотреть

oko

12.04.2022

to JoKeR174
Классика в виде /var/log/auth.log, /var/log/syslog (если туда сыпятся все события — проверяйте по *.* в /etc/rsyslog.conf), и аналогичных системных журналов сервера-контроллера (Система, Безопасность). Нужны события по отбою авторизации. Контроллер домена каким-нибудь файрволлом не прикрыт случайно (это так, на всякий случай уточнение)?
По-прежнему есть подозрение, что косячит Kerberos. Тикет запрашивается и отрабатывает корректно при вводе правильных уч.данных? И покажите, пожалуй, финальный вариант /etc/krb5.conf…

13.04.2022

Все куски логов в момент попытки входа
На контроллере домена в эти моменты зарегистрированы такие события:

Код:

Запрошен билет проверки подлинности Kerberos(TGT).

Сведения об учетной записи:
    Имя учетной записи:        mov
    Предоставленное имя сферы:    ZAKAZ.LOCAL
    Идентификатор пользователя:            ZAKAZmov

Сведения о службе:
    Имя службы:        krbtgt
    Код службы:        ZAKAZkrbtgt

Сведения о сети:
    Адрес клиента:        192.168.151.109
    Порт клиента:        46763

Дополнительные сведения:
    Параметры билета:        0x50010010
    Код результата:        0x0
    Тип шифрования билета:    0x12
    Тип предварительной проверки подлинности:    2

Сведения о сертификате:
    Имя поставщика сертификата:     
    Серийный номер сертификата: 
    Отпечаток сертификата:     

Сведения о сертификате предоставляются только в том случае, если сертификат использовался для предварительной проверки подлинности.

Типы предварительной проверки подлинности, параметры билета, типы шифрования и коды результата определены в стандарте RFC 4120.

Код:

Запрошен билет проверки подлинности Kerberos(TGT).

Сведения об учетной записи:
    Имя учетной записи:        mov
    Предоставленное имя сферы:    ZAKAZ.LOCAL
    Идентификатор пользователя:            ZAKAZmov

Сведения о службе:
    Имя службы:        krbtgt
    Код службы:        ZAKAZkrbtgt

Сведения о сети:
    Адрес клиента:        ::ffff:192.168.151.109
    Порт клиента:        37984

Дополнительные сведения:
    Параметры билета:        0x50010010
    Код результата:        0x0
    Тип шифрования билета:    0x12
    Тип предварительной проверки подлинности:    2

Сведения о сертификате:
    Имя поставщика сертификата:     
    Серийный номер сертификата: 
    Отпечаток сертификата:     

Сведения о сертификате предоставляются только в том случае, если сертификат использовался для предварительной проверки подлинности.

Типы предварительной проверки подлинности, параметры билета, типы шифрования и коды результата определены в стандарте RFC 4120.

Код:

Запрошен билет службы Kerberos.

Сведения об учетной записи:
    Имя учетной записи:        mov@ZAKAZ.LOCAL
    Домен учетной записи:        ZAKAZ.LOCAL
    GUID входа:        {d5a06320-9143-6ff6-e2bd-99aab7fa2320}

Сведения о службе:
    Имя службы:        ADMWS-UMZ003$
    Идентификатор службы:        ZAKAZADMWS-UMZ003$

Сведения о сети:
    Адрес клиента:        ::ffff:192.168.151.109
    Порт клиента:        37986

Дополнительные сведения:
    Параметры билета:        0x50810000
    Тип шифрования билета:    0x12
    Код ошибки:        0x0
    Службы передачи:    -

Данное событие возникает каждый раз при запросе доступа к ресурсу, такому как компьютер или служба Windows.  Поле "Имя службы" указывает ресурс, доступ к которому запрашивался.

Это событие можно связать с событиями входа Windows, сравнивая поля "GUID входа" каждого из событий.  Событие входа регистрируется на компьютере, к которому запрашивался доступ. Часто этот компьютер отличается от контроллера домена, выдавшего билет службы.

Параметры билета, типы шифрования и коды ошибок определены в стандарте RFC 1510.

При запросе тикета вроде все отрабатывается нормально, ошибок нет, в klist отображается

Код:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: mov@ZAKAZ.LOCAL

Valid starting       Expires              Service principal
13.04.2022 08:34:36  13.04.2022 18:34:36  krbtgt/ZAKAZ.LOCAL@ZAKAZ.LOCAL
        renew until 14.04.2022 08:34:34

Вот krb5

Код:

[libdefaults]
    default_realm = ZAKAZ.LOCAL
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
    fcc-mit-ticketflags = true
    dns_lookup_realm = false
    dns_lookup_kdc = true
    v4_instance_resolve = false
    v4_name_convert = {
        host = {
            rcmd = host
            ftp = ftp
        }
        plain = {
            something = something-else
        }
    }

[realms]
    ZAKAZ.LOCAL = {
    admin_server = dc1.zakaz.local
    kdc = dc1.zakaz.local
    kdc = dc2.zakaz.local
    default_domain = ZAKAZ.LOCAL
    }

[domain_realm]
    .zakaz.local = ZAKAZ.LOCAL
    zakaz.local = ZAKAZ.LOCAL
[login]
    krb4_convert = false
    krb4_get_tickets = false

6 КБ
Просмотры: 45
4 КБ
Просмотры: 47

oko

13.04.2022

to JoKeR174
Мде, особых проблем не вижу. Разве что директива «default_domain» обычно мелкими описывает домен — есть же строки конвертации в секции domain_realm…
Еще dns_lookup_realm = false вообще бы убрал. И, возможно, имеет смысл добавить в секцию libdefaults директивы default_tgs_enctypes и default_tkt_enctypes с описанием разрешенных стандартов шифрования. Особенно, если в вашем домене все переведено на AES и RC4/DES/прочее явно заблокированы в политиках безопасности. Иначе билет-то будет запрашиваться, но по минимальному стандарту шифрования, что приведет к сбою его выдачи и эксплуатации. Впрочем, klist у вас отрабатывает, значит, дело не в этом…
Плохо, что syslog пустой — надеялся там увидеть корень проблемы…

13.04.2022

При попытке зайти в консольный режим syslog выдает

Код:

Apr 13 15:34:07 ADMWS-UMZ003 systemd[1]: Stopping System Security Services Daemon...
Apr 13 15:34:07 ADMWS-UMZ003 sssd[nss]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[be[zakaz.local]]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[pam]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[ifp]: Shutting down
Apr 13 15:34:07 ADMWS-UMZ003 sssd[4575]: Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
Apr 13 15:34:07 ADMWS-UMZ003 sssd[4575]: Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
Apr 13 15:34:07 ADMWS-UMZ003 sssd[4575]: Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
Apr 13 15:34:07 ADMWS-UMZ003 systemd[1]: Stopped System Security Services Daemon.
Apr 13 15:34:07 ADMWS-UMZ003 systemd[1]: Starting System Security Services Daemon...
Apr 13 15:34:08 ADMWS-UMZ003 sssd: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[be[zakaz.local]]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[nss]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[ifp]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 sssd[pam]: Starting up
Apr 13 15:34:08 ADMWS-UMZ003 systemd[1]: Started System Security Services Daemon.
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: ; TSIG error with server: tsig verify failure
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: update failed: REFUSED
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: ; TSIG error with server: tsig verify failure
Apr 13 15:34:09 ADMWS-UMZ003 sssd[23389]: update failed: REFUSED
Apr 13 15:34:33 ADMWS-UMZ003 systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Apr 13 15:34:33 ADMWS-UMZ003 systemd[1]: Stopped Getty on tty1.
Apr 13 15:34:33 ADMWS-UMZ003 systemd[1]: Started Getty on tty1.
Apr 13 15:34:53 ADMWS-UMZ003 systemd[1]: getty@tty1.service: Service has no hold-off time, scheduling restart.
Apr 13 15:34:53 ADMWS-UMZ003 systemd[1]: Stopped Getty on tty1.
Apr 13 15:34:53 ADMWS-UMZ003 systemd[1]: Started Getty on tty1.

oko

13.04.2022

to JoKeR174
А покажите-ка выхлоп systemctl status sssd

13.04.2022

to JoKeR174
А покажите-ка выхлоп systemctl status sssd

Код:

● sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2022-04-13 15:34:08 +05; 32min ago
 Main PID: 23389 (sssd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/sssd.service
           ├─23389 /usr/sbin/sssd -i --logger=files
           ├─23391 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain zakaz.local --uid 0 --gid 0 --logger=files
           ├─23392 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           ├─23393 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files
           └─23394 /usr/lib/x86_64-linux-gnu/sssd/sssd_ifp --uid 0 --gid 0 --logger=files

oko

13.04.2022

to JoKeR174
Странно, ожидал увидеть ошибку TSIG как в случае локального входа. Тогда было бы как тут…
Вообще, нашел свою же заметку про sssd в AstraLinux. Посмотрите, проверьте, возможно поможет. Пока у меня иных мыслей нет…

14.04.2022

Попробовал, ничего не изменилось к сожалению.
При всем при этом через терминал и команду “su login” получается залогиниться под доменным пользователем, и через ssh login@127.0.01 получается

oko

14.04.2022

to JoKeR174
Все страннее и страннее (с)
Значит, Kerberos и механизмы авторизации в домене отрабатывают. Хотя… неплохо бы посмотреть трафик по-середине, что же там передается в момент login по ssh и чего не передается при стандартном графическом входе…
И это не может быть проблема Fly-DM/WM, поскольку консольный вход под доменным юзером у вас также не работает…
Тогда у меня остается один вариант: косячит демон sssd — служба не стартует до момента авторизации в системе локального юзера/админа. Проверить элементарно — зайти под локальным, разлогиниться и зайти под доменным. Впрочем, не до конца понял — этот момент тоже пробовали?

15.04.2022

Да, так пробовал, пробовал открывать сессию в окне, не пускает
Момент авторизации по ssh:

Код:

Apr 15 08:26:02 ADMWS-UMZ003 sshd[10493]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=mov
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=mov
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: Accepted password for mov from 127.0.0.1 port 40736 ssh2
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: pam_unix(sshd:session): session opened for user mov by (uid=0)
Apr 15 08:26:03 ADMWS-UMZ003 systemd-logind[893]: New session 52 of user mov.
Apr 15 08:26:03 ADMWS-UMZ003 systemd: pam_unix(systemd-user:session): session opened for user mov by (uid=0)
Apr 15 08:26:03 ADMWS-UMZ003 sshd[10493]: lastlog_write_entry: Error writing to /var/log/lastlog: File too large

Код:

Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Created slice User Slice of mov.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Starting User Manager for UID 975401130...
Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Started Session 52 of user mov.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG network certificate management daemon.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Timers.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Paths.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent and passphrase cache.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Sockets.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Basic System.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Reached target Default.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[10496]: Startup finished in 22ms.
Apr 15 08:26:03 ADMWS-UMZ003 systemd[1]: Started User Manager for UID 975401130.

oko

15.04.2022

to JoKeR174
В порядке бреда — удалите файл /var/log/lastlog и либо рестартаните rsyslog, либо перезагрузитесь (понятно, что это в минимуме решит трабблу с ошибкой в логе, но вдруг на lastlog еще что-то завязано — надо бы поглядеть)…
Еще мне откровенно не нравится, что по PAM авторизацию отбивает, а дальше sssd ее принимает. Не настолько хорошо разбираюсь в sssd-интеграции в домен, чтобы делать выводы. Но, кажись, проблемное место найдено, потому что процессы локального входа могут быть по-прежнему завязаны на PAM, который не срабатывает. Или в /etc/ssh/sshd_config параметр UsePam = no?…

15.04.2022

После удаления стал ругаться что файла нет, после создания руками начинает также ругаться на этот файл.
Впрочем при логоне su login такой ошибки нет.
В sshd_config параметр UsePam yes.
По поводу PAM авторизации, пробовал сменить очередность, тогда отбивает авторизацию напрочь:

Код:

Apr 15 15:19:15 ADMWS-UMZ003 su[18894]: pam_sss(su:auth): authentication failure; logname=adminumz uid=1000 euid=0 tty=/dev/pts/0 ruser=adminumz rhost= user=mov
Apr 15 15:19:15 ADMWS-UMZ003 su[18894]: pam_sss(su:auth): received for user mov: 7 (Сбой при проверке подлинности)
Apr 15 15:19:18 ADMWS-UMZ003 su[18894]: pam_unix(su:auth): authentication failure; logname=adminumz uid=1000 euid=0 tty=/dev/pts/0 ruser=adminumz rhost=  user=mov
Apr 15 15:19:20 ADMWS-UMZ003 su[18894]: pam_authenticate: Authentication failure
Apr 15 15:19:20 ADMWS-UMZ003 su[18894]: FAILED su for mov by adminumz
Apr 15 15:19:20 ADMWS-UMZ003 su[18894]: - /dev/pts/0 adminumz:mov

Попытка входа через консоль:

Код:

Apr 15 15:21:28 ADMWS-UMZ003 login[901]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=mov
Apr 15 15:21:28 ADMWS-UMZ003 login[901]: pam_sss(login:auth): received for user mov: 7 (Authentication failure)
Apr 15 15:21:31 ADMWS-UMZ003 login[901]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost=  user=mov
Apr 15 15:21:34 ADMWS-UMZ003 login[901]: FAILED LOGIN (1) on '/dev/tty1' FOR 'mov', Authentication failure

ssh:

Код:

:26 ADMWS-UMZ003 sshd[18984]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=mov
Apr 15 15:23:26 ADMWS-UMZ003 sshd[18984]: pam_sss(sshd:auth): received for user mov: 7 (Authentication failure)
Apr 15 15:23:26 ADMWS-UMZ003 sshd[18984]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=mov
Apr 15 15:23:28 ADMWS-UMZ003 sshd[18984]: Failed password for mov from 127.0.0.1 port 45184 ssh2

oko

15.04.2022

to JoKeR174
Ругается он, очевидно, из-за некорректных прав доступа к файлу. Но не суть…
Попробуйте командой sss_debuglevel 7 включить полное логирование sssd и как тут добавить логирование для PAM. Дальше еще раз зайти-выйти и посмотрим, что получится…
Такое ощущение, что PAM у вас не полностью привязан к sssd…

18.04.2022

krb5_child

Код:

(Mon Apr 18 09:37:46 2022) [[sssd[krb5_child[5799]]]] [privileged_krb5_setup] (0x0080): Cannot open the PAC responder socket
(Mon Apr 18 09:37:47 2022) [[sssd[krb5_child[5799]]]] [sss_send_pac] (0x0040): sss_pac_make_request failed [-1][2].
(Mon Apr 18 09:37:47 2022) [[sssd[krb5_child[5799]]]] [validate_tgt] (0x0040): sss_send_pac failed, group membership for user with principal [mov@ZAKAZ.LOCAL@ZAKAZ.LOCAL] might not be correct.

sssd_nss

Код:

(Mon Apr 18 09:37:36 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:36 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:36 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:37 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:46 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:47 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:48 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:50 2022) [sssd[nss]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.

sssd_pam

Код:

(Mon Apr 18 09:37:46 2022) [sssd[pam]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.
(Mon Apr 18 09:37:47 2022) [sssd[pam]] [get_client_cred] (0x0080): The following failure is expected to happen in case SELinux is disabled:
SELINUX_getpeercon failed [92][Протокол недоступен].
Please, consider enabling SELinux in your system.

sssd_zakaz.local

Код:

(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [check_if_pac_is_available] (0x0040): find_user_entry failed.
(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [check_if_pac_is_available] (0x0040): find_user_entry failed.
(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [sysdb_get_real_name] (0x0040): Cannot find user [fly-dm@zakaz.local] in cache
(Mon Apr 18 09:37:36 2022) [sssd[be[zakaz.local]]] [sysdb_get_real_name] (0x0040): Cannot find user [fly-dm@zakaz.local] in cache

oko

18.04.2022

to JoKeR174
Откровенно говоря, смущает вот это:

У вас там в krb-конфигурациях нигде нет дубляжа домена случайно?
И вот это тоже:

Выходит, что fly-dm (уч.запись для сессии связи Fly-DM с X-Server) почему-то вместо PAM локально ломится в домен через sssd. Не ясно…

Источник