Bug 747 - host authentication requires RSA1 keys
Summary: host authentication requires RSA1 keys
Status: CLOSED INVALID
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Documentation (show other bugs)
Version: -current
Hardware: All All
: P2 trivial
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
: 746 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-10-21 09:17 AEST by Glenn Burkhardt
Modified: 2006-10-07 11:36 AEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Burkhardt 2003-10-21 09:17:31 AEST
The documentation indicates that /etc/ssh/ssh_known_hosts can be built from 
entries in the per-user ~/.ssh/known_hosts file. However, the entry must have
an RSA1 key; any other key type will not work.

In the 'ssh' man page:

"If the server machine does not have the
 client's host key in /etc/ssh/ssh_known_hosts, it can be stored
 in $HOME/.ssh/known_hosts.  The easiest way to do this is to con-
 nect back to the client from the server machine using ssh; this
 will automatically add the host key to $HOME/.ssh/known_hosts."

The key put in the user's known_hosts file is 'ssh-rsa', which will not work for 
host based authentication in /etc/ssh/ssh_known_hosts.

In monitor.c, at about line 962 the type of the key passed to key_read() is
fixed:

		case MM_RSAHOSTKEY:
			key->type = KEY_RSA1; /* XXX */
			allowed = options.rhosts_rsa_authentication &&
			    auth_rhosts_rsa_key_allowed(authctxt->pw,
			    cuser, chost, key);

In addition, the host's IP address is required in the key definition
in /etc/ssh/ssh_known_hosts; the symbolic host name won't work. 

Here's a workaround, that could be included in the documentation:

Here's a workaround for the problem.  Use

        ssh-keyscan -t rsa1 192.168.2.30 > ssh_known_hosts

where the actual host's IP address should be substituted for "192.168.2.30".
Comment 1 Glenn Burkhardt 2003-10-21 09:19:39 AEST
The line number in monitor.c applies to rev 3.7.1p2.
Comment 2 Markus Friedl 2003-10-22 19:26:41 AEST
*** Bug 746 has been marked as a duplicate of this bug. ***
Comment 3 Markus Friedl 2003-10-22 19:27:48 AEST
that's not a bug.

protocol 1 hostbased, AKA rhostsrsa requires rsa1

protocol 2 hostbaesed requires rsa/dsa hostkeys.
Comment 4 Glenn Burkhardt 2003-10-22 21:45:28 AEST
I guess a bug is in the eyes of the beholder.  If the code doesn't do what the
documentation says, is it a bug, or is the documentation incorrect?
In this case, I'd say the documentation is incorrect.  My main point is that in
order to use the feature, the docuemtation misled me, and I had to resort to the
source code to figure out how to get the feature to work.

My appeal is to fix the documentation.
Comment 5 Markus Friedl 2003-10-22 21:52:20 AEST
AFAIK it's obvious from the documentation that
rsa1 keys are for protocol 1
and rsa/dsa for protocol 2.
Comment 6 Markus Friedl 2003-10-22 21:52:57 AEST
please pr
Comment 7 Glenn Burkhardt 2003-10-23 00:21:15 AEST
> AFAIK it's obvious from the documentation that

The documentation for what's needed in /etc/ssh/ssh_known_hosts is wrong, and,
if followed, prevents host based authentication from working.  A short note
about the requirement for RSA1 keys, with the IP address of the known host,
would be very helpful.
Comment 8 Markus Friedl 2003-10-23 00:35:16 AEST
the documentation says that the global known hosts file
can be generated from the per user file.

that's not wrong.

there is no requirement for rsa1 keys.

i think it's obvious that the ssh1 protocol uses
ssh1 keys and the ssh2 protocol uses ssh2 keys.

the documentation also mentions over and over
again that RhostsRSA only works with protocol 1.
Comment 9 Glenn Burkhardt 2003-10-23 06:36:34 AEST
I realize now that the source of my confusion was that the default for ssh on
one machine was protocol 1, and on the other, protocol 2.  So the bit in the ssh
man page that says:

"If the server machine does not have the
 client's host key in /etc/ssh/ssh_known_hosts, it can be stored
 in $HOME/.ssh/known_hosts.  The easiest way to do this is to con-
 nect back to the client from the server machine using ssh; this
 will automatically add the host key to $HOME/.ssh/known_hosts."

didn't work.

I believe that the documentation could be improved by adding something like 
this to the ssh man page, where the /etc/ssh/ssh_known_hosts file is discussed:

    /usr/local/etc/ssh_known_hosts 

	Systemwide list of known host keys.  This file should be prepared
	by the system administrator to contain the public host keys of
	all machines in the organization.  This file should be world-
	readable.  This file contains public keys, one per line, in the
	following format (fields separated by spaces): system name, pub-
	lic key and optional comment field.  When different names are
	used for the same machine, all such names should be listed, sepa-
	rated by commas.  The format is described on the sshd(8) manual
	page.

        If the system wide ssh_known_hosts file is to be used for protocol 1
        Rhosts RSA Authentication, there must be an entry with an RSA1 key
        and the IP address of the machine as a system name.  For use with
        protocol 2 host based authentication, the entry must have an RSA key
        and the IP address as a system name.  'ssh-keyscan' can be used to
        obtain the key from the host with the appropriate type, e.g.,

	  ssh-keyscan -t rsa1 ip-address >> /usr/local/etc/ssh_known_hosts

I haven't been able to find anywhere in the documentation that it's required
that the IP address of the machine be listed as a system name.  

There a short reference in the sshd_config man page to which key is used by
which protocol, and others in the ssh-keygen/ssh-keyscan utilities, but it
can't hurt to note that in the ssh_known_hosts files, separate keys are
required if the server is to handle both protocols.

Thanks.
Comment 10 Glenn Burkhardt 2003-10-23 07:38:56 AEST
Sorry, just discovered that the IP address isn't required for protocol 2.
It's smarter.
Comment 11 Damien Miller 2005-04-21 15:52:14 AEST
This was never a bug.
Comment 12 Darren Tucker 2006-10-07 11:36:04 AEST
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.