Re: SSH Option files using hashes instead of hostnames?
- From: Robert Hajime Lanning <robert.lanning@xxxxxxxxx>
- Date: Wed, 30 Jun 2010 12:12:56 -0700
On Tue, Jun 29, 2010 at 11:01 AM, Dan Mahoney, System Admin
As I mentioned in my first request, this hash would have to be done after
the client looked up the FQDN, and base it on that. Something resolvable
would have to be specified on the command line.
I admit that this would not work in cases where you're using both host and
hostname for the same host in your options file. I've always been a fan of
specifying the correct thing on the command line, though, and mainly use
this config for tunnels and port forwards, not for hostname-aliasing, which
would work perfectly fine with this.
At that point just nix the "Hostname" field.
Then you are just asking for hashing the "Host" field and matching the
host field after FQDN expansion.
of course all aliases must be implemented either in the host table or in DNS
via your search path.
cannot be done if Hostname was hashed.
tunnel options 1
tunnel options 2
<no tunnel options>
Since the "Hostname" field is not a field the is used to match
against, it is used to store information that is used as is, you
cannot store it as a none reversible transform (a hash). You need to
be able to pull the original data out of it.
The ONLY field that can be hashed is the "Host" field, since it is not
used to retrieve settings.
If you require a FQDN expansion before matching the Host entry, you
then preclude having multiple entries for the same host, specifying
different options. (as shown in my second example)
And, did Galoka think the Ulus were too ugly to save?
- Next by Date: Re: SSH port forward - one fails to listen
- Next by thread: Re: SSH port forward - one fails to listen