openssh bugs - Feb 2023 - [Bug 3543] New: Add a provision to force query of login ID

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

            Bug ID: 3543
           Summary: Add a provision to force query of login ID
           Product: Portable OpenSSH
           Version: 9.1p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: cponder at nvidia.com

I'm using a remote system that doesn't require a password to log on,
but the login-ID is issued by Axis Security and changes every 24 hours.

I'd like to have a setting in the ~/.ssh/config to force it to ask for
the ID (but not the password) when I use ssh/scp commands, as opposed
to me expressing it on the command-line with ```-l $ID``` or ```$ID@```
every time.

That way ssh & scp operations embedded into scripts wouldn't have to be
adjusted every time the ID changes. Also I tried (the longshot) of
overwriting the $USER variable, but it had no effect.

I don't see any way to do this (and have googled around quite a bit to
check), which is a little surprising since you-all had already added
just about anything else I can think of.

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

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

Carl Ponder <cponder at nvidia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|9.1p1                       |8.9p1

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

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

Damien Miller <djm at mindrot.org> changed:

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

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
This wouldn't play nicely with how ssh reads and processes ssh_config.
We need the username before processing the config to resolve "match"
conditionals.

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

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

Darren Tucker <dtucker at dtucker.net> changed:

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

--- Comment #2 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Carl Ponder from comment #0)
> That way ssh & scp operations embedded into scripts wouldn't have
to
> be adjusted every time the ID changes.
You could achieve the same effect as what you're asking for with a
couple of extra lines in those scripts:

  printf "Username: "
  read user
  scp $user at whatever ...

so the script is prompting instead of ssh, but from the user's POV it'd
look the same.
> Also I tried (the longshot)
> of overwriting the $USER variable, but it had no effect.
ssh looks up the username from the id's password entry since in the
past it could be installed setuid so we couldn't trust the environment.
 setuid installations are no longer supported, however and looking up
USER would be trivial, in ssh.c:

        if (options.user == NULL)
-               options.user = xstrdup(pw->pw_name);
+               options.user = getenv("USER") ?
getenv("USER") :
+                  xstrdup(pw->pw_name);

however it would be a user-visible behaviour change.  I don't know how
many installations would have $USER but have it set to something
different, though.

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

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

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Darren Tucker from comment #2)
> +               options.user = getenv("USER") ?
getenv("USER") :
Actually that should probably use LOGNAME since that's specified by
POSIX:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

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

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

--- Comment #4 from Carl Ponder <cponder at nvidia.com> ---
Here's something I *was* able to contrive. I generate a provisional
config-file that gets included back into the main one:
```
Match originalhost thatHost exec "~/.ssh/HACK/queryID thatHost"
include ~/.ssh/HACK/thatHost
```
The provisional config-file is generated by this "qeryID" script:
```
PTY=$(ps --no-headers $$ | xargs index 2)         # Re-connect with I/O
channels.
echo -n "Login: "         > /dev/$PTY             # Require a fresh
User ID.
read LOGIN                < /dev/$PTY
echo "Hostname $1"        > ~/.ssh/HACK/$1        # Re-build the
parameter-file.
echo "User " $LOGIN      >> ~/.ssh/HACK/$1
echo "UpdateHostKeys no" >> ~/.ssh/HACK/$1
sync
```

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

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

--- Comment #5 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Carl Ponder from comment #4)
> Here's something I *was* able to contrive. I generate a provisional
> config-file that gets included back into the main one:
> ```
> Match originalhost thatHost exec "~/.ssh/HACK/queryID thatHost"
> include ~/.ssh/HACK/thatHost
You can put the Include inside the Host block so you only need to put
"User $whatever" in the file that changes:

in ~/.ssh/config:
Host foo
  Include ~/.ssh/foo.user
  Hostname bar
  UpdateHostKeys no

then write "User $LOGIN" into ~/.ssh/foo.user
> sync
Aside: you probably don't need the sync (and it can have a negative
impact on some workloads).

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