[Bug 1483] Unable to select desired (DSA) key file

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Fri Jul 18 14:57:44 EST 2008


https://bugzilla.mindrot.org/show_bug.cgi?id=1483





--- Comment #2 from rannumgen at globaleyes.net  2008-07-18 14:57:37 ---
After many more tests with/without configuration files, with/without
"default keys" (eg; id_dsa/id_rsa), with/without new/empty user_ssh
directories, ...., I think that I have found the fundamental problem.
Despite what the MANual page for 'ssh_config' says,

ssh(1) obtains configuration data from the following sources in the
fol-
     lowing order:

           1.   command-line options
           2.   user's configuration file (~/.ssh/config)
           3.   system-wide configuration file (/etc/ssh/ssh_config)

     For each parameter, the first obtained value will be used. 

IF there is one or more of the "default keys" that EXIST in the user's
SSH "home" directory, WHETHER or not there are ANY SSH system/user
configuration files, the default keys will ALWAYS appear FIRST in the
list of keys to be offered, EVEN when there is a key list provided as
command line arguments. IF the remote/target site has the requisite
components of the "default keys" in its target SSH "authorized_keys"
file, THEN THOSE "default keys" will be offered and accepted FIRST and
any command line key list will be effectively ignored.

Since these "default keys" (names) are built into SSH/SCP/SSHD, they
SHOULD be at the END of any collected/derived key list, unless also
provided as command line parameters, in which case - they will appear
twice in the derived key list.

My workaround - delete all "id_dsa/id_rsa" (user) key files, "delete"
the system-wide SSH configuration file, create a new USER SSH config
file that has JUST the key files specific to single remote hosts. Do
NOT have a "host wildcard" entry in the user SSH configuration file.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.


More information about the openssh-bugs mailing list