openssh unix dev - Mar 2014 - [RFC] Add hash token to ControlPath

Hi.

Last night on an irc openssh channel, a user brought up a use
case involving cluster trees and very descriptive (i.e. long)
hierarchical hostnames.

To make a long story short, his ControlPath (~/.ssh/control-master
/%r@%h:%p) was bumping up against UNIX_PATH_MAX.

Attached patch adds a new percent-token (%H) that expands to the
sha1 digest of the concatenation of host (%h) + port (%p) + remote
user (%r). The token's expanded length is a fixed 40 characters
and, barring digest collision, provides uniqueness.

The patch was built against 6.5p1 but applies (with harmless
offsets) to OpenBSD HEAD.

--mancha

mancha <mancha1 <at> hush.com> writes: 
> Attached patch adds a new percent-token (%H) that expands to the
> sha1 digest of the concatenation of host (%h) + port (%p) + remote
> user (%r). The token's expanded length is a fixed 40 characters
> and, barring digest collision, provides uniqueness.
> 
> The patch was built against 6.5p1 but applies (with harmless
> offsets) to OpenBSD HEAD.
> 
> --mancha
Apologies but it seems the ML strips attachments. Rather than risk
whitespace debacles with inline patches, I've placed it here:

http://sf.net/projects/mancha/files/misc/openssh-6.5p1-mux-hash.diff

On Thu, Mar 06, 2014 at 18:37:21 +0000, mancha wrote:
> Hi.
> 
> Last night on an irc openssh channel, a user brought up a use
> case involving cluster trees and very descriptive (i.e. long)
> hierarchical hostnames.
> 
> To make a long story short, his ControlPath (~/.ssh/control-master
> /%r@%h:%p) was bumping up against UNIX_PATH_MAX.
> 
> Attached patch adds a new percent-token (%H) that expands to the
> sha1 digest of the concatenation of host (%h) + port (%p) + remote
> user (%r). The token's expanded length is a fixed 40 characters
> and, barring digest collision, provides uniqueness.
> 
> The patch was built against 6.5p1 but applies (with harmless
> offsets) to OpenBSD HEAD.
> 
> --mancha
I suppose the IP address of the destination host is not known at the
time that the socket is created or initially accessed; but if it is,
adding a macro for the IP address might be an alternative approach.

With regard to your suggestion, it might also be worthwhile including
the client hostname in the hash to cover scenarios where the sockets are
created in shared filesystems. I'm also a little hesitant about using
%H; in analogy to %l and %L, %H should be the first component of the
destinations's name. Perhaps %M or %S?

I'm not sure if the work being done to allow OpenSSH to be built without
OpenSSL includes SHA-1 support. I assume that it does, but I haven't
gottent around to looking at the code. If it doesn't, it might be
necessary to use MD5 instead.

-- 
Iain Morgan