Forums

Resolved
0 votes
Every time I login via Putty I'm seeing this in the Events log

User root logged in via su-l 2016-04-13 10:17:17
Authentication failure for malcolm via sshd from 192.168.1.180 2016-04-13 10:17:06
User malcolm logged in via sshd 2016-04-13 10:17:06

I have root login disabled, ie login in as malcolm then su -

Any ideas why?

TIA
Malcolm
Wednesday, April 13 2016, 12:23 AM
Share this post:
Responses (10)
  • Accepted Answer

    Wednesday, January 12 2022, 08:59 AM - #Permalink
    Resolved
    0 votes
    If you follow the threads through, you end up with https://gitlab.com/clearos/clearfoundation/app-base/-/issues/41 where I have added the solution at the bottom.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, January 11 2022, 11:37 PM - #Permalink
    Resolved
    0 votes
    Sorry to bring up this old thread, but this what google brings up.

    What's the solution to this? I see a reference to a redhat solution that it isn't public (anymore?).

    Thanks
    The reply is currently minimized Show
  • Accepted Answer

    Friday, April 15 2016, 07:00 AM - #Permalink
    Resolved
    0 votes
    It actually happens quite a lot especially when starting services, and, I think, some of the mail apps, transmission and others produce a lot of chatter which the fix resolves.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 14 2016, 11:39 PM - #Permalink
    Resolved
    0 votes
    Hi Nick

    As this only seems to happen (so far) when logging on as non-root user via SSH I might leave things alone and turn root login back on, as I will only be using SSH on the LAN and not have the port open on the WAN.

    .....until there is a fix of course ;)

    Cheers!
    Malcolm
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 14 2016, 06:55 AM - #Permalink
    Resolved
    0 votes
    I'm only a home user but I've not noticed any issued arising from the fix which I am still using.

    As an outline, the fix is forcing authentication against unix users (system accounts on ClearOS) before LDAP users and allowing them to fail silently before going on to try LDAP users 3 times, reporting failures. Before it was authenticating against LDAP, reporting failures then trying the system accounts. Unfortunately the additional parameters are not well understood by myself or anyone in the dev team (they put out an appeal in one of the old threads for help) so the bug is not being sorted.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 14 2016, 01:52 AM - #Permalink
    Resolved
    0 votes
    G'day again Nick

    Well replacing the /etc/pam.d/password-auth-ac certainly "fixes" the problem.

    Are you still using this from 3 years or so ago? Has it caused any unintended consequences?

    /var/log/secure if you're interested!

    Apr 14 11:40:58 cos72 sshd[1468]: Accepted password for malcolm from 192.168.1.180 port 56177 ssh2
    Apr 14 11:40:58 cos72 sshd[1468]: pam_unix(sshd:session): session opened for user malcolm by (uid=0)
    Apr 14 11:41:06 cos72 su: pam_unix(su-l:session): session opened for user root by malcolm(uid=2000)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 13 2016, 09:45 PM - #Permalink
    Resolved
    0 votes
    Hi Nick
    I think this might be the problem; it is a pity that it has been an issue for so long and has not been addressed :(

    Have to say I am very nervous about making changes like this however I will try in this a VM first and post back the results here.

    Cheers!
    Malcolm
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 13 2016, 08:10 AM - #Permalink
    Resolved
    0 votes
    I *suspect* you've hit this bug. If you follow the linked threads, the fix is quite easy but system users are now less than 1000 and not 500.

    [edit]
    I'm very nervous of this diagnosis because I think the bug is because ClearOS tries to authenticate against LDAP users before unix users and I don't think that is happening to you, but it could be right and it is worth trying the fix anyway. Make a backup copy of the file so it is easy to revert.
    [/edit]
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 13 2016, 06:27 AM - #Permalink
    Resolved
    0 votes
    G'day Nick

    Thanks for your quick response :)

    [root@gc ~]# tail /var/log/secure
    Apr 13 16:24:08 gc runuser: pam_unix(runuser:session): session opened for user squeezeboxserver by (uid=0)
    Apr 13 16:24:08 gc login: pam_unix(login:session): session opened for user clearconsole by LOGIN(uid=0)
    Apr 13 16:24:09 gc login: LOGIN ON tty1 BY clearconsole
    Apr 13 16:24:24 gc runuser: pam_unix(runuser:session): session closed for user squeezeboxserver
    Apr 13 16:24:26 gc sudo: clearsync : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/sbin/trigger network_connected
    Apr 13 16:24:30 gc sudo: clearsync : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/sbin/trigger accounts
    Apr 13 16:24:39 gc sshd[2805]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.180 user=malcolm
    Apr 13 16:24:39 gc sshd[2805]: Accepted password for malcolm from 192.168.1.180 port 57906 ssh2
    Apr 13 16:24:39 gc sshd[2805]: pam_unix(sshd:session): session opened for user malcolm by (uid=0)
    Apr 13 16:25:09 gc su: pam_unix(su-l:session): session opened for user root by malcolm(uid=2000)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 13 2016, 05:59 AM - #Permalink
    Resolved
    0 votes
    I would guess this is because of the way pam is set up to authenticate where it is trying as a system user first (and failing) then trying as an LDAP user and succeeding. If that is the case, it is a known bug. I think these log to /var/log/secure. Can you post the full bit of the log?
    The reply is currently minimized Show
Your Reply