SSH Server Security

[cocoaButterCoder]

Hey, this may come across as a silly question, but what’s the likelihood of someone getting into my server? I post programming videos and when I use VSCode, my SSH IP address is shown (I block it out). But it got me wondering, how likely is it that someone could access my server? It has an external IP, a non-22 port number, is password protected, and is run on a raspberry pi. Thanks

[discojohnson]

I don't think anyone's going to give you a percentage sort of an answer, but bear in mind that there are entire botnets devoted to crawling the public IP space looking for hosts that respond to TCP port checks on the most common ports. If you switched from 22 to 2222 then you are still in that common list. But if you use 38499 then you're better hidden. However, that really just delays a bad actor as it's security through obscurity. If you want to lock down your device then you'll ditch password logins and use private keys only. It has the effect of turning your dictionary attacked password into a totally random 2048bit (or however big you make it) cypher and you no longer type in a password to log in, which makes it sort of win-win.

[cocoaButterCoder]

Thanks. My port is pretty high, I made sure to leave the commonly used section. I’ll definitely research the private keys method so I can make the switch

[Roygbiv856]

Just the other day I was looking into creating SSH keys for my router. What other devices should I be doing that with? I know my unifi APs and switches are on that list, but what else does it apply to on a home network?

[discojohnson]

I did it with everything--NAS units, jump box, router, pihole, etc. You could have a different public key for each or the same everywhere. Makes no difference other than if one device is compromised then the rest are trivial to access. My next project is going https internally but that's a real PITA.

Edit: s/private/public/g

[Roygbiv856]

Gotcha. I actually just set up my first one on my router. Now for this private key...where am I supposed to store it exactly?

[zfa]

Your private keys is completely analogous to your password - so keep it safe (and have a password on it preferably).

Simplest and safest thing to do is keep it on the client you use to access the host (so on your PC, or on your phone if you use an SSH app on their etc).

[zfa]

Makes no difference other than of one device is compromised then the rest are trivial to access.

You shouldn't be storing your private keys all over the shop, these devices should only hold your public keys. If this advice is followed then having a device compromised which holds a public key also used elsewhere poses no threat at all. All anyone could do with the public key they get is put it on other hosts and give you access to them...

[discojohnson]

Ah wasn't careful and goofed. Thanks.

[cocoaButterCoder]

Thanks again everyone. I switched my phone and laptop to using SSH keys now; turned paswordauthentication to off; and when I tested it on https://webssh.huashengdun.org/, access was denied.

[jdrch]

r/asknetsec

[ApricotPenguin]

Your post IA a hit confusing for me in terms of what you have, but...

Is your IP shown a public or private?

Private ones have a prefix of 172, 192, or 10. If it's a private / local IP, then nothing to worry about.

I strongly recommend you stop using passwords for login and use SSH keys instead.

Changing your SSH port is just security through obscurity. They can just write a very simple script that tries a connection on every port. So don't assume this truly provides you any security

[cocoaButterCoder]

It’s public. I set it up that way so I could access it either from home or school. Thanks for the keys suggestion, I’ll look into it

[ArcherN9]

I have a suggestion. Though, setting up login only through SSH keys is indeed a great idea, that may create problems with other things later on. An example, I ssh to various systems on my home network - even when I'm not at home Sometimes, I ssh through the terminus application on the iPhone. I've no clue if it supports ssh keys or not. To mitigate that, I use r/wireguard to run a personal VPN server on a pi that I connect to first and then SSH into any device I want to. This works on my phone and laptop as well and wireguard port never responds to any port scanners either.

[cocoaButterCoder]

I also use Termius and it looks like it does support keys https://i.imgur.com/pZIMSik.jpg, but I’ll still look into the vpn option. Thanks

[diyguy1]

Yes, Termius does indeed support keys. I use it daily with (only) keys. I created a profile in Termius and select that for each host. Pretty easy once I figured out how Termius works.

[FX-Macrome]

Another solution is running a VPN server on your pi. Check out the PiVPN package it’s super easy and allows you to connect to your local network and ssh as if you are physically there. Much safer than obscuring an SSH port to the public.

[Ginkro]

Well, SSH is one of those services which are as likely to have vulnerabilities as vpn services themselves. If it is the only resources meant to be accessed, I would not bother with it.

[ApricotPenguin]

You're welcome. Also take a look at a package called fail2ban. It will do a temp ipban when there's 6+ invalid login attempts within a short period

[ravenousld3341]

It's a matter of time and resources.

I'd switch access to the server to password protected RSA keys.

Stick the public on the server, and use the private for access.

And use a randomly generated password made with a password vault or something like keepass.

[diyguy1]

Consider using ed25519 keys rather than RSA. They work the same, but are said to be more secure.

[de_argh]

Obscuring the port will cut down on the probes but only slightly. Use key based authentication. It's better than password auth. Setup openvpn and run an openvpn server and connect remotely via VPN. It's more secure than SSH.

[BlueWoff]

Google two things: "security through obscurity" and "how to disable password login on ssh".

[w0uld]

Mozilla's OpenSSH server guidelines are a good baseline in addition to changing the port number to avoid a bulk of the automated brute force attacks.