4

Simple, how do I make ssh (port 22) drop/refuse a connection if root@ip_address request is received, but still allow user@ip_address to work properly. Basically hide the fact there's a server at that particular ip_address.

I'm having issues with crawlers hitting my server(s). SSH root permission already disabled in sshd_config and UFW limit is already being used.

Alternative details to problem/solution

These requests are slowly eating up my RAM, would you recommend the response to be to flush the cache for ssh? and how?

Update and possible quick solution

Okay after diving into Fail2Ban a little more as suggested, the guys at booleanworld did a great job of defining a banaction of dropping packets and not responding.

link here: https://www.booleanworld.com/protecting-ssh-fail2ban/

3
  • 2
    If an SSH client tries to authenticate as root which is rejected, after a few tries at most sshd will disconnect that connection, and it should NOT 'eat up' any RAM. If a client doesn't authenticate as any userid, that will tie up a process and socket for 2 minutes by default, but you can reduce that. Jun 16 '20 at 7:05
  • 1
    What observations did you make that showed high memory usage from SSH connection attempts?
    – Freiheit
    Jun 16 '20 at 13:28
  • @ Freiheit, Under top, a bunch of USER sshd keep appearing as well as agetty's. And it's just suckin up cache. Jun 17 '20 at 4:47
9

You can't do that.

Your server has no way of knowing what user the remote connection will try to login as, until after it has already connected!

You should consider using fail2ban to block repeated abusers.

6
  • Well I realize there's TCPIP back and forth, but would the server have a simple method to read the packet, realize it's asking for root, and then just not respond anymore thereafter? Alternatively, I'll edit my OP, these requests are slowly eating up my RAM, would you recommend the response to be to flush the cache for ssh? and how? Jun 16 '20 at 3:50
  • 3
    Well, that's basically what it's already doing! You really should be using fail2ban like the rest of us. Jun 16 '20 at 3:52
  • It's enabled, but I'm running small RAM VPS's, there's a ton banned but they just keep coming at random walk intervals based on the logs. I'm guessing I just have a popular domain name for nubs to hit. (I'm trying to avoid using DOS prevention services, or coding up a tun device, which I can probably control the packet timing and cause a timeout - neither I want to do) Jun 16 '20 at 3:56
  • 1
    You're on the Internet, this is just part of it. Every IPv4 address gets automated malicious traffic. If it's really bogging down the VM, you might move ssh to a different port, but that is inconvenient for you, and won't be helpful if someone does target you specifically. And a few bots will find the alternate port anyway, so it's not a cure-all. Jun 16 '20 at 4:48
  • I second the fail2ban option!
    – Thomas
    Jun 16 '20 at 13:54
2

You can disable root login via ssh by editing /etc/ssh/sshd.conf

Always backup config files before making changes.

sudo cp /etc/ssh/sshd.conf /etc/ssh/sshd.conf.backup

Use whatever editor you like such as nano or vi and edit /etc/ssh/sshd.conf

Find, or add, the following lines;

AllowUsers someuser some_other_user
PermitRootLogin no

Save the file and restart your ssh server.

sudo systemctl restart sshd.service

You can still perform root activities using sudo and you can also switch to the root using by typing su root

Bonus Tip:

While you have the config file open take a moment to examine its contents. You might also find other useful settings. Before changing anything google what it does otherwise you risk locking yourself out.

2
  • 3
    While good advice, OP specifically mentions that they already did this: "SSH root permission already disabled in sshd_config"
    – Michael
    Jun 16 '20 at 14:30
  • @Michael-Where'sClayShirky Wow, I didn't even see the second paragraph where they mentioned that. :( Jun 16 '20 at 21:20
0

Since TCP is a connection-oriented protocol, an established connection is required to process/negotiate anything further (like a username in this case). Hence, the above suggestion from @Michael Hampton may be your solution: run SSH server on a different port.

An attacker can scan a million hosts with a million probes sent to port 22/tcp. When a non-standard port is used, only 16 hosts can be scanned with a million probes, since up to 65,534 additional ports need to be tested on the top of the well-known one.

Of course, it won't help you if you're a target already, but chances are, you'll reduce the number of random scans by several orders of magnitude.

For all other attackers that know your machines already, use filtering automation solutions, like Fail2Ban. Otherwise, you'll end up having tons of firewall rules, that need to be processed for every SSH packet before it is accepted. This can lead to many wasted CPU cycles when your Netfilter rules grow over time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.