SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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
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
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
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.
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. 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!
Last edited by gus3; 01-22-2024 at 10:41 AM.
Reason: two-words
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.
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.
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.
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.)
Last edited by thirdm; 01-25-2024 at 09:13 PM.
Reason: removing gkr
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.
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...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
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).
