What with all the hubbub with the OpenSSL faults in the news recently, I deciced I would do something to put down another large problem I have with a closely related product–OpenSSH, although I should immediately point out that this is not necessarily particular to OpenSSH.
You see, OpenSSH has very little support for easily creating rich access policies. The access policy I wanted to create was to allow password authentication to clients inside our campus, but only allow public-key authentication to clients coming from outside the network.
The reason for this, as anyone running an Internet-facing SSH server will be able to immediately appreciate, is that every day many login requests are made from the Internet to SSH servers, trying to brute-force account names and passwords; sometimes they are successful, but most of the time it just creates a lot of noise in the logs and an uneasy what-if feeling in your gut.
OpenSSH has no configurable to allow you to specify a policy such as I want to specify (or similar constraints). You might be able to play tricks with PAM, but for our purposes, you can’t really tell PAM which authentication mechanism you are using. If you can show an equivalent solution to mine using just PAM I would like to know of it.
Because the brute-force problem is a problem shared among many, I have developed an OpenSSH configuration I refer to as “Split SSH”. The name comes from “Split DNS”, where the client sees a different view (configuration) depending on where they are coming from. Instance 222 is configured for public-key authentication only (had to turn off PAM), while instance 22 is configured for password or public-key. Then, to maintain the illusion, requests to port 22 from outside are diverted (as in transparent proxying) to port 222. The full document about this (ie, an e-mail I sent to the IT mailing list on campus) can be found in the Files section of this site.