Bug 554

Summary:	RFE: PATH_SSH_KEY_SIGN, SSH_RAND_HELPER
Product:	Portable OpenSSH	Reporter:	Jens Elkner <elkner>
Component:	sshd	Assignee:	OpenSSH Bugzilla mailing list <openssh-bugs>
Status:	CLOSED WONTFIX
Severity:	normal
Priority:	P2
Version:	-current
Hardware:	All
OS:	All

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