Best practices for securing SSH server

Erik Norgaard norgaard at
Wed Jun 24 14:50:04 UTC 2009

cpghost wrote:
> On Wed, Jun 24, 2009 at 03:53:15PM +0200, Erik Norgaard wrote:
> But port knocking can be useful and provide more security *if* you
> modify the kocking sequence algorithmically and make it, e.g. a
> function of time, source IP/range (and other factors). This could
> prevent a whole class of replay-attacks.
> Of course, you can modify the keys/passwords algorithmically and
> make them a function of time, source IP etc. as well... ;-)

I don't think it's worth wasting time trying to repair a conceptually 
bad idea, in particular when there are so many alternatives.

Whichever way you turn around this idea, it boils down to a shared 
secret. The security of a shared secret is inversely proportional to the 
people knowing it, while the trouble of changing it is proportional to 
the number knowing it.

You've already got individual passwords in place. If your knock 
sequence/shared secret is randomly chosen of say 1 million (any number 
will do for the example) won't you get better security increasing the 
entropy of the individual passwords equivalently?

> And while we're at it: how about real OPIE? Or combining SSH keys,
> OPIE, and port knocking?

What is the easier solution: implement port knocking or doubling the 
length of your ssh keys?

Each of the technologies you mention can be tuned for higher security 
using longer passwords, checking entropy when people choose a new 
password, more ports in the range of your combination, more knocks etc.

I don't get why you wish to combine different technologies rather than 
tune the well tested and tried already implemented out of the box 
methods for higher security.

BR, Erik

Erik Nørgaard
Ph: +34.666334818/+34.915211157        

More information about the freebsd-questions mailing list