Mailing List Archive

On Sun, Jun 27, 2010 at 05:08:14PM -0400, Dan Mahoney, System Admin wrote:
> SSH allows the option of hashing the known-hosts file in order to prevent
> people who get access to your account being able to jump other places. Is
> is not conceivable that they'd want the same option with their options
> file?

It doesn't make sense. The point of a hash (at least in this context)
is that you cannot reverse it to get the original data back. When ssh is
connecting to a host, it has the hostname available, because you typed
it on the command line. It can hash the hostname, and then look up the
hash in the known_hosts file.

This doesn't apply to options. The ssh client would have to have the
option already, so it could hash it and look for the hash in the file,
to see whether it should have the option. As I said, it's nonsense.

On Mon, 28 Jun 2010, Greg Wooledge wrote:

> On Sun, Jun 27, 2010 at 05:08:14PM -0400, Dan Mahoney, System Admin wrote:
>> SSH allows the option of hashing the known-hosts file in order to prevent
>> people who get access to your account being able to jump other places. Is
>> is not conceivable that they'd want the same option with their options
>> file?
>
> It doesn't make sense. The point of a hash (at least in this context)
> is that you cannot reverse it to get the original data back. When ssh is
> connecting to a host, it has the hostname available, because you typed
> it on the command line. It can hash the hostname, and then look up the
> hash in the known_hosts file.

What? I think you're not understanding this, then.

The point of the hash is that if, someone has compromised my account (via
brute force, keyboard surfing, evil sysadmin, whatever, and whatever else
it contains (trusted keys, kerberos credentials, etc), they could look in
my known_hosts file and see what other hosts they could log into.

Now, assume I have that file hashed, but sitting in my ~/.ssh/config file,
I have:

# Server in guam is on overloaded DSL link
Host slowpoke
HostName slowpoke.secure.server.ad.company.com
ConnectTimeout 600
User admin

Well, there you go. Have fun. Even without the username, assume I have to
have other options in there like for port-forwards, or the like.

Now, keeping information in known_hosts is automatic and mostly mandatory,
and config files like this are optional. I recognize that.

But compare this with

HostnameHash |1|JYh/HiqdBkaEKeg0KrS9cHncJRI=|Qc2hMsrOMpReJLyOxwmps3nnb0k=
ConnectTimeout 600
User admin

(Assume that the lookup of the hash was done AFTER resolving the FQDN in
dns, like I said).

Yes, you can confirm that that host is also present in my known-hosts, but
you cannot log into it.

For the purposes of this discussion we'll assume I have shell-history
turned off.

> This doesn't apply to options. The ssh client would have to have the
> option already, so it could hash it and look for the hash in the file,
> to see whether it should have the option. As I said, it's nonsense.

Actually, you hadn't said that.

Yes, I recognize this is a corner-case, but other than saying it's
"nonsense" please tell me this would be less secure, and please feel free
to tell me there's no use-case for it.

-Dan

--

--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

On Mon, Jun 28, 2010 at 6:32 PM, Dan Mahoney, System Admin
<danm@prime.gushi.org> wrote:
> Now, assume I have that file hashed, but sitting in my ~/.ssh/config file, I
> have:
>
> # Server in guam is on overloaded DSL link
> Host slowpoke
> HostName slowpoke.secure.server.ad.company.com
> ConnectTimeout 600
> User admin
>
> Well, there you go.  Have fun. Even without the username, assume I have to
> have other options in there like for port-forwards, or the like.
>
> Now, keeping information in known_hosts is automatic and mostly mandatory,
> and config files like this are optional.  I recognize that.
>
> But compare this with
>
> HostnameHash |1|JYh/HiqdBkaEKeg0KrS9cHncJRI=|Qc2hMsrOMpReJLyOxwmps3nnb0k=
> ConnectTimeout 600
> User admin

problem here is that we are not comparing fields.
This field (Hostname) is read to replace the alias (Host). Hashing
looses data. You don't get
the original data back.

So, in the config file you can implement hashing for the "Host" field,
you cannot implement hashing for the "Hostname" field. Since the
"Host" field is just a lookup field, the command line argument can be
hashed and compared with the "Host" fields in the config file.

The only way to go forward is to encrypt either the field or the
complete file. Then you have to enter a passphrase every time you run
"ssh" to decrypt the config file. This is in addition to entering a
passphrase for your private key.

--
And, did Galoka think the Ulus were too ugly to save?
-Centauri

On Mon, 28 Jun 2010, Dan Mahoney, System Admin wrote:
> Now, assume I have that file hashed, but sitting in my ~/.ssh/config file,
> I have:
>
> # Server in guam is on overloaded DSL link
> Host slowpoke
> HostName slowpoke.secure.server.ad.company.com
> ConnectTimeout 600
> User admin
>
> [...]
> But compare this with
>
> HostnameHash |1|JYh/HiqdBkaEKeg0KrS9cHncJRI=|Qc2hMsrOMpReJLyOxwmps3nnb0k=
> ConnectTimeout 600
> User admin
>
> (Assume that the lookup of the hash was done AFTER resolving the FQDN in
> dns, like I said).

There is no requirement that "Host" is a lookup-able name and thus in
general it is impossible to derive "HostName" from it. Moreover, you
can use different "Host" names for the same "HostName" server, e.g.,
to setup different forwardings or use different user names:

Host sa
HostName server.example.com
User admin

Host sd
HostName server.example.com
User dan

--
Regards,
ASK

On Mon, Jun 28, 2010 at 09:32:06PM -0400, Dan Mahoney, System Admin wrote:
> On Mon, 28 Jun 2010, Greg Wooledge wrote:
> >It doesn't make sense. The point of a hash (at least in this context)
> >is that you cannot reverse it to get the original data back.

> The point of the hash is that if, someone has compromised my account (via
> brute force, keyboard surfing, evil sysadmin, whatever, and whatever else
> it contains (trusted keys, kerberos credentials, etc), they could look in
> my known_hosts file and see what other hosts they could log into.

You're discussing what you desire as an outcome. That's great. It's
a perfectly reasonable thing to want.

The problem is that it's not possible.

> # Server in guam is on overloaded DSL link
> Host slowpoke
> HostName slowpoke.secure.server.ad.company.com
> ConnectTimeout 600
> User admin

Hashes are one-way. You can turn data into a hash, but you can't turn
a hash back into data.

> But compare this with
>
> HostnameHash |1|JYh/HiqdBkaEKeg0KrS9cHncJRI=|Qc2hMsrOMpReJLyOxwmps3nnb0k=
> ConnectTimeout 600
> User admin

There is no way to translate the hash into the string
"slowpoke.secure.server.ad.company.com". If you had typed the string
"slowpoke.secure.server.ad.company.com" on the command line, then the
ssh client could hash it and compare that to what's in your options
file. But if you only typed "slowpoke" on the command line, then the
client can't even look up the canonical FQDN from that.

On Tue, 29 Jun 2010, Greg Wooledge wrote:

> On Mon, Jun 28, 2010 at 09:32:06PM -0400, Dan Mahoney, System Admin wrote:
>> On Mon, 28 Jun 2010, Greg Wooledge wrote:
>>> It doesn't make sense. The point of a hash (at least in this context)
>>> is that you cannot reverse it to get the original data back.
>
>> The point of the hash is that if, someone has compromised my account (via
>> brute force, keyboard surfing, evil sysadmin, whatever, and whatever else
>> it contains (trusted keys, kerberos credentials, etc), they could look in
>> my known_hosts file and see what other hosts they could log into.
>
> You're discussing what you desire as an outcome. That's great. It's
> a perfectly reasonable thing to want.
>
> The problem is that it's not possible.
>
>> # Server in guam is on overloaded DSL link
>> Host slowpoke
>> HostName slowpoke.secure.server.ad.company.com
>> ConnectTimeout 600
>> User admin
>
> Hashes are one-way. You can turn data into a hash, but you can't turn
> a hash back into data.
>
>> But compare this with
>>
>> HostnameHash |1|JYh/HiqdBkaEKeg0KrS9cHncJRI=|Qc2hMsrOMpReJLyOxwmps3nnb0k=
>> ConnectTimeout 600
>> User admin
>
> There is no way to translate the hash into the string
> "slowpoke.secure.server.ad.company.com". If you had typed the string
> "slowpoke.secure.server.ad.company.com" on the command line, then the
> ssh client could hash it and compare that to what's in your options
> file. But if you only typed "slowpoke" on the command line, then the
> client can't even look up the canonical FQDN from that.

Agreed, perhaps I wasn't clear that this would assume the client typed the
right thing on the command line.

And yet, ssh today will accept a non-fqdn today, even without a
"hostname" entry in your config. DNS is Sexy. :)

There are two uses to the Host/Hostname thing in ssh.

First is to let you look up a machine that's not in DNS at all, sometimes
with alternate credentials or whatnot. (i.e. an alias).

The other is if you need to trump your DNS search-list.

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.

-Dan

--

"Don't think of it as beer, think of it as a flavored motor oil."

-Jeremiah Kristal, on Guinness
3/29/05, 9:52 AM

--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------

On Tue, Jun 29, 2010 at 11:01 AM, Dan Mahoney, System Admin
<danm@prime.gushi.org> wrote:
> 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.

so:
Host desktop
Hostname desk-HBMDT3J.site.domain.com
tunnel stuff...

cannot be done if Hostname was hashed.

or even:
Host desk-HBMDT3J-tun1
Hostname desk-HBMDT3J.site.domain.com
tunnel options 1

Host desk-HBMDT3J-tun2
Hostname desk-HBMDT3J.site.domain.com
tunnel options 2

Host desk-HBMDT3J
Hostname desk-HBMDT3J.site.domain.com
<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?
-Centauri