6 ms·

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

• city41 13y ago
  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.
  • djcapelis 13y ago
    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.
    • GalacticDomin8r 13y ago
      > 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
      • gnur 13y ago
        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.
        • lttlrck 13y ago
          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.
        • Nick_C 13y ago
          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.
        • GalacticDomin8r 13y ago
          > What can go wrong by changing the listening port of sshd? Read the article.
  • jerrya 13y ago
    How can you ever tell that by port alone? If a box has been exploited, it's been exploited.
    • sp332 13y ago
      Exploiting a single user's account and opening a high port is not the same as getting root on a system.
      • MichaelGG 13y ago
        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.
        • djcapelis 13y ago
          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.
          • mpyne 13y ago
            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.
        • petsos 13y ago
          Look at it a different way. If a bug was found that could kill sshd, then a local user could replace it.
  • brooksgarrett 13y ago
    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.
  • danielrm26 13y ago
    > 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.
    • djcapelis 13y ago
      > 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.
      • danielrm26 13y ago
        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.
        • MarkMc 13y ago
          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?
  • clamprecht 13y ago
    Then bind to another port under 1024, so it's privileged, but not port 22.
  • jvdh 13y ago
    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.
  • rly_ItsMe 13y ago
    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
• pepr 13y ago
  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.
  • dave1010uk 13y ago
    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?
    • xarball 13y ago
      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 :)
    • entropy_ 13y ago
      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.
    • danieldk 13y ago
      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.
• danielrm26 13y ago
  If you have random people spinning up daemons on your servers then you don't have an SSH problem.
  • djcapelis 13y ago
    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?
    • fragsworth 13y ago
      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.
      • akl 13y ago
        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.
        • cdcarter 13y ago
          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.
• kijin 13y ago
  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.
  • dawkins 13y ago
    I run ssh in a non standar port and its annoying to always specify the port. Thank you for the tip about ~/.ssh/config
  • simias 13y ago
    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).
    • reidrac 13y ago
      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.
    • cagriemer 13y ago
      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 http://tools.ietf.org/html/rfc4255
    • deleted 13y ago