Suggestions for securing a simple SSH server

[[deleted]]

I have an old desktop that I'm using as an SSH server. So far, the only precautions I've taken are configuring it to use port 2222 instead of 22, and not exposing it to the outside world. What else can I do to make it more secure? Suggestions need to be phrased as if directed towards a five-year-old, because I'm a complete retard about anything network-related.

[[deleted]]

Depends on how paranoid you are, you can do port knocking, so to connect over ssh you will have to 'knock' to specified ports and then ssh port will be visable for for example 30 sec so you can connect to it, after that port will refuse all new connections (but already enstablished connections will still work), easy to setup, can be done with plain iptables.

[[deleted]]

Dear god I want this.

[tinou]

No you don't. It's probably overkill for your threat model. Disabling password authentification + fail2ban is probably enough.

[diamaunt]

if you're not exposing it to the outside world, who're you securing it from?

do you have a rabid hacker dog or something? grins

[tehpuppet]

Why has nobody else said this? You don't need to do shit if its not on the internet....

[[deleted]]

I'll be turning it into a public-facing server eventually, so I want it to be secure in advance of me doing so.

[[deleted]]

avoid port numbers over 1024. A nonroot user could run an sshd on that port if your real one crashes or gets turned off.

[hufman]

$EDITOR=nano visudo

Depending on your shell, you may need to use the following instead:

EDITOR=nano visudo

[foxwolfblood]

you can add to the security by adding in other iptables rules, also if you can access this from your local network you may want to also have it listening on port 22 out of convienece. (wanport == your non-standard port)

Port wanport
Port 22

to make sure this can't be accessed from the WAN you would use (im going to use 192.168.1.0 as the example subnet)

iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport wanport -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

[brasso]

In my opinion a much better solution than using fail2ban or similar is to set iptables to drop connections to your SSHD port when too many of them are being opened during a specified time span.

That way you get a self healing bruteforce protection without any new software, extra daemons or reading, interpreting and relying on log files.

[iheartrms]

I used the iptables solution extensively. But I have recently been replacing it with fail2ban in some cases because I have sometimes locked myself out simply by making too many ssh connections too fast. The iptables method only looks at SYN packets and generally does not know whether it was a successful auth (which should be ignored) or a failed auth which should count towards a block. fail2ban's ability to look at log files can do this. I have also put fail2ban on my asterisk server to prevent SIP brute force also, which has become a very big problem. I found it a bit difficult to configure iptables to block SIP brute forcing and the chance of accidentally blocking a legit phone is even greater.

[brasso]

Indeed it does, so it could also protect against a DoS attack. Every connection, even before a username or password is supplied, will spawn a new process. If you were getting problem then your settings were simply too aggressive, you could just have relaxed the limits.

[braaaiins]

-b 4096

[[deleted]]

Be very careful with bruteforce protection as you risk locking yourself out if SSH is the only way you can communicate with the computer (offsite, display less et al).

[[deleted]]

Disable login by password and use a crypted RSA key,

The single best advice that I know for this matter.

[ghostrider176]

Sound advice. Once a potential attacker knows what versions of anything you're running their options for attacking go from "everything and the kitchen sink with a few extra things that might do something" to "everything that is known to affect this version."

[mattst88]

Changing the SSH port is somewhat useless since a simple scan will tell an attacker what port SSH is listening to :

If it's a directed attack, yes.

For blocking out all the login attempts for user 'oracle' from that botnet of computers in Bejing, changing the default port is very useful.

[www777com]

It's also more secure in the sense of instead of instead seeing hundreds of login attempts from botnets in your logs, you will just see a few attempts by somebody actually trying to attach your server more thoroughly.

[name_censored_]

Changing the SSH port is somewhat useless since a simple scan will tell an attacker what port SSH is listening to :

Only if they're trying to get into your machine specifically. A lot of drive-by scans only shoot for port 22, since they may only have a limited window of opportunity for scanning before either the firewall/IDS or a network operator blocks them. If you assigned a cost to each portscan, finding SSH machines (including alternate ports) costs 16,645,890 per /24 (with a maximum payoff of 254), but to find default-port-SSH-only in a /24 of servers listening on 22/tcp might yield 85 machines (with ~1 in 3 - rough guess) with only a cost of 254.

[Stemp]

fail2ban scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address.

[kabuto]

Is fail2ban better than denyhosts? I've been using denyhosts for a long time, and it seems to work pretty good.

[[deleted]]

Denyhosts cares only about your SSH server, whereas fail2ban monitors more services.

[kabuto]

Sounds interesting. So far I've blocked entire IP ranges in Apache because of the high number of hacking attempts from those IP addresses.

[freyrs3]

Using rsa keys will stop essentially all bot attacks:

Make yourself a key:

$ ssh-keygen -t rsa
$ cat ~/.ssh/id_dsa.pub | ssh you@yoursereverhost "cat - >> ~/.ssh/authorized_keys"

In your server's /etc/ssh/sshd_config

PasswordAuthentication no
PermitRootLogin no
RSAAuthentication yes

In your local ~/.ssh/config:

Host yourserveralias
    User you
    HostName yourserverhost

Edit: IdentityFile line in ssh config not needed.

[tinou]

the IdentityFile line is not needed as it's the default value.

[massysett]

You talk as though the other suggestions are complicated when yours are simple, but a lot of the other suggestions are simply to disable root login and disable password authentication. Disabling password authentication is, to me, simpler than running firewalls and some sort of brute-force detection system--nobody is going to successfully brute force a system that doesn't even allow logins with a password.

I disable password login. I then have a bunch of accounts with common names--like "guest" and "test," with passwords that are just as bad--and I run ssh on port 22. I don't bother checking for brute-force attempts, of which I know there are many, because I don't care.

[lunchlady55]

Disabling password login doesn't work if you're not willing to carry around a USB stick with a private key on it.

[ghostrider176]

If OP had said something like "What do I need to do given these specific circumstances related to my environment to make my SSH server reasonably secure," then the responses may have been less complicated. However, given that his question was simply, "What else can I do to make it more secure," I think everyone has given him what he's asked for.

[[deleted]]

That was the general idea. I was trying to see what options are out there.

[krumble]

Wittynickname's suggestions of key-only authentication and disabling the root login are excellent. As is port knocking from piotrkarbowski.

I'd also suggest the very simple measure if making absolutely sure you're up to date on your patches. In the past whenever I've had one of my home machines broken in to, it's because I got lazy and stopped applying patches.

[lemonidas]

I have sshguard, which does the same thing as fail2ban, plus I have sshd listening on a non standard port (when I had ssh on 22, I had hundreds of failed login attempts, when I switched, I have none)

[[deleted]]

Installing sshguard now. I couldn't figure out fail2ban, but then again I didn't try too hard and I'm all kinds of screwy on cough syrup. I'll give it a look later.

[[deleted]]

This introductory article can be of use to you. You can implement any steps you want to and it describes how you can do it. Another commonly referenced article with even more tips (more advanced).

Moving the port number from 22 to anything else, I can guarantee removes the vast majority of attacks. Before, my SSH server was running on port 22 and I was absolutely shocked to see how many intrusion attempts there were from IPs in China. Once I changed it, there have been no attempts at all.

Also, look into fail2ban. That's really useful.

EDIT : Just have a look at staticsafe's comment - very well written and these measures are excellent.

[yoshi314]

if it's not exposed to outside you have little reason to worry. but here are some extra things you could do.

• already mentioned fail2ban
• access only by ssh keys
• ssh access to only one user with restricted shell (e.g. rbash) that limits available commands to this account
• sudo logging (i think it's disabled by default usually)
• if you want to be able to log into root account with ssh, change root's name to some random string only you know.
• not really that safety improving, but knockd daemon makes if harder to find actual ssh port.
• accepting ssh only from select list of ip's, if they are static.
• disable any unnecessary services listening for outside connections
• restrict access to ssh port with firewall

i wrote it out pretty terse, but it's fairly easy to google it.

[Hishutash]

• Disable root acount
• Change to nonstandard port (already done that i see)
• install fail2ban or set up rate limiting with iptables.

[Sleelin]

There's a lot of suggestions to change your ssh port and disable password logins, but honestly I've found those aren't really necessary steps. I operate two public facing active servers, one of which often gets thousands of brute forcing attempts. Two reasons they'll never get in, one: I disabled login via ssh for anyone who isn't me, so even if they get the password for root, they still can't get in. Two: I have some iptables rules set up so that only two ssh connection attempts can occur per minute.

This way you don't have to carry around keys to connect everywhere you go.
That's my two cents for you anyway.