Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Putting SSH On Another Port is a Good Idea

danielmiessler.com

Post reply on HN
Print view View original

181–190 of 192 posts

Re: Why Putting SSH On Another Port is a Good Idea

#181

Post by beagle3 »

simias wrote: post #112
kijin wrote: post #83

Earlier quoted context omitted.

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…

> 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.

I think the recent NSA news indicate that the SSL authority model is broken. Any 3rd party authority can be subverted by legal (e.g. NSL) means.

SSH's model leaves that only semi-solved. you CAN distribute your own "known_hosts" file, thereby avoiding the need for either an SSL-style authority, or remembering every host's key. Alternatively, you can use something like SSHFP+DNSSEC/DNSCurve or Monkeysphere if you like the underlying trust models.

ssh's key model is NOT broken. SSL's models IS practically broken. ssh just leaves a little less specified.

Re: Why Putting SSH On Another Port is a Good Idea

#182

Post by stormbrew »

simias wrote: post #112
kijin wrote: post #83

Earlier quoted context omitted.

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 actually can sign your host keys (and actually login keys) with relatively recent versions of openssh:

http://blog.habets.pp.se/2011/07/OpenSSH-certificates

Re: Why Putting SSH On Another Port is a Good Idea

#183

Post by fletchowns »

__david__ wrote: post #171
fletchowns wrote: post #114

Earlier quoted context omitted.

You use a VPN and then connect to SSH

So then we go back to my original question. Why do you think a VPN is more secure than SSH? IE, Why is it important that your SSH port only be connected to by known IPs, but your VPN port is OK to be connected to from anywhere?

It's not really about one being more secure than the other. They are both very secure. It's just good to have multiple layers of protection in case something goes wrong somewhere, whether it's caused by human error or something else.

Re: Why Putting SSH On Another Port is a Good Idea

#184

Post by Nick_C »

gnur wrote: post #103
GalacticDomin8r wrote: post #68

Earlier quoted context omitted.

> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour. galacticdominator% sysctl net.inet.i…

What can go wrong by changing the listening port of sshd? I have changed the port on my vps purely for less clutter in my logs, but I haven't had anything go wrong because of it.

When you have to use the java applet of the Control Panel in your browser to manage your VPS. If your sshd is not on port 22, typically the applet won't find it and you're screwed.

Re: Why Putting SSH On Another Port is a Good Idea

#185

Post by crest »

kijin wrote: post #83
djcapelis wrote: post #3

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 can recommend gatling by passing firewalls on port 443. It waits 2 seconds for a HTTPS request before it starts OpenSSHd in inetd mode.

Re: Why Putting SSH On Another Port is a Good Idea

#186

Post by Quai »

MarkMc wrote: post #140
danielrm26 wrote: post #46

Earlier quoted context omitted.

Ok, fair point. I'd say it differently, though. Instead of defending the original point, which was bad, I'd instead say among all other controls--most important of which is patching, removing passwords, etc.--one control is running below 1024. I could go for that. Except I actually think the gain from being up high (over 60K) is greater than the gain from being below 1024. It's not about being invincible, it's about…

Firstly, I like the tone you used to concede your original point. As to whether the port should be below 1024 or above 60000, I am undecided. I'd love to see some empirical data on this: let's say I run ssh over several days on port 22, port 762 and port 90332. How many connections do I get for each port?

Highest port number is limited by the port field in TCP[1]; a unsigned short (2^16, 0-65535).

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#T...

Re: Why Putting SSH On Another Port is a Good Idea

#187

Post by rly_ItsMe »

city41 wrote: post #6
djcapelis wrote: post #3

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…

Privileged ports are why I disagree with this rebuttal. I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd.

What makes you sure, that the daemon listening on port 22 is is a 'true and sanctioned sshd'? Because of it uses a port under 22?

If you have fear that a port of your server listens on any unprivileged port and it than you have far more problems with that box then the sshd. _If_ a port is opened by a user that emulates the sshd daemon to grab your passwords that means that:

a) this is the usual port you use for ssh

b) your box is hacked, then the real sshd daemon that usualy would listen at this high port is replaced by something else. That means sombody has root access to that box (the sshd has to be killed for that)- big big OUTCH

c) you box isn't hacked but you have some non trustwoth people have access to that box, that use some exploits for rights traversal

All in all I would say, constructing a security issue of using a non standard ssh port is academic. If that could be abused you have far more problems on your system than that changed ssh port.

On our production servers I use the following:

1. ssh access with keywords is disabled 2. ssh access for root is not allowed 3. ssh access is allowed from one trusted IP address only 4. restrict users with access to ssh to only the needed ones 5. users with git access get as shell '/usr/bin/git-shell'

optional: If you're paranoic like me and like some technical baublery you step 3 this way that users have a VPN to the server with the trusted IP

Re: Why Putting SSH On Another Port is a Good Idea

#188

Post by KedarMhaswade »

kijin wrote: post #83
djcapelis wrote: post #3

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 think this is the easiest you can/should do that helps keep random checks and break-in attempts away.

Re: Why Putting SSH On Another Port is a Good Idea

#189

Post by GalacticDomin8r »

gnur wrote: post #103
GalacticDomin8r wrote: post #68

Earlier quoted context omitted.

> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour. galacticdominator% sysctl net.inet.i…

What can go wrong by changing the listening port of sshd? I have changed the port on my vps purely for less clutter in my logs, but I haven't had anything go wrong because of it.

> What can go wrong by changing the listening port of sshd?

Read the article.

Re: Why Putting SSH On Another Port is a Good Idea

#190

Post by GalacticDomin8r »

__david__ wrote: post #102
GalacticDomin8r wrote: post #76

Earlier quoted context omitted.

> Frankly I'd much rather do that then have my server on a non-standard port. Frankly, the problems with key security and management are much worse than are being discussed. Using only keys is fine as long as your keys are secure and you know which is which and control all access and immediately remove any key which needs to be. In a complex environment, this is extremely difficult and more prone to security breaches…

I don't know. In complex environments that try to use passwords, I've observed that the password spreads until everyone knows it and then nobody can change it because "everyone already knows it and it would be a pain". Keys allow fine grained access and can theoretically be way more secure. On the other hand, the last place I consulted for had their private key for production checked in to the main git repo, unencryp…

> Keys allow fine grained access and can theoretically be way more secure.

This is true but as often is theory and "life" don't agree about the practice. This is exactly my point. If you could enforce a non-blank password on keys then I would change my tune at least a bit.

Post reply on HN