I have read that rather lengthy article and still didn't get the reason "why not?". From the article "The amount of information an attacker would need to get right, measured in number of bits or bytes is a fairly useful measure". So yes, port knocking means one need to know more bits in order to gain access. If some one got the message, could you please provide points "why not?"

Nope, you are correct. Port knocking adds more bits to whatever security you already have, so it's a win.

And, of course, for any discussion of security, you need to specify what your threat environment is. Are you just locking down your home router, or are you running the first line of cyber defense for the CIA? He keeps moving the goalposts in order to knock down his opponents, which is why I can't take him seriously.

From what I could gather, is that because most port knocking examples use 3 port sequences, that boils down to 3 Unicode characters. Likening that to a password, I think he's saying putting a layer of security in front of SSH, protected only by a 3 character password, is not a great idea, and that he's seen slow brute force attacks that seem to be able to overcome such things.

(Edit: For what it's worth, when I tried out knockd, it supported arbritrary port sequences, so you could easily have a 16 port sequence, making it as robust as you want. Timing however, was quite a pain. I had to use specific timeouts (relative to the RTT time from my network to my VPS), and manually enter each port in the sequence).

Personally, I've found that whitelisting IP's for SSH access, as well as a default block-all policy, disabled root login, and Key authentication have been enough to keep people out of my VPS.

Sure, seeing all of the denied traffic in the logs is annoying, but there's not much you can do about that (other than not log it).

Changing the port to something other than the default (even to something obvious like 22222) will get rid of all the log spam. You could also use something like fail2ban, but changing the port is much simpler.

oh yeah, sorry, I didn't mean to make it out like I was complaining. I log all blocked traffic, so I get data related to ports other than just SSH. I was more lamenting that people even want to attack my VPS, as there's really nothing interesting about it.

It's not people, though. It's bots! While changing the ssh port adds a comically small amount of security (if any), it isolates you from 99.99% of automated attacks and keeps those logs clean, so I'd recommend it for everyone.

Just remember that the port argument to `scp` is -P and not -p like it is for `ssh`. :p

Yeah, I whitelist IPs, and just drop all other packets, so I'm not really worried, but thanks for the advice, it's always good to get other peoples opinions on best practices.

I think you can just use ssh/config to store ports even for scp; it's much nicer than remembering that stuff.

This is my setup, except I also run psad.

"he's saying putting a layer of security in front of SSH, protected only by a 3 character password, is not a great idea"

He seems to be missing the point that this is only equivalent to a password if the attacker knows that it's there and can measure whether they've guessed correctly. Sure, if I tell someone that I've used a 48-bit password and allow them to get instantaneous feedback for each attempt, and don't block them completely after N guesses, it's not much of a barrier. On the other hand, if all they see is a non-responsive port and I make timing a factor and I do block them for guessing, it can significantly hamper their ability to make any guesses at the next (ssh) layer. Nobody's suggesting that the three-letter port knocking sequence should be the only security measure taken. It's purely an adjunct or enhancer for other measures, and for that it can be quite effective.

> Sure, seeing all of the denied traffic in the logs is annoying, but there's not much you can do about that (other than not log it).

Yes: you can significantly reduce it by dynamically banning IP addresses which originate it.

Here is a rebuttal to the "why not" argument:

http://www.cipherdyne.org/blog/2013/10/port-knocking-why-you...

I stopped using port knocking simply because it made remote access a hassle.

Scanning logs for intrusions and banning offending IP's deals approximately the same locus of issues that port knocking does.

Now if you absolutely must have deathly silence in your SSH logs, then only port knocking will do.

I use iptables to ratelimit ssh connections to 4 per 300 seconds per ip. I feel like that plus using a key provides a reasonable level of security while not being a pita.

Open question -- is there any reason this is a bad idea?

This is all connections, even if every connection attempt from a given IP succeeds?

It's not a bad policy overall, but of course it interferes with a legitimate use: a script which rapidly executes numerous SSH commands.

yes, all connections

things like scp and rsync recycle connections across files though, so it hasn't been a problem in practice; ansible does too if you use openssh instead of paramiko

ps -- if someone knows iptables well, and is willing to share a similar script for failed connections, I would be grateful! But doing this across all ssh connections was easy enough that even I managed to get it working.

I'm talking about have a shell script like:

  while whatever ; do
    # hit host with a ssh command numerous times in loop
    ssh user@host command ...
    ...
  done

Banning more than X failed connection attempts from an IP in Y minutes is done with utilities like fail2ban, which wheedle that information from system logs.