Hacker News Reader

Comment by djcapelis | Hacker News Reader

  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
  nc: bind to source :: 14 failed: Permission denied
  nc: bind to source 0.0.0.0 14 failed: Permission denied
  nc: failed to bind to any local addr/port
  djc@capelis.dj:~$ nc -l -p 1414
  ^C

See the difference?

(Edit: The original blog entry has now been edited to slightly clarify the wording. But the update mostly seems like an attempt to rapidly justify the author's original point.)

View on HN

His argument is that we can't be sure whether we're talking to the real SSH running or some rogue SSH run by an unprivileged user. That's why SSH servers have their server host keys with fingerprints you're supposed to verify using a different channel when first connecting: if someone managed to spin up a rogue SSH server, it would have a different host key and you would get a big fat warning from your SSH client that the server key doesn't match.

Could a non root user just read the host keys from sshd, then kill it and serve them? Or could it even just MITM it?

That's what file system permissions are for, on the private key.

(I might be wrong about this, but...) I've seen quite a few instances where SSH refuses to let people even try to log in if there's a chance that a private key has the wrong permissions applied, so as to minimize the risk of someone accidentally letting others read it -- as you suggested.

You'll find the default SSH config on the more noteworthy Linux distributions to do this 90% of the time time without even asking :)

No, they couldn't. sshd usually runs as root* so it can create shells for in user that's logging in. Therefore, only root could kill the daemon. Also, as mentioned by the sibling post, its configuration files are usually(if not you have a serious problem) only writeable by root so nobody else could modify them.

* Note, I guess you could run an sshd that only allows logging in to a single user and runs as that user but both points above still stand even in that case.

Could a non root user just read the host keys from sshd,

No, file permissions.

then kill it and serve them?

Users with uid != 0 cannot kill other user's processes.

Or could it even just MITM it?

No, host key verification ensures that you are talking to the intended ssh daemon without packets being intercepted. The host key is a public key of the SSH server, which is verified by the client to be the key registered for that particular host. Since only the server has corresponding private key, the MITM cannot eavesdrop on the key exchange.

Run it on a port where (port != 22 && port < 1024). Problem solved. Not every non-standard port is unprivileged. Lots of people run SSH on port 443 to get around firewalls.

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 run ssh in a non standar port and its annoying to always specify the port. Thank you for the tip about ~/.ssh/config

I agree but I think TFA should clarify that it's probably a good idea to run sshd on a non-standard port < 1024.

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

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.

Have a look at SSHFP[1] DNS resource record. If you combine SSHFP record with DNSSEC, you can actually validate the fingerprint.

[1] http://tools.ietf.org/html/rfc4255

monkeysphere is how you deal with your SSH keys. It's pretty awesome.

http://web.monkeysphere.info/getting-started-ssh/

So I figured I'd share it here: https://news.ycombinator.com/item?id=6617132

They just need to scan once to find the port speaking SSH, then brute force as usual.

If you want actual more protection run a bogus SSH (with no login allowed) on 22 and a thousand unused ports... then they have to try them all or guess which port is actually able to log in.

OTOH, not running on port 22 prevents you from drive by scans.

You are right that it doesn't protect from a targeted attack. In my experience (10 years as a sysadmin and dev), I've never had a targeted attack -- all the attempts against my machines are drive by.

Having port 22 open can end my IPs on a list of "let's try to break later".

It's not close to a complete solution, but I find it beneficial.

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

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

That's excellent! Thank you for pointing that out.

Ideally, you can run both https:// and ssh:// on 443, with sslh.

Everyone who's expecting to see HTTPS will see it on :443 as well.

I would never have known about this had I not read this article and the comments here, and have been running SSH servers for a very long time.

The solution I'm particularly fond of is mentioned in Daniel's blog comments, which is to use iptables to block externalip:22 and redirect a non-standard port to localhost:22.

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.

I think this is the easiest you can/should do that helps keep random checks and break-in attempts away.

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.

To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. Many of the lower numbered even-numbered ones are good options as for historical reasons those are all mostly unassigned. (Pretty much any even number below 16 isn't used by much.)

But I agree, the privileged ports point isn't something that should be brushed aside.

> 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.ip.portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023

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.

It introduces a communications problem. Which machines are running SSH on a non-standard port and what is it? Plus some tools are harder to set up, IIRC SVN+SSH is one of them.

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.

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

Read the article.

How can you ever tell that by port alone? If a box has been exploited, it's been exploited.

Exploiting a single user's account and opening a high port is not the same as getting root on a system.

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.

Or instead of doing a script or a patch, you could just do the right thing in the first place and run your daemon on any of the literally over one thousand ports set aside for privileged services.

Running on a privileged port doesn't change which other hosts can connect to the privileged server though. At best it tells the client that the server is probably running as root (or has the appropriate capability bit).

If you're worried about an impostor sshd on that host then I would tend to agree that it's simply not prudent to be connecting to that server at all, let alone passing key material or credentials.

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.

The absolute best way to know that is to know the public host key and verify your keys. Additionally, you don't have to resort to high ports to achieve a best of breed. Just !=22 is enough to avoid majority of skiddies.

> I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd.

You don't get that from it being on 22; you get it from verifying host keys.

> You don't get that from it being on 22; you get it from verifying host keys.

You know how you just wrote a blog post talking about how more layers of security are better even if all you're gaining is obscurity? This isn't an exception. And it is a valid point that by moving from a privileged port to a non-privileged port, you just traded away a layer (arguably a more useful one than you gain by moving away from 22) for absolutely no reason. (You could move to a different privileged port and still get everything else.)

tl;dr: You advocate giving up an actual layer of protection for a layer of obscurity. This is especially puzzling when you could get both.

Further, the reality of the situation is that as a practical matter most sysadmins are terrible about key management and when they see those warnings the very next thing they almost always do is immediately delete the key and hastily attempt to login to the machine via ssh. (The better ones to see what's going on and try and fix it, and the worse ones just assume that the key changed because sysadmins change keys all too often without notifying users and don't investigate at all.)

It turns out that humans are annoyingly predictable.

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 not being a target at all.

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?

For 90332, I suspect not many :)

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

Privileged ports isn't an example of security through security. Maybe you could call it security by convention. Still, it relies on a number of assumptions, none of which can be relied upon if a system is compromised, and if the system isn't compromised... well, you don't have a problem now do you?

Honestly, the only win of a using "privileged ports" these days is you don't have to worry about the odds of some other service randomly binding to your port. Since most systems spin up ssh well before they spin up services that bind to random ports, and generally don't ever shut down ssh, that isn't much a win, but either way, it is NOT a _security_ win.

> you get it from verifying host keys.

You might be surprised how often StrictHostKeyChecking is no. Are you checking it on your active installs?

Then bind to another port under 1024, so it's privileged, but not port 22.

How are you going to log in to your shell, with your environment, without a daemon that has the suid bit? A user can never install such an sshd without having root permissions at some point.

If you run ssh on a static port, then it really does not matter whether it is 22 or 2200, as long as it remains static, and everyone knows the correct port.

If it turns out that that daemon is logging your passwords, then someone has already compromised your host.

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

If you have random people spinning up daemons on your servers then you don't have an SSH problem.

UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out.

You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there.

Also it isn't uncommon at all for an attacker on a server to get access to a regular account and not a root account in their initial vector. It is often too easy to escalate, but do you really want to help them out more?

In fairness, multi-user linux systems have been losing popularity for a long time, with KVM/xen-based VPS services taking over for having significant advantages in security and software compatibility.

A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.

I think you're misunderstanding - GNU/Linux is a multi-user OS regardless of if it is run in a kvm/xen/etc container or on bare metal.

Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.

Yes, but he's noting that a younger engineer may have never encountered a system with multiple users, so wouldn't think that being able to open a privileged port is more terrifying than being able to spin up netcat on 10032.

This is absolutely true. But unless people have started to also run their webapps and other daemons as root, the boundaries still cling to relevancy.

But maybe I just miss computers where finger, write, wall and talk were all useful commands.

And people say things are more social now? The growth of hypervisors made our operating systems desolate and lonely! :)

The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. The ability to spin up a daemon on port 22 on your server, however, would be called a privilege-escalation exploit waiting to happen.

If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea.

(...until, you know, we finally start using DNS service-records for this sort of thing.)

> The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit.

No, that is very, very wrong. This is SOP for an account on a system

nc -l 9000 <- spinning up a daemon on your server

Rather, the ability for someone who isn't considered to have an account on your server, to spin up a daemon on your server.

Something as simple as an exploit against a php script could lead to unprivileged code execution & something as minimal as memory exhaustion could kill off your sshd process. If the sshd process is killed, and the attacker knows what port it was on (netstat -na | grep LISTEN), the attacker could spawn their own daemon on the unprivileged port that was previously being used for sshd, and that daemon could be used to collect plain-text passwords that people try to use when logging in. Heck, they could craft their daemon to log all keystrokes & which could grab the local root password.

This is a very valid point and a good reason to choose a port in the privileged range if you use an alternative port for SSH. I wonder, though, what is the worst it can do if you don't use password authentication? E.g., to offer you a fake shell and try to capture your sudo password a rogue daemon would have to have access to your public key, which as an unprivileged user it shouldn't.

Reply on news.ycombinator.com