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/

Improve this question
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.
    – dave_thompson_085
    Jun 16, 2020 at 7:05
  • 1
    What observations did you make that showed high memory usage from SSH connection attempts?
    – Freiheit
    Jun 16, 2020 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.
    – Farmer John
    Jun 17, 2020 at 4:47

3 Answers 3

Reset to default
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.

Improve this answer
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?
    – Farmer John
    Jun 16, 2020 at 3:50
  • 3
    Well, that's basically what it's already doing! You really should be using fail2ban like the rest of us.
    – Michael Hampton
    Jun 16, 2020 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)
    – Farmer John
    Jun 16, 2020 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.
    – Michael Hampton
    Jun 16, 2020 at 4:48
  • I second the fail2ban option!
    – Thomas
    Jun 16, 2020 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.

Improve this answer
2
  • 3
    While good advice, OP specifically mentions that they already did this: "SSH root permission already disabled in sshd_config"
    – Michael come lately
    Jun 16, 2020 at 14:30
  • @Michael-Where'sClayShirky Wow, I didn't even see the second paragraph where they mentioned that. :(
    – Admiral Noisy Bottom
    Jun 16, 2020 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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .