LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   PAM authentication failure (https://www.linuxquestions.org/questions/slackware-14/pam-authentication-failure-4175733041/)

mfoley 01-21-2024 11:21 PM

PAM authentication failure
 
I've just upgraded a computer to Slackware 15.0. This release includes PAM. I'm having some authentication issue, the first of which is shown below in /var/log/secure:
Code:

Jan 22 00:16:11 mail sshd[1488]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.101.88.225  user=root
Jan 22 00:16:11 mail sshd[1488]: gkr-pam: unable to locate daemon control file
Jan 22 00:16:11 mail sshd[1488]: gkr-pam: stashed password to try later in open session
Jan 22 00:16:14 mail sshd[1488]: gkr-pam: unable to locate daemon control file
Jan 22 00:16:14 mail sshd[1488]: gkr-pam: stashed password to try later in open session
Jan 22 00:16:17 mail sshd[1488]: gkr-pam: unable to locate daemon control file
Jan 22 00:16:17 mail sshd[1488]: gkr-pam: stashed password to try later in open session
Jan 22 00:16:20 mail sshd[1488]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.101.88.225  user=root

These messages repeat about every 15 seconds, forever.

Any idea why?

GazL 01-22-2024 06:03 AM

Yeah. Someone in China is trying to break into your system via ssh. If you haven't already then lockdown your sshd configuration as tightly as possible (or better yet, don't run it if you don't need it), and check your log thoroughly for any successful logins.

You could try blocking that source address at the firewall, but it's a game of whack-a-mole.

marav 01-22-2024 07:00 AM

Do you run sshd on port 22 (or NAT 22 -> 22)?

If so, avoid this
Change the port, or forward a port between 40000 - 65000 to port 22 on your router

allend 01-22-2024 08:00 AM

Looks like a serial offender conducting a password brute force attack for root.

I am a big fan of
Code:

PermitRootLogin no
in /etc/ssh/sshd_config
If I need root privileges, I am happy to use 'su -'.

GazL 01-22-2024 08:50 AM

Quote:

Originally Posted by allend (Post 6478556)
I am a big fan of
Code:

PermitRootLogin no
in /etc/ssh/sshd_config
If I need root privileges, I am happy to use 'su -'.

Sound advice. I like to take it a bit further and restrict use to only members of group 'users', with:
AllowGroups users


Allowing only pubkey authentication is preferable if your use situation allows for it.

mfoley 01-22-2024 09:08 AM

Quote:

Originally Posted by GazL (Post 6478529)
Yeah. Someone in China is trying to break into your system via ssh. If you haven't already then lockdown your sshd configuration as tightly as possible (or better yet, don't run it if you don't need it), and check your log thoroughly for any successful logins.

Ah, you're right! I didn't notice the IP of 180.101.88.225 at first. That is China.
Quote:

You could try blocking that source address at the firewall, but it's a game of whack-a-mole.
[/quote]
I do have a whack-a-mole script. This is a new domain controller just installed yesterday and I haven't fired up that script yet. Will do so ASAP. Meanwhile, I have blocked that IP.
Quote:

Originally Posted by marav (Post 6478541)
Do you run sshd on port 22 (or NAT 22 -> 22)?

If so, avoid this
Change the port, or forward a port between 40000 - 65000 to port 22 on your router

Yes, I do that on other systems. In this case I leave 22 as a "honey pot" and block per my comment above.
Quote:

Originally Posted by allend (Post 6478556)
Looks like a serial offender conducting a password brute force attack for root.

I am a big fan of
Code:

PermitRootLogin no
in /etc/ssh/sshd_config
If I need root privileges, I am happy to use 'su -'.

I do have "PermitRootLogin no" set.
Quote:

Originally Posted by GazL (Post 6478565)
Sound advice. I like to take it a bit further and restrict use to only members of group 'users', with:
AllowGroups users


Allowing only pubkey authentication is preferable if your use situation allows for it.

Yes, I only permit a specific user.

Thanks all! I've turned on my whack-a-mole script.

gus3 01-22-2024 10:38 AM

Whack-a-mole, honey pot... I remember having so much fun.

It was a special kind of fun, when I was fighting back the latest Internet DDoS. I wrote a simple Bash script to detect and block it.

Then I tested it. While I was online. Oooh! It worked, almost too well. :redface: :doh: The web site still ran just fine; all evil testing was blocked off (incl. mine) while the botnets were still waiting to find out if this "victim" was online or not (incl. mine).

Like I said, almost too well. After a reboot, I decided to keep the script and use it, until better protections came in for Windows, via Norton and McAfee.

And yes, it was fun!

henca 01-22-2024 01:01 PM

I log all addresses that fail connecting by ssh to my machine. At the time of this writing, it is 53661 different IP addresses, many of them from China. They do not only attempt the root account. I am not listening om port 22, but the rather easy to use port 2222.

Those 53661 IP addresses has accumulated since 2018.

regards Henrik

mfoley 01-25-2024 04:13 PM

Quote:

Originally Posted by henca (Post 6478644)
I log all addresses that fail connecting by ssh to my machine. At the time of this writing, it is 53661 different IP addresses, many of them from China. They do not only attempt the root account. I am not listening om port 22, but the rather easy to use port 2222.

Those 53661 IP addresses has accumulated since 2018.

regards Henrik

I do the same and whack each of these moles/IPs. I do, however, periodically clear that list so as not to have the 10's of thousands of IP that iptables has to deal with. I find that very often bots give up after numerous retries and move on, usually permanently. For persistent attackers, I maintain a repeatOffenders list that alway get blocked. Currently, after 25 days from a clean list, I have 1,355 "moles" on one machine and 441 (Since Saturday) on another.

scuzzy_dog 01-25-2024 04:50 PM

I just use simple iptables rules.

iptables -A INPUT -s 192.168.17.0/24 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -s xxx.yyy.zzz.abc -p tcp --dport 22 -j ACCEPT

iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "Denied SSH: " --log-level 2
iptables -A INPUT -p tcp --dport 22 -j DROP

rkelsen 01-25-2024 08:09 PM

Rather than making the SSH port vulnerable, IMO it would be best to use a VPN (either OpenVPN or WireGuard). That would give you remote access to the LAN, thereby allowing you to SSH to any machine you want. Running it on a high-numbered UDP port would be ideal. Your machine becomes practically invisible. No whack-a-mole necessary, because the moles stop coming.

thirdm 01-25-2024 09:11 PM

So what about those gkr-pam messages? I see those in my log too, but no attempts on sshd since I'm not running that.
(Update: removepkging gnome-keyring, maybe that will help.)

henca 01-26-2024 12:54 AM

Quote:

Originally Posted by rkelsen (Post 6479356)
Rather than making the SSH port vulnerable, IMO it would be best to use a VPN (either OpenVPN or WireGuard). That would give you remote access to the LAN, thereby allowing you to SSH to any machine you want.

Yes, I have also been using a VPN for such a purpose (good old vpnd). Nevertheless it has been convenient to have some ssh port open to easily be able to login from new things like smartphones.

regards Henrik

lostintime 01-26-2024 11:52 AM

Quote:

So what about those gkr-pam messages?
If the gnome keyring is not needed, then in /etc/pam.d/system-auth, comment out the lines with pam_gnome_keyring.so. For example:

Code:

#-session optional pam_gnome_keyring.so auto_start

dr.s 01-28-2024 09:13 AM

Quote:

Originally Posted by GazL (Post 6478565)
Sound advice. I like to take it a bit further and restrict use to only members of group 'users', with:
AllowGroups users


Allowing only pubkey authentication is preferable if your use situation allows for it.

I like to restrict to certain users/hosts ex.
Code:

AllowUsers user1@192.168.0.25 user2@192.168.0.26
Code:

AllowUsers
              This keyword can be followed by a list of user name
              patterns, separated by spaces.  If specified, login is
              allowed only for user names that match one of the
              patterns.  Only user names are valid; a numerical user ID
              is not recognized.  By default, login is allowed for all
              users.  If the pattern takes the form USER@HOST then USER
              and HOST are separately checked, restricting logins to
              particular users from particular hosts.  HOST criteria
              may additionally contain addresses to match in CIDR
              address/masklen format...



All times are GMT -5. The time now is 12:10 AM.