Best practices for securing SSH server

[Tim Judd]

On 6/22/09, Daniel Underwood <djuatdelta at gmail.com> wrote:
> On a BSD box at work (at an extremely fast connection and static IP),
> I run an SSH server.  I am the only person who uses the server, but I
> use it from some locations that are behind a dynamic IP (so I can't
> set pf rules to filter by IP).  I will always, however, use the same
> laptop to connect to the server.  Due to the speed and location of the
> connection, it's a relatively high-risk target.
>
> What are some good practices for securing this SSH server.  Is using a
> stored key safer than a password in this instance? I have no
> experience with port-knocking, but I'd appreciate some tips or
> suggested beginning references... I welcome any and all advice.
>
> Note: I do require X11 forwarding (not sure whether that's relevant
> information)
>
> TIA,
> Daniel


My remote ends are "dynamic" too, but since everywhere I go keeps the
routers online 24/7, the IP is almost static.


Here's my suggestion.  I think it might work, by adding a small dns
hit every packet to port 22 goes to the box.  My config is similar

table <knownIPs> const { 1.2.3.0/25 10.20.30.0/24 }

<..standard rules..>

pass in on $ext_if from {<knownIPs, ("my.dyndns.domain.org")} to port 22




()'s get reevaluated every time the rule is evaluated (in this case,
only packets to port 22)
the ""'s resolve hostnames.

So you pick yourself a dyndns hostname, use either a dyndns client or
update it yourself, wait 60 seconds (ttl for dyndns.org), and your
firewall will find your new remote IP.


I do know, that if the rules list ""'s only, the hostname is resolved
when pfctl loads the rules, but doesn't re-resolve it until the next
time you load the rules.  Kludgy workarounds are possible (cronjob
that), etc.  Because of this, the example above may resolve the dyndns
hostname, then reevaluate the same IP at every evaluation of that
rule....  hrm, may not work.  Gotta test.


I'll update within the week of my testing results.