[NTLUG:Discuss] SSH

[David]

On Tue, Oct 14, 2003 at 11:02:00PM -0500, severian at pobox.com wrote:
> >   use a non standard port for the server/client. Lots of hackers
> >      try and access port 22.
>    I was thinking about that, but I wasn't sure if it was worth the 
> trouble.  It is certainly easy to do.

Personally I don't bother.  Network probe tools such as Nessus ignore
the port number.  They determine what service is listening on a port
by actually contacting it and seeing what sort of greeting it sends.
SSH has a very distinctive initial greeting, which can be readily
identified. 

Changing the port number will help avoid getting hit by automated
worms, which scan large IP ranges looking for "vendor-default"
installations that may not be up-to-date on patches.  I prefer to keep
my systems updated and firewalled.  Hiding your port number is a form
of security by obscurity, an approach which doesn't usually work.

>    Both remote workers are on systems where they will not have long term 
> IP leases.  I mentioned how I was thinking about handling this in a 
> response to Chris.  Basically, I'll give each remote machine a name put the 
> IPs in the hosts file.  One point here seems redundant.  Maybe it isn't 
> really, but it seems tthat way.  If I disallow passwords and require keys, 
> doen't that limit the ip addresses?  The keys contain the IP address or the 
> name, so only a matching IP address or name can do a public/private key 
> match.  If this is't true, what am I missing?

Nope, not true.  SSH keys include the login name and hostname of the
user, but that's just a comment field.  It exists to allow us humans
to easily distinguish between keys.  The SSH program doesn't use it in
any way.  

That means that you don't need to worry about the fact that your
telecommuters have dynamic IP addresses.  In PubkeyAuthentication, SSH
will accept the given public key from any IP address.  The public
portion of the key must be listed in the server-side file
"~/.ssh/authorized_keys".  By means of options in that file, you can
limit the IP addresses from which the key is accepted.  This is
somewhat more specific than using IP Tables, because it's done on a
per-user and per-key basis.  Key 1 can be allowed from a particular
IP, while Key 2 is not allowed from that same IP.

-- 
David Hayes
david at hayes-family.org