Best practices for securing SSH server

cpghost cpghost at
Wed Jun 24 15:13:02 UTC 2009

On Wed, Jun 24, 2009 at 04:50:01PM +0200, Erik Norgaard wrote:
> 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?

It all boils down to this: do you login from a secure machine
or not? Each tool has its own set of uses. When I want to log in
from a public terminal, I prefer OPIE; when I log in from home,
I prefer SSH keys. Port knocking is an interesting technique, but
as you pointed out, its only useful on machines with very few

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

I totally agree.

> BR, Erik
> -- 
> Erik N?rgaard
> Ph: +34.666334818/+34.915211157        


Cordula's Web.

More information about the freebsd-questions mailing list