http://bugzilla.mindrot.org/show_bug.cgi?id=910
mindrot at askneil.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mindrot at askneil.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910 ------- Additional Comments From mindrot at askneil.com 2004-09-11 03:14 ------- As a workaround you could set the nohostauthenticationforlocalhost option; this disables checking for localhost. Alas, this has the very undesireable property of leaving those connections unverified. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910 ------- Additional Comments From mindrot at askneil.com 2004-09-11 03:20 ------- Checking the source finds the "right" way to do this: use the HostKeyAlias option. Your suggested fix would be automatic and easier, but HostKeyAlias seems to be the way to get things done without a patch. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910
devin.nate at bridgecomm.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|3.7.1p2 |-current
------- Additional Comments From devin.nate at bridgecomm.net 2004-09-20 06:10
-------
First try at a patch to do this.
The patch changes the known_hosts file format. Format is host:port.
Nothing else changes, so multiple aliases etc are permitted.
This patch does NOT include DNS based host key checking updates,
i.e. those found in verify_host_key_dns()
Patch is against openssh-3.9p1
If any openssh developers capable of getting code into the official
tree are watching, please consider this patch for inclusion into
a future release.
Thanks,
Devin Nate
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910 ------- Additional Comments From devin.nate at bridgecomm.net 2004-09-20 06:11 ------- Created an attachment (id=716) --> (http://bugzilla.mindrot.org/attachment.cgi?id=716&action=view) Patch includes port numbers in known_hosts file ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910
mouring at eviladmin.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From mouring at eviladmin.org 2004-09-20 06:19
-------
I'm closing this because it was already tagged and rejected in bug ID 393.
Please review that bug id to
understand why using host:ip in known_hosts file is not wise.
- Ben
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910
------- Additional Comments From devin.nate at bridgecomm.net 2004-09-20 07:45
-------
Interesting.. I read through bug 393. Thanks for the pointer, Ben.
I'm not sure if the question is up for consideration or not. There appear to
be
2 different requirements, and having read through bug 393 it didn't seem
like
either side was really understanding the requirements.
In particular, I didn't realize the impact this patch would have on
HostBasedAuthenciation. Definitely, the 1:many problem you mentioned is a
problem - which of several host keys to use. That is a very significant problem-
it would totally break Hostbaseauth.
The problem I have is several hundred ssh servers, located behind (fewer) dhcp
changing IP addresses that many of our Customers have. For each ip address
(approx 100), there are 3 or so ssh servers (running on different ports
forwarded from the single IP). On a daily basis, someone (or lots) are moving IP
addresses. I need to ensure our staff can connect safely and securely and ensure
our Customers are equally protected. To that end, our staff can accept new host
keys but cannot connect if an already known hostkey doesn't match what it
should
(i.e. ssh StrictHostKeyCheck ask). We explicitely disable HostBasedAuth (and all
related auth tyes) on all of these installs. As per bug 393, maintaining a
ssh_config file with the necessary mappings is not a viable option,
commercially- we just have too many hosts changing too often. Our Customer base
is growing, so the problem is getting bigger.
The interesting thing is that these are quite different requirements. One is
hostbasedauth and one is MITM-mitigation.
I would still like to see this feature, but as you noted there needs to be a
method that ensures 1:1 for hostbasedauth to work properly. This is what I see:
1) For sites with multiple machines behind 1 IP address; only 1 of those
machines could connect to another ssh server using hostbasedauth, given openssh
3.9p1 unchanged. Assuming one of these hosts connects to a ssh server:
2) The server that is connected to is able to lookup the host pub key because it
knows the ip address of the connecting host (in this case, the NAT ip). Since
there's 1:1 match between ip/hostname and the key files, the ssh server
knows
which key to select.
Therefore, the conclusion that I think I can draw is that hostbasedauth works
for all hosts that have the same ip address and host keys. Stated another way,
hostbasedauth does not work for hosts that share a common ip address but
different host keys.
If that is true, then assuming a patch similar to mine were accepted, causing
multiple keys with the same ip address to be in the known_hosts files, the
question is how to identify which of the potential lines hould be used to get
the host key from.
The answer to that could be to have a flag to tell the functions in auth.c (and
in particular check_key_in_hostfiles()) to know about the special flag so that
only one host line matches. Perhaps the easiest to impliment would be a special
indicator similar to a port number.
Potential example:
ip.ip.ip.ip:hostbasedauth
In this way, a line in a known_hosts file with :hostbasedauth after the
hostname, ip, or alias, would be singled out for use by a ssh server for
hostbasedauth. This would maintain the 1:1. Also, since I'd venture to guess
folks using hostbasedauth are a little more fluent with Unix and ssh (since
they've at least had to know how to edit a rhosts or shosts file), they
would
seem fairly well equiped to add a hostbasedauth flag.
The largest disadvantage that I see, which isn't so much a disadvantage for
me,
is that the known_hosts entry with the :hostbasedauth is not shared for outgoing
connections - and therefore in situation where host A connects to host B using
hostbasedauth, and then from host B connects back to host A using whatever, host
B will have 2 entries for host A: 1 for the hostbasedauth and 1 for the standard
hostauth/MITM-mitigation.
Any comments, thoughts, chance of getting this bug un-wontfixed?
Thanks,
Devin Nate
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910
devin.nate at bridgecomm.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #716 is|0 |1
obsolete| |
------- Additional Comments From devin.nate at bridgecomm.net 2004-09-20 08:04
-------
Created an attachment (id=717)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=717&action=view)
Same patch as before, updated auth.c to look for 'hostbasedauth' flag in
place
of port number for HostBasedAuth
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910
devin.nate at bridgecomm.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #717 is|0 |1
obsolete| |
------- Additional Comments From devin.nate at bridgecomm.net 2004-09-21 06:15
-------
Created an attachment (id=719)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=719&action=view)
Patch to add PortAware to ssh client
Summary:
Permit ssh client and ssh server to preserve all backwards compat while at the
same time permitting ssh client to be 'port aware'. I believe that both
mechanisms (PortAware and HostKeyAlias) can co-exist. I am not asking to
replace one with the other, I'd sure like both though, and I believe the
following is a way to have both in such a way that backwards compat is
maintained, no features are lost, and the port feature is gained.
SSH CLIENT
1) ssh will use the host documented in HostKeyAlias if there is one. No port
information will be used for key retrieval or key addition. (i.e. ssh client
will work identical as before if there is a HostKeyAlias specified).
2) ssh will use host & port if there is not an explicit HostKeyAlias. Port
information will be appended to the hostname and/or ip address in the format
@port (the mailing lists noted that @ is a better seperator).
SSH SERVER
1) sshd will use host/ip address only for HostbasedAuth. It will not use any
port information for key retrieval. (i.e. sshd server will work identical as
before, no changes to be made).
ADDITIONAL FEATURES:
1) ssh client becomes 'port aware'.
COMPAT MAINTAINED
1) ssh client connections still can use all the features of the HostKeyAlias
functionality, both for key learning and key retrieval. ssh client is identical
when HostKeyAlias information is specified.
2) For non-HostKeyAlias entries, ssh client behavior is identical to before
except that port info is used to save and retrieve known_hosts entries.
3) sshd does not process port information and therefore operates identical to
before.
POTENTIAL CONSEQUENCES
1) Since ssh client may learn with @port info (i.e. when there is no
HostKeyAlias), and since sshd ignores @port info, users will need to make sure
that keys to be read by sshd for HostbasedAuthentication appear without the
@port information. Since current info is stored without @port info, full
backward compat is maintained for people already doing this. Only newly added
hosts need to be verified.
POTENTIAL CONFIG ISSUES [ NOT IMPLIMENTED IN THIS PATCH ]
1) Since there is some controversy, perhaps a ssh option for ssh_config or from
the command line exists to enable the port-aware behavior. ssh_config example:
PortAware [ yes | no ] (default to no to maintain backwards compat).
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910 ------- Additional Comments From foomzilla at fuhm.net 2004-09-21 09:04 ------- This is the same as (at least) bug 80, bug 393, bug 454, bug 523, and bug 537. I hope the number of bugs submitted on this convince that it is a real problem, at least.. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910 ------- Additional Comments From mouring at eviladmin.org 2004-09-21 09:38 ------- Do note as what bug 454 states don't use ":" as a host:port separator. user at port is fine. Otherwise you run into IPv6 issues. - Ben ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=910 ------- Additional Comments From devin.nate at bridgecomm.net 2004-09-21 12:15 ------- My most current patch 'PortAware' uses @ as per bug 454 as the port seperator. It was good advice to read all the past comments :) Thanks, Devin Nate ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.