So you're operating with a compromised user account capable of killing your sshd on port 1234 but there's no other local escalation exploits? Seems like something a little script or patch could fix up really easily - make sure your daemon is running on port 1234. If it's not, take whatever defensive measures you think would be effective.
Look at it a different way. If a bug was found that could kill sshd, then a local user could replace it.
Anything connecting to this replacement sshd would immediately be spotted as fraudulent due to keys.
2. Next he talks about this non-root listener issue. He claims that you shouldn’t run your SSH daemon on a non-privileged port because anyone can spin up a daemon up there. Great point, except you can still do that even if you run your main one on 22. I don't think I understand this point at all. What is it that you're trying to say? Are you sure you understood the original post's point? djc@capelis.dj:~$ nc -l -p 14…
Run it on a port where (port != 22 && port I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.
I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port .
While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use.
Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the keys/check the keys against an authority like with SSL. Most people just accept the key they're given when they first connect (I know I do).
Ouch, camouflage on a tank is a good analogy. Nice response post. In addition to, as the author encourages, being "weary of the 'by obscurity'" argument (as I'm sure we all already are), I would also advocate being wary of it :)
No it isn't. Every server runs SSH, so this is more like there's a field, and you know there's a tank in the field, but you can't see it.
The next thing you do then is take out your standard radar device which scans the field, and pinpoints exactly where the tank is in 3 seconds, and then you aim your tank buster at that spot and fire.
VPN is not mutually exclusive with using SSH. What he's saying is that people should firewall their SSH ports to only allow access from trusted IPs, and VPN's make that easier to do.
So that means you can't SSH into your remote machine from an arbitrary connection? What do you do when you're traveling?
VPN is not mutually exclusive with using SSH. What he's saying is that people should firewall their SSH ports to only allow access from trusted IPs, and VPN's make that easier to do.
So that means you can't SSH into your remote machine from an arbitrary connection? What do you do when you're traveling?
The reason he's right is most attacks on SSH are one-dimensional. In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running. The other d…
Security is as strong as your weakest link. If you can't protect your port 22, any other ports are probably easy to take over too. Are you saying you get extra time since attacker has to find this new port? I am not totally sure what you mean. Please educate me.
Your premise is wrong – while the security of encryption, for example, is as weak as the weakest out of algorithm, key, random numbers used etc., the security of a system solely attacked via the SSH daemon is the sum of each layer of defence (or at least the strongest of these layers); that is, an attacker has to pierce each layer individually and successfully attacking one of them (e.g. finding the SSH port or the correct port knocking sequence) is not enough to render the whole defence void.
Actually, one thing I've found useful is keeping an sshd listening on port 443. I know, I know, sacrilege reusing the HTTPS port, right? The benefit of this is that it can allow you to tunnel through an HTTP proxy (e.g., like in a corporate environment). Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, it will transpare…
> Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, Thats not how HTTPS works, there is no HTTP proxy for 443. You are in a corporate environment where nothing is let out on port 80, except through their HTTP proxy. However, port 443 is allowed out. > In fact, this behaviour is what makes HTTPS remain secure when going t…
Port scanning is generally automated (edit: and scans all ports, not just the handful you listed), so it doesn't actually matter which port you pick as long as it's not 22. Port scanners like nmap are widely available, so the time to actually figure out which port is running SSH is quite short in practice. Basically, there are two classes of people: 1. Those who use port scanners. 2. Those who do not. If you are bein…
those numbers don't look good at when you take a look at what those two classes of people are doing. ie. 1. is targeting you specifically, 2. is bot targeting everyone when presented with two options, thinking of those options as 50:50 is natural, but it's really more like 0.0000001:99.9999999
A bot doesn't necessarily only scan port 22 in a range - nothing stops the bot herder making it scan 1-1024 instead.
Run it on a port where (port != 22 && port I run my SSH daemons on port 1022. It reduces brute-force attacks significantly without reducing security in any way that I'm aware of. I also have a ~/.ssh/config file in my laptop that tells SSH to use port 1022 whenever I'm connecting to one of my own remote machines so I don't even need to type anything extra when I use ssh, rsync, etc.
I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port . While other posters are right to point out that server certificate should make sure nobody can truly hijack your sshd there's no point in taking the risk unless for some reason all privileged ports are in use. Not to mention that ssh's key model is a bit broken since there's not built-in way to distribute the ke…
You can verify the fingerprint, can't you? Not that I always do it (even is just the "first time", as you said), but IMHO the SSH model is definitely better than a central authority you have to pay to get your certificate signed.