Bug 2607

Summary:

accept location off ssh binary via environment variable or deduce it from /proc/

Product:

Portable OpenSSH

Reporter:

Stefan Tomanek <stefan.tomanek-mindrot>

Component:

ssh

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED WORKSFORME

Severity:

enhancement

CC:

Bert.Wesarg, djm, dtucker

Priority:

Version:

7.3p1

Hardware:

All

OS:

Linux

Attachments:

Description	Flags
use /proc/self/exe or environment variable to launch port forwarding for ProxyJump	none

Description Stefan Tomanek 2016-08-23 06:06:01 AEST

Created attachment 2864 [details]
use /proc/self/exe or environment variable to launch port forwarding for ProxyJump

When testing the relatively new JumpHost (-J) functionality, ssh constructed several command lines to facilitate the port forwarding; the command line however always starts with "ssh", picking the wrong binary from $PATH (and not from my development directory). This patch adds the option to use an environment variable (SSH_CUSTOM_CMD) to specify the command line to start with; on platforms that support it (Linux), it can also use /proc/self/exe to identify the ssh binary currently run and use it to create the port forwarding, avoiding confusions and possible problems when using different versions of ssh.

github reference: https://github.com/wertarbyte/openssh-portable/compare/master...proxyjump_custom_cmd

Comment 1 Darren Tucker 2016-08-23 09:51:10 AEST

Since /proc/self is not portable I don't think we should be cluttering up the code with it, and if you're going to set an environment variable to tell it where to find ssh, why not $PATH?

Comment 2 Bert Wesarg 2016-08-23 15:37:51 AEST

I missed the initial discussion about -J, but why not using av[0]?

Comment 3 Darren Tucker 2016-08-23 16:16:47 AEST

(In reply to Bert Wesarg from comment #2)
> I missed the initial discussion about -J, but why not using av[0]?

That's a better idea.  It doesn't cover all cases, but it might cover enough.  The cases I can think of are:

1) full path: currently will exhibit the described behaviour, using argv[0] would fix it.
2) relative path: ditto, assuming ssh(1) doesn't chdir, which I don't think it does.
3) no path, $PATH set and exported.  should work.
4) no path, $PATH set but not exported.  could potentially pick up a different ssh.

Comment 4 Damien Miller 2018-06-09 13:19:58 AEST

ssh now tries to use argv[0] and falls back to $PATH if it doesn't look like an executable

Comment 5 Damien Miller 2021-04-23 15:03:57 AEST

closing resolved bugs as of 8.6p1 release