Bug 554 - RFE: PATH_SSH_KEY_SIGN, SSH_RAND_HELPER
Summary: RFE: PATH_SSH_KEY_SIGN, SSH_RAND_HELPER
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: -current
Hardware: All All
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-04 06:27 AEST by Jens Elkner
Modified: 2004-04-14 12:24 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 Jens Elkner 2003-05-04 06:27:38 AEST
Unfortunately there is no way, to specify the default location
of ssh-keysign and ssh-rand-helper per ssh[d]_config (since
pathes are hardcoded), which prevents relocation.

So it would be nice to have a

SshSigner = /path/ssh-keysign
# and perhaps a
SshRandHelper = /path/ssh-rand-helper

in the configs. If it is not found, ssh can still fallback to the hardcoded 
values ...
Comment 1 Damien Miller 2003-06-04 22:00:30 AEST
No, we want less options rather than more. You can always use symlinks...
Comment 2 Jens Elkner 2003-06-04 23:26:55 AEST
Symlinks are not a solution. E.g., if you install openssh on a shared volume
(i.e. NFS) named /usr/local, you can't expect, that the admin creates on dozens of
other machines a link from /usr/sbin/.... to /usr/local/,,,.

Furthermore symlinks are a bad solution wrt. NFS shared fs. E.g. something refers
to /usr/sbin/... and that is a link to /usr/local, which is an NFS drive, which is
not available for any reason, the whole machine starts hanging.

Also symlinks may sometimes impose security risk and are usually slower than
direct access.

Hardcoding pathes is really an ancient practice and should be avoided in a
modern application. Symlinks are not a solution as well, they are more or less
an "instrument" to save diskspace and to "keep files uptodate". It is NOT an
"instrument" to solve application weaknesses!
Comment 3 Damien Miller 2003-06-04 23:44:57 AEST
Sorry, as I said: we are not adding extra options for this.
Comment 4 Damien Miller 2004-04-14 12:24:19 AEST
Mass change of RESOLVED bugs to CLOSED