[tptacek]

Obligatory: I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH. If you have lots of hosts running SSH, collapse them down to one exposed SSH bastion host. Then get on with your life.

[mathrawka]

I once had a legitimate use case for port knocking. The network monitoring software at Yahoo! Japan was very strict and you were not allowed to connect to a system outside of their network via SSH. (Don't get me started on the local spyware installed on everyone's Windows boxes... that was easy to inject a DLL into and crash though). Me being extremely evil, wanted to connect to my home computer over SSH.

They had a loophole that the network monitoring system would trigger an alert that gets manually verified. If the port was open, they could verify that it was an actual SSH server. If the port was closed, they would write it off as a false alarm.

[spindritf]

sslh[1] usually allows you to reach it even through fairly restrictive firewalls. At least unless they have their certs installed and inspect ssl traffic.

[1] http://www.rutschle.net/tech/sslh.shtml

[icebraining]

They don't need to have certs installed, since sslh doesn't actually tunnel SSH-over-SSL, it just redirects the connection to the right daemon. Simply pointing ssh to that port would have given up the trick.

[nmcfarl]

Most useful comment in this whole conversation. Incredibly handy for home servers - for which I'd just resigned myself to the fate of running ssh on port 80.

[peterwwillis]

If you're concerned enough to set up an SSH bastion host, do the right thing and set up a VPN. Not only is it a completely separate application (vs two SSH daemons which might both be exploited by a single 0day), it gives you fine-grained control over what users get access to what parts of the network, it doesn't magically grant a user shell, and ultimately allows for tunneling any network service without fumbling with SSH tunneling.

IMO, If your aim is to provide a clandestine entry point to your network, port knocking is amazingly effective. Your host can be completely silent on the internet and seemly be offline but still provide network services. Keep a honeypot online on the same network and most attackers will be busy for weeks/months.

[tptacek]

A VPN is also a fine answer. I'm marginally more worried about the code quality of something like openvpn than I am about openssh at this point, but six of one.

I think the "clandestine entry point" stuff is mostly a psychological benefit.

[wglb]

And it reduces junk in the log.

[masklinn]

> Obligatory: I think port knocking is really silly and you shouldn't waste time with it.

That's the gist of the article, but it details why it's silly as well, which is nice.

[tptacek]

Sure, I wasn't criticizing the article.

[dkl]

He's why it's not silly and why disabling password logins and using key-based logins in SSH doesn't increase your security:

If you turn off password logins, people will use authorized_keys to in effect get a password-less login. If their public key has a password, this is OK, since they're either using ssh-agent or typing in their password at the time of the login. However, what if their ssh key has no password on it? That gives a password-less login path to my host, which is less secure. The problem is, it is impossible to detect, on the server side, a login with a key with no password.

[tptacek]

I'm failing to see what this has to do with the threat model that port knocking addresses. Suffice it to say that an attacker who has access to your SSH identity file has with virtually total certainty access to your SSH passphrase as well.

[dkl]

I'm failing to see what this has to do with the threat model that port knocking addresses.

You said:

I think port knocking is really silly and you shouldn't waste time with it. Disable root logins and password logins in SSH.

I'm pointing out that will lead to less security, not more, for the stated reason.

Suffice it to say that an attacker who has access to your SSH identity file has with virtually total certainty access to your SSH passphrase as well.

How so? By brute for cracking it?

[ds9]

In case anyone ever wonders why "disable password logins" is commonly used as a synonym for "use keys", it's because of the config file and the way SSH for Linux works. If you enable both passwords and keys, then either will succeed instead of both being required! This unintuitive result is a rather dire "gotcha" for anyone new to the task.

Personally I would like to have both, in succession, but have not found a way to configure it. This would be simpler than the SSH-to-SSH solution.

[kaoD]

> Personally I would like to have both, in succession

Key files can be password protected. Do you mean "(key+password) + password" or just not aware of passworded keyfiles?

[thwarted]

If you can force authentication via both private key and a password, then you're authenticating via both "something you have" (the key), and "something you know" (the password). Having a passphrase on the key protects access to the key, but it doesn't provide any additional levels of authentication to the (remote) system that is requesting authentication — after all, the user could have removed the passphrase from the key file, there's no way for the remote system to know.

Unfortunately, there doesn't seem to be a way to require both a key and a passphrase to be entered. There may be a way to do it with some (custom?) pam configuration/modules, but as far as I know, nothing in sshd itself.

[phamilton]

Not sure how robust it would be, but you can set a default shell that would be a simple script requiring log in before launching bash. That would give you both.

[ds9]

Different issue. It is definitely best practice to use a long passphrase to protect every secret key, this is off topic.

What I meant was, you connect to the SSH server and authenticate cryptographically (use passphrase locally when prompted) - then you also need a logon + password for the SSH server to complete the authentication. This would reject the internet noise banging on the port, but impose a 2 factor test.

[tptacek]

If you want two factors for SSH authentication, you can and should set up a two-factor auth system, like Duo.

[cmhamill]

Any resources on best practices for a bastion host?