openssh bugs - Jul 2019 - [Bug 3048] New: ssh reads from the wrong directory in user namespace

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

            Bug ID: 3048
           Summary: ssh reads from the wrong directory in user namespace
           Product: Portable OpenSSH
           Version: 7.9p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: hholst80 at gmail.com

ssh(1) says that

     -i identity_file
             Selects a file from which the identity (private key) for
public key authentication is read.  The default is ~/.ssh/id_dsa,
             ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa. 
Identity files may also be specified on a per-host basis in the con?
             figuration file.  It is possible to have multiple -i
options (and multiple identities specified in configuration files).
             If no certificates have been explicitly specified by the
CertificateFile directive, ssh will also try to load certificate
             information from the filename obtained by appending
-cert.pub to identity filenames.

but it seems it does something else

holst at hholst-lt:~$ unshare -r
root at hholst-lt:~# echo "~ expands to" ~ "and \$HOME is"
$HOME
~ expands to /home/holst and $HOME is /home/holst
root at hholst-lt:~# ssh sdf.org
Could not create directory '/root/.ssh'.
load pubkey "/root/.ssh/id_rsa": Permission denied
load pubkey "/root/.ssh/id_rsa": Permission denied
load pubkey "/root/.ssh/id_dsa": Permission denied
load pubkey "/root/.ssh/id_dsa": Permission denied
load pubkey "/root/.ssh/id_ecdsa": Permission denied
load pubkey "/root/.ssh/id_ecdsa": Permission denied
load pubkey "/root/.ssh/id_ed25519": Permission denied
load pubkey "/root/.ssh/id_ed25519": Permission denied
load pubkey "/root/.ssh/id_xmss": Permission denied
load pubkey "/root/.ssh/id_xmss": Permission denied
The authenticity of host 'sdf.org (205.166.94.16)' can't be
established.
ED25519 key fingerprint is
SHA256:ZjwbO7AU8rHJExYrmZS2LqGZ7WfdoELfMrF54W92PYA.
Are you sure you want to continue connecting (yes/no)? n
Please type 'yes' or 'no': no
Host key verification failed.
root at hholst-lt:~#

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
It uses the directory returned by the system's getpwnam(3) for the real
userid of the ssh process.  Thus, if you are running it as root then it
always looks in root's home directory.

https://github.com/openssh/openssh-portable/blob/master/ssh.c#L545

It's behaved like this for a long time.  I suspect its original intent
was to prevent $HOME games in the case where the ssh binary was setuid,
which was supported (although very infrequently actually used that way)
up until recently.

-- 
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.

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

--- Comment #2 from hholst80 at gmail.com ---
Would a patch that changes this behavior be accepted as a fix? To use
the environment variable I mean?

-- 
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.

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

chrysn at fsfe.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrysn at fsfe.org

--- Comment #3 from chrysn at fsfe.org ---
An easier fix for the inconsistency between behavior and documentation
would be to remove the reference to HOME from the ssh(1) man page --
but I'd also prefer ssh to just use the HOME environment variable.

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
hmm, ssh.1 doesn't mention in any context related to files it loads, it
just uses '~'

-- 
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.

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

--- Comment #5 from chrysn at fsfe.org ---
Right, it says that it will *set* HOME. (It's just very tempting to
misread the "ENVIRONMENT" section to mean what it means in many other
programs: which variables are *consumed*).

Other docs, such as `contrib/cygwin/README` mention that HOME is *not*
used, but it's unclear whether that's platform dependent, and there are
occurrences of HOME spread in various files.

So there is no inconsistency with documentation. What remains is the
inconsistency with the behavior of shells (looked up bash and zsh), and
all language provided tilde expansions I've checked (GNU libc, Python).

If there is (given Darren's comment: if there is still) a reason to
only use getpwnam, that's fine with me, but please point it out in the
docs (along with the rationale for the behavior) -- but my impression
is that this behavior is a remnant of a long unused mechanism.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.