Why Putting SSH On Another Port is a Good Idea | Hacker News Reader

Why Putting SSH On Another Port is a Good Idea

danielmiessler.com

293 pointsdanielrm26187 comments

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

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

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.

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.

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.

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 dimension of attack is when an attacker is focusing on your IP address specifically. Then he probably is going to nmap your IP and discover which port(s) SSH is running on. Changing the default port for SSH doesn't help here, but this use case is far less common.

Like others have said, changing port doesn't remove the need for security measures (cert-based/passwordless login, disable root, fail2ban) but it reduces any of those even being tested in the first place when most of your attempted attacks are IP-range based.

Turning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.

Attacks on port 22 end up consuming CPU.

and attack on other ports don't?

The assumption is that bots don't usually scan other ports: way too inefficient for them to scan all ports for every potential target host.

fail2ban

And now you have another exploitable venue, the log parser of fail2ban ;).

Personally, I trust netfilter/iptables' rate limiting more.

Even better yet is pam_abl. If any IP or user fails authentication faster than a configured rate pam_abl will block logging into that user or any authentication attempts coming from the same IP address and it's all nicely tied into PAM so you don't have to worry about yet another fail2ban vulnerability or someone spoofing some important IP address and tricking your server into blocking it.

Using pam_abl to disallow logging into an account that is being hit sounds like a easy way to DoS a box.

Bots frequently exploit changes that were recently fixed upstream. Not perhaps 0-days, but maybe a couple days after the original fix. How up-to-date do you really keep your SSH server? On the off chance the attacker gets to an exploit faster than you get around to updating your machine, then keys won't keep you safe. Using a non-standard port in that scenario might very well save you from the botnets, if the GP's argument about the dimensionality of attacks is correct.

> 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 than password access.

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, unencrypted. :-/

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

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.

It's more of an annoyance. If you require password based login, port 22 will lead to constant attempts that fill the logs. Move to any other port,and you'll see none.

Curiously, that was my primary motive for moving SSH on a couple of servers off 22. It had nothing to do with any notion of security and everything to do with the annoyance of filling up my auth logs with mindless login attempts by dozens of bots.

Maybe that's the wrong reason, but irritation can be a decent motivator. :)

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.

In moving sshd to an alternate port, I've noticed two things: a greatly decreased amount of log noise from dictionary attacks, and a moderately increased amount of portscans.

It's reasonably clear to your average net malfeasant that any host running recognizable services is going to be running sshd.

So why not do both?

Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you swimming in interesting data.

Then run real sshd elsewhere, possibly filtered, possibly port knocked, and hopefully permitting key-based auth only.

And use sshguard, because the only thing you should care on a secured host is power consumption. One of my boxes went to 33% on all CPU threads during a sk attack.

I've done this in the past with some pretty good results. Though, I've dropped it because I found myself constantly locking myself out of my own machines.

I can't deny, it is a cool technique though. PortSentry is a good tool to use for just this. Anytime someone came to :22 and the machine just disappears.

Try kippo, it's a whole bunch of fun. Redirect the port in iptables to a kippo VM to stay safe as well, but I don't think anyone's broken out of it.

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 transparently just transmit data between your client and the remote server, irrespective of what that content is. In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy.

You can use this to tunnel ssh through an HTTP proxy. Putty supports this out of the box, but if you're using openssh, you'll need corkscrew also.

You can always try to tunnel to an ssh server on port 22, but most proxies will hand you HTTP403 on any CONNECT request to a non-port 443.

More info at http://daniel.haxx.se/docs/sshproxy.html.

I use sshttp for this - support for both port HTTP and HTTPS. I don't serve any webpages, but I wanted the option to also use a more aggressive SSH holepunch on the same port, and just naked SSH if I could.

> 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 through an HTTP proxy.

That would be a MITM against https and it doenst work that way.

If you would go over the http proxy to connect to your sshd on port 443, that would be stupid as the proxy would see your connections. Its much easier and better to just connect directly without asking the proxy.

It can work like this - see: http://wiki.squid-cache.org/Features/HTTPS#CONNECT_tunnel

Right. Sorry, in case I wasn't clear, the HTTP proxy acts as a proxy for HTTP on port 80, but tunnels HTTPS traffic (and anything else including ssh) on port 443. The tunnelling is done using the HTTP CONNECT verb.

He's right that "security by obscurity" isn't the entire story -- it's more like a mnemonic device for the more complex idea that:

1. In the real world, security resources aren't free.

2. Security decisions are made by users.

3. Humans will engage in risk compensation [1]

4. Setting policy doesn't change people's brains, it just tells them what to do.

5. It doesn't matter what you intend, it matters what users actually do.

The upshot of this is that any security policy that is highly visible and highly inconvenient will reduce your security, and has to have a substantial benefit to justify its cost. You can say "I'll do stupid port reassignment tricks, and I'll also mandate that passwords are forbidden, and require that private keys be managed properly" but at three in the morning when the whatever is overdue and not working what you're gonna get is:

I'll just do password auth with root:root, nobody ever hits port 24601 anyway. Besides, look at this page [2], using a strange port makes me invisible like the Predator and makes me four thousand times more secure! I really want to believe this so I do.

Also, subverting scanners is an anti-security move, not a pro-security one. Scanners are a helpful tool to identify what the hell is running on your network. Your security efforts have to find every hole, the bad guys only have to find one. Don't put yourself at an even bigger disadvantage by making your systems harder to analyze.

[1] http://en.wikipedia.org/wiki/Risk_compensation

[2] http://www.danielmiessler.com/blog/security-and-obscurity-do...

I agree with the sentiment of your post, however, I'm not sure if for the kind of user who would put a root:root shell on port 24601 the alternative in the absence of the article [2] wouldn't be putting the same shell on port 22. The former at least has a better chance to stay uncompromised until somebody comes in to fix it.

Edit: I also wonder if a passwordless root Telnet would last longer. :-)

I think you're making some assumptions about people in your argument.

This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful.

Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argument shouldn't even be present about that point. Changing the SSH port towards the internet is a very pragmatic solution to spam in your logs.

I know people will mention fail2ban but I'd rather not have a log parser running day and night on every internet facing server when I can just change the port and get rid of all that spam Forever. (I have yet to encounter one robot that can dynamically scan for SSH ports and use anything else than 22).

Also, in my personal opinion, using a high port like 24601 is insecure because if your SSH daemon ever crashes then an unprivileged user on your system can listen on that high port and receive your precious connections. So personally I always use an alternative ssh port under 1024.

> security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful.

That's ok. Just don't pretend that you are getting anything worthwhile from that policy. All you get is a 10 bit door, added (not multiplied - so, it does not increase your overall security) to whatever security you already had.

In computer security, people normally consider anything with less than 64 bits worthless. A 10 protection can be brute-forced by hand.

As humans work, changing that port is a clear indicator of an admin that didn't care about avoiding the less secure modes of SSH. If you are looking for obscurity, I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable".

> I'd consider a non-standard port (and concern about bots) to be a huge flag announcing "This system is exploitable".

Every system is exploitable. How is changing a port indicative of someone who did nothing else to secure their shell access? I keep all mine on 22, but have been considering moving it just to keep the logs a little more sane for when I actually have to read them to find something.

It really isn't difficult to write such a robot, it just involves a port scan before actually probing. Using bash, something like:

  nmap $host | grep -i open | cut -d '/' -f 1 | xargs -I {} ./sshscan.sh $host {}

Where the contents of sshscan.sh is something like:

  #!/bin/bash
  
  nc $1 $2 | grep -i ssh
  if [ $? -eq 0 ]; then
  # ssh probing stuff here
  fi

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

Seriously, I think "wary" might be the most-misspelled word in the English language right now....

They're are much more common culprits out their.

http://grammarist.com/usage/wary-weary/

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.

Except unless your only target is that one tank you're not going to scan all its ports.

In my experience most of the time "attackers"/script-kiddies just scan over a range of IPs for port 22, and if it's not open on your computer, they just move on to the next IP. That's why you get thousands of requests for port 22 and very few on say port 21.

Of course, not that it would stop someone willing to spend more than a few seconds on attacking your server, but still makes the camo analogy a quite nice one in my opinion.

Or, you put up a fake, camouflaged tank and let the enemy reveal themselves when they attack it. (Leave 22/tcp open as a honeypot, triggering an immediate iptables drop).

As I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that:

1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.

2. The security it adds is itself bad (sent in cleartext, easily brute-forced)

3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).

And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.

I changed it because it makes FreeBSD's nightly security run output not contain thousands of lines like this:

    Jul 28 23:53:57 hostname sshd[1068]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55040 ssh2
    Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
    Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
    Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2
    Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
    Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
    Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2
    Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2
    Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2

Here is an even worse log output nightmare: Enable logging in the firewall/ids, which show all packets sent to a closed port.

It's massive. Endless. Like looking into the endless void.

Of course, my computer does not log packets that are just bouncing against my computer. It would distract me too much, and maybe it would do so for you to. Easier just to tell the computer to not bug you about it, and trust that the "attack" is harmless enough so to not to bother logging it at all.

This is the default email that a freshly installed FreeBSD sends you every night. It also contains a bunch of other bits. That's a bit different than subscribing to firewall spam.

It follows, obviously, that creating these log entries in the first place (much less reporting them) is a silly thing to do, just as receiving firewall logs for every packet to a closed port would be.

So does this:

ChallengeResponseAuthentication no

PasswordAuthentication no

For some reason I can't upvote you.

Clear your cache: https://news.ycombinator.com/item?id=6616972

>1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.

Aren't there rate limiting tricks you can use to impose great cost on searching for the correct port?

There are more effective rate-limiting settings in the SSH daemon, and these have the bonus of not impairing the functionality of the rest of the TCP/IP stack.

Everyone else is chiming in with their anecdotal proofs, so I will with mine.

Yes, if you have a long password or key-only method of logging in, and disable root login, and patch the daemon, then party on.

But for the extra bit of protection against 0-days and bullshit amounts of logs from quick port-22 only scans on your network, it helps to move it to another port. This is why I disagree with your mathematically founded reasoning. It doesn't fit with real world scanner behavior.

If it's just your home network, it's not confusing because only you use it. If it's a corporate network, then using putty might be a little annoying, but it's not hard to communicate another standard.

> But for the extra bit of protection against 0-days

I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional.

That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program.

But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers.

> and bullshit amounts of logs

This is a separate problem, better addressed by adjusting SSH to not log stupid amounts of stuff in the first place.

The "change-port" discussion for SSH is so boring :-/ OpenSSH is I guess the most secure daemon on all your servers. People should more think about to change the HTTP(S) ports of their non-public facing sites and other daemons and frameworks they use.

> OpenSSH is I guess the most secure daemon on all your servers.

Probably correct. However, sshd should be the only public facing daemon that hasn't dropped root privileges immediately after binding to its privileged port.

So it should be the only daemon that can directly offer root privs to an attacker.

I say "should" because it's a big world out there and people do some bizarre and indefensible things. Sometimes merely lazy things, but the net effect is the same.

It is almost the same thing to offer non-root privs, because of the great number of patched and unpatched priv escalation holes in Linux. Almost guaranteed you will be able to get root if you get normal user privs.

Better solution: require VPN connectivity and don't expose SSH on any port to the public Internet.

Running services on non-standard ports will make the next admin that takes over this server want to track you down and smother you in your sleep.

Here is something to think about, the author is right, but if you follow many ssh setup tutorials that say to move to say port 25000, you are less likely to be port scanned than the default, but still more likely than if you had used something totally random like say port 42 or 818. By me even writing this clever hackers will start scanning those ports too, just to be sure they are hitting everyone. That being said, any port is better than the standard one and picking an unused port instead of the standard ssh port will give a reasonable 80/20 benefit for a lot of people.

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 being attacked by someone in class 1, then moving your port gives you absolutely no protection. Thus moving your port is only worth anything at all if the percentage of class 2 people is significant.

However, if you also consider the probability a person in each class has of actually compromising your machine, then the security looks less convincing. Yes, it might be true that 95% of people don't bother to use a port scanner, but the most competent hackers are almost certainly going to be in the 5% that do use one.

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.

Yes there is. It's called economics.

Anyway, those 0.999999 that don't scan the ports are doing lame attempts of guessing the password of your box, while the 0.000001 is doing that, but also trying new exploits that have a chance of working.

As a consequence, the chance of one of those 0.999999 bots invading your computer is zero, the chance of one of the 0.000001 doing the same is non-zero.

Who is going to bother with a portscanner when there are plenty of targets on port 22. The targets on other ports are more likely to have been set to use keys, or at least have better passwords.

When you set the system to use keys, all those attempts at accessing just don't happen, and the log does not get polluted. Since the log pollution is the main complaint of people that change the port, I think you are wrong.

If you want to defend against port scanning just open some honeyports that ban all connectors. Maybe randomize these every X hours.

There are indirect scanning techniques that induce and measure traffic from ordinary non-compromised hosts. When the attacker notices that he gets banned for scanning he'll do that.

http://nmap.org/book/idlescan.html but IIRC there are more ways than this to do it.

Standard or not standard port, you still should use port knocking in a way or another (or only enable it for the specific IPs that can access it ever). Internet don't even should be able to know that you have there a service that is only for you or for a very small amount of people.

If a remote vulnerability is discovered in the server (happened in the past, don't rule it out for the future), you will be attacked, and it won't be a brute force attack to be blocked by fail2ban or similar. You can be scanned in any time, put in a database as "having ssh version x running in y port" and get ready for future use.

And if well simple port knocking could be defeated inspecting your traffic, there are variants like fwknop that are resistant to that kind of interception or replaying.

Agreed. Contrary to the naysayers, port knocking is an unalloyed good.

Whatever your setup is, it's better if it doesn't show up in a scan at all.

The "knock is a weak password" argument is silly - nobody suggests using only the knock, but rather to use the knock in addition to your existing auth scheme.

Its kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem.

So why not solve the problem with something a little more proactive like turning off password auth and go for sshkeys only. Maybe toss in something like fail2ban if you want to interrupt kiddies scanning your boxen.

That said high port ssh can be nice if you're frequently on restrictive networks and getting out on port 22 is impossible.

edit(spelling)

I think you've missed the point. Ultimately, moving the port isn't securing the service but is just one more layer. It won't hold against a focused attacker but will hold against a majority of casual scanners just looking for a large number of SSH targets. The goal isn't to do keys OR move the port. The goal is to combine all the factors at your disposal to disrupt and discourage attacks.

I completely agree, moving the port is a must just to change up the configuration from everyone else's. Configuration items like port numbers are meant to be tweaked, especially when you can just stick a unique SSH port in your ssh_config.

However, it's not hard to imagine these scanners have moved further past the days of the Morris worm and aren't just simple port scanners. Identifying what services are on what ports is a relatively easy process that doesn't remove much from the discovery phase of a bot or script kiddie. Hell, code review metasploit for a half hour and rip theirs out.

Yes, you have pointed out - a targeted attack.

What if non-targeted attack like a robot scanning all port 22 in your datacenter?

Thats where fail2ban is useful, pick a number of failed auth attempts on any service you care to integrate, lets say 8 PAM failures, and trigger a rule that inserts an iptables rule to drop/reject the attackers IP for 5minutes. That will time out the ssh scan for all but the most patient scanners. If you shared the fail2ban database across hosts you could inject null routes for the offender into your router or block them at your firewall.

I think you have missed the point - you should tell why using non-standard port is less secure, not provide me an alternative, because I would also argue VPN is better fail2ban.

You cannot neglect the fact that there are vast amount of bots scanning only port 22 in the Internet. We know this because we have found the evidence in our OWN logs, not from those security experts always saying security through obscurity is bad and therefore we should do nothing.

Because moving your port has an opportunity cost.

Documenting and configuring it has a non-zero cost which could be spent doing something else more impactful.

I've never seen an infrastructure where there was a sufficiently advanced state of security such that obscuring the port numbers of services was the at top of the todo list.

Unless people recommending these things work for shadow organizations I've never heard of, I'm pretty sure it's something done without any kind of cost-benefit analysis.

What are the odds of a SSHd zero-day? Or, more specifically, what are the odds that someone with zero-day knowledge would be so stupid as to decide to risk the vulnerability being discovered by others by using it in a horizontal search of all running SSHds?

Because it has to both be more likely than any other attack that could be mitigated (and port obscurity would have to be the most effective solution) with the same effort.

Pretty sure that for virtually all infrastructures, auditing that your systems are properly isolated, users and services have the least privilege possible prevent massively more probable attacks, and that firewalling services or port knocking or really anything are more effective solutions for this attack.

Well, apparently with Zmap [1] you can do internet-wide scans in less than an hour from a single host, so I can't imagine they'd have that much trouble finding any open SSH ports on a smaller IP range.

So just changing the SSH port will do little, but enabling port knocking would help it stay hidden.

1. https://zmap.io/zmap-talk-sec13.pdf

"Less than an hour" is with gigabit internet, which is rare for an attacker to have.

With a 100 Mbit/sec connection, that would become "Less than 10 hours". That's still quite fast.

One question, why people always say that disabling passwords is important. AFAIK, passwords with keys is better than keys only. Now if someone gets the keys they can access the service with those keys without the passwords. Disabling passwords just makes security in one way worse. Think about chip & pin, because you have your credit card, wouldn't it be smart to disable PIN completely? Of course key ring could be encrypted, but that still allows off-line attack against it. If password is queried on-line, you can limit password attempts which you can't do in off-line situation. - Thanks

Disabling password-only authentication doesn't prevent you from using a password on your key. When you login with key-based authentication you will be prompted for the password for your key, even if password authentication is disabled, because they are two separate & unrelated processes.

Anyone use Dome9? (http://dome9.com) they close all of your ports and open them on demand via chrome extension or mobile app for when you want to use SSH.

Seems kind of like inetd? Except having to trust the reliability and availability of a remote provider to manage it for you?

There's nothing inherently good or bad about running SSH on another port. Honestly this argument is a bit silly given how easy it is to port-scan and many scripts out there will do that before actually trying anything. Essentially all you're going to do is make things annoying for your users.

The really real good idea is running a VPN in front of all of your servers and never allowing SSH access to the outside world. I have two ports (at most) open on all of my servers: 80 and 443. OpenVPN takes less than an hour to setup. There's no reason not to set it up!

Agreed, VPN via physical firewall is a particularly nice solution.

Sounds like you've offloaded mail, dns, etc. elsewhere if you only have at most 80 and 443 open.

That was very fair response. Kudos for being able to attack the points, not the person.

It's probably already been said, but it can be said enough: Security through obscurity is valid for marginally increasing the total security margin, but relying on any one practice or technique always smells like a dangerous approach. (Hence the hollistic practice of many overlapping features providing defence-in-depth.)

Changing ports reduces the threat surface in limited but practical ways, however far more effective would be using secure port knocking (say fwknop with GPG and is also time-based).

Secure port knocking and changing ports together would be perfectly valid. In fact, I have deployed these for openbsd jumpboxes guarding core infrastructure. So breaking in would require defeating fwknop with GPG and ssh.

(If anything needs public auditing, it's GPG and SSH. VPN code also considering the logic often makes OpenSSL look simple. )

By experience, it just lets you avoid getting a shitload of brute-force attacks. So I do it.

On my personal boxes I use a combination of non-standard ports, disabling password auth (seriously, this will do more for your security than anything else), and fail2ban. Even with key authentication fail2ban still blocks several IPs a day.

I apologize but there is no such thing as "it is (ALWAYS|NEVER) a good idea" no matter how many blog posts people wrote about that.

It just depends on which are the tradeoffs between the antithetic goals that you have when you do any kind of security hardening.

Aside from that, since many already mentioned port knocking as another layer in the pile of this game, let me point out that not all port knocking (-like) implementations are that weak, look e.g. at knockknock [ http://www.thoughtcrime.org/software/knockknock/ ].

Wasn't it posted on HY that modern exploit tools like metasploit scan all ports for SSH services by default now?

That was my biggest reason not to bother changing the port.

Is there any real reason beyond that? (I do use fail2ban to block repeated attempts.)

He's overreacting a bit. Port knocking is not just an "obscurity layer". It's more akin to a PIN or weak password.

The condescending opening is a tip off ("people who almost understand the topic").

Even so, it is still a very weak security layer that you are adding on to something that is already very secure. Does that really make it less secure?

Now running SSH on a different port is an even weaker obscurity layer, but still, it still adds some security.

I think nobody is denying that it adds security. The question is, does the added security offset the increased complexity and associated difficulties?

This is, I think, the only valid argument against knocking.

The standard (and always condescending) responses are that it is either a very small password and/or that an attacker can record and replay the knock from an eavesdropping position.

Both of those are true, of course, but they neglect that the knock is always in addition to whatever else you are already doing to protect ssh.

So I have always rejected those arguments and continue to evangelize for port knocking.

BUT, the added complexity part is a valid point. I try to keep systems as bare and simple as possible and hate to add even a single unnecessary dependency package. I am happy to say that (on FreeBSD, at least) knock[1] is light, simple, and has run for thousands of days on busy production servers as well as my personal servers without even a single incident.

[1] /usr/ports/security/knock

I used the word “complexity” not in the meaning of “the installed system is more complex for having more software in it”, but in the sense of “I don’t want to feel like I’m entering Diagon Alley just for wanting to use SSH” – i.e. complex to use, not complex to set up.

But your interpretation works too – they are both valid arguments, in my opinion.

How about: Why it doesn't matter what port you run SSH on

* Because anything but the IP address of your office or VPN connection should be blocked at the firewall level for that port

I'm with you on that one. Setting up OpenVPN is a day worth of work at most and gives you the freedom not to have to worry about this stuff in the future.

Why would I use a VPN when I have SSH? IE, why do you think that a VPN is somehow more secure than an SSH connection?

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?

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.

VPN into it?

Yes, in a sense those things are mutually exclusive.

You can get in a network by VPN or SSH. Yes, after that you can also log into a computer by SSH, but the question remains - why access the network by VPN instead of SSH?

Let's start with a secure implementation for remote access:

1. SSH:

Port - 22

Protocol - 2

PermitRootLogin - no

StrictModes - yes

MaxAuthTries - 1

PasswordAuthentication - no

PermitEmptyPasswords - no

ChallengeResponseAuthentication - no

UsePAM - yes

2. PAM_ABL (auto-ban by account after three retires)

3. IPTables (auto-ban by IP after three retries)

So in the above implementation an attacker has three attempts, max. This means the logs are quiet, yet accurately depict intrusion attempts. This also stops brute force attempts in their tracks and requires no exemptions to normal workflow.

If, under the above circumstances, I were to obscure the port as well, this would serve no purpose than to completely side step script kiddie brute force attempts (as minimized as they would be in this configuration) with the horrific side effect of forcing my users to maintain (at the least) a config entry for the custom port assignment. Which, by the way, would become perpetually worse with the amount of servers and users in play.

This is why obscuring the port is such a bad idea.

And if you still want to obscure the port because the server, or network device, in question should only have occasional access by an extremely limited group of people, then just throw on a white list and possibly restrict access only through another server. Both provide more security than moving the port.

And moreover, this article isn't even about SSH. It's about the semantics surrounding the usage of the term "security through obscurity" in the previous article. Which is hilarious to me, as both articles are full of shit. For one, the security implications of non-privileged ports is moot as the attacker already has access. And two, being less likely of a target is still being a target. Those five people who found the port in the test sample. Those are the ones who win most likely to exploit; not the thousands of script kiddies brute forcing you.

Your time would be much better spent obscuring the actual version information for the service than the access point to it ...

(Reposted here, as the original site went down.)

So, the guy's point is that if someone has access to your machine, then it's ok to make life easier for them to run a fake sshd?

I still can't understand why things like port knocking or single packet auth schemes like fwknop never really took off ...

I run SSH on port 22, but occasionally (when I travel) I will run it on port 443. Yes, know 443 is used by HTTPS, but:

1) I don't run HTTPS on the box I SSH into

2) I might hit an overly restrictive WiFi that only allows traffic out over HTTP and HTTPS

Which is another reason why you might not want to run SSH on another port. You might not be able to reach it.

I run my ssh server on port 443 in addition to 22, because some network connections block anything except 80 and 443, and this allows me to easily proxy through that broken network connection.

(Actually, I appear to have stopped doing this. But it's something to consider if you are on weird networks on a regular basis.)

Amend the title to include (if you run only one SSH daemon and you're the only one who needs to access it).

Then I agree.

Otherwise, hell no.

I posted the original because I thought it was interesting. Elated to see an honest response. I love HN.

Better yet, put a firewall in front of sshd and only allow connections from your management network ;)

Is there a way to increase the privileged port range from 1024 in linux? If it's set to a high enough number, say 1024*1024, that would solve both problems (we could use a large port number for ssh and not allow non-root users to hijack the port).

1024*1024=1048576 TCP port is a 16-bit value i.e. only values between 0 a 65535 are valid, it's not a wide range at all

After pondering this article, I think the only reason to run SSH on a different port is to prevent zero day ssh authentication bypasses, which I don't think is a decent reason -- I'll eat my hat when this happens again.

I think he mentions port knocking precisely because he DOES understand point #1 ( the difference between security through obscurity as a layer but not your only layer), and is giving an example of using it as one such layer.

I don't change the port, but use keys and instead allow a tiny, tiny subset of the the internet to talk to my servers on 22... my networks.

Very little hassle, no crap in the logs. Is there a drawback I'm missing?

So really the only problem you had with the argument is the security via obscurity? Yeah, me too. Otherwise, his point were spot on and you didn't address them directly.

A daemon that blocks the attacker address after a number of wrong attempts is much more secure. IMHO moving SSH to another port is kind of Cargo Cult Security.

I still don't see any reason to change the port. Use only key auth. Problem solved.

if you have sshd on 22 you get 1000 hack attempts per day. if you move it somewhere else you probably get none the whole day.

the chance to get hacked is way higher. why would you not want to lower the risk?

while I agree with most of the things in this article, he states the obvious...

Don't understand how this article got to the main page and it's still here after more than 11 hours.

Thanks for writing up the same response I had to that article.

a: $port != 22 is enough to thwart most bots and skiddies. If you think the port number is a guarantee that you are safe or that you are communicating with a blessed ssh you are sadly mistaken.

b: Uhh the port number means nothing. Host keys are there for a reason... Someone does not understand the functions of SSH. http://www.snailbook.com/ <- great book

c: If you are not investigating fingerprint issues when logging in via SSH and you call yourself a sysadmin, please stop. You are going to be the reason your company ends up in the news because your shit got owned and 2,000,000 user account hashes were leaked blah blah.

d: If you are not using key based auth and you have a fly by night keystore policy. Which means you have a keystore - stop. The whole keystore for SSH shit irritates me. I cannot tell you how many times I have heard sysadmins say a that a single private key is a "best practice". It is not a best practice it is a stupid practice and really prevents you from protecting unauthorized logins on other machines for the obvious reasons.

   Put your public keys on bitbucket.com or source 
   management. Put your private keys on an encrypted disk
   in an encrypted archive if you must. This is still dumb
   imho because it is not needed.

   Leave one account (root) with console only/no ssh access
   that will allow for keys to be revoked/recreated when
   users need new keys.

e: The original article http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-... Is wrong and misguided. port knocking or knockd is an obscurity measure, precisely the kind he argues against. The linked article from the OP calls this out.

f: Spinning up daemons is a big deal for non-priv users? So spinning up a remotely accessible Lisp out of emacs from a screen that is running in the background is bad? Hmm, here I thought that computers were meant to be tools for humans to get work done... Sorry, background processes are part of getting shit done. Users should be able to spin up the stuff they want to spin up in the network segments they have access to without the bureaucracy of misguided fools making the jobs of others more difficult because they think spinning up a gunicorn process or a custom daemon is worse than their unpatched kernel, apache tomcat and mysql listening on a publicly accessible address. Stateful firewalls and hosts allow/deny are there for a reason.

Sorry for the snarky reply here but there are a lot of people chiming in that obviously have very little knowledge about managing *nix ops and remote access. I have pretty strong opinions about this kind of stuff. Especially the single key stupidity and not checking host fingerprints.

>I cannot tell you how many times I have heard sysadmins say a that a single private key is a "best practice".

Are you talking about a host key, user key, what? Confused.

Sorry for deviating for the topic, but I think it must be said: "Sorry for the snarky reply" is not enough, considering that you wrote it at the same time you could have gone back and rewrite the text into a polite, well-worded argument. That's just condescension - if you really were sorry, you'd have rewritten your text.

By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph.

If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that.

"Sorry for the snarky reply" is not enough, considering that you wrote it at the same time you could have gone back and rewrite the text into a polite, well-worded argument. That's just condescension - if you really were sorry, you'd have rewritten your text."

You are right. I am not sorry for the snarky reply.

"By replying like that you've ensured that your point won't come across - for all I know you might be technically right, but using that tone ensures that lots of people will refuse to read past the second paragraph."

Okay.

"If your argument is solid, that's all you need. IMHO, snark makes your point come across as bragging, and no one likes that."

Okay.

This is a non issue. Set your iptables to start dropping packages after 3 failed login attempts.

Reply on news.ycombinator.com