[Bug 3904] New: Feature Request: Support %u token expansion in 'User' config directive

[bugzilla-daemon at mindrot.org]

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

            Bug ID: 3904
           Summary: Feature Request: Support %u token expansion in 'User'
                    config directive
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: f-tornack at t-online.de

Hi everyone,

I would like to suggest a feature enhancement for ssh_config.

Currently, the %u token (local user name) is supported in various
directives (like Hostname, IdentityFile, or Match), but it does not
seem to undergo expansion when used within the User directive itself.

Use Case: My local username often matches the user part of my remote
identities across different domains, but the remote servers require a
fully qualified user string (e.g., user at domain). I would like to define
dynamic users in my config based on the currently running local user to
avoid hardcoding the name.

# Desired behavior in ~/.ssh/config
Host server1
    Hostname server1.example.com
    # If local user is "frank", this should resolve to
"frank at domain1.local"
    User %u at domain1.local

Host server2
    Hostname server2.example.com
    # If local user is "frank", this should resolve to
"frank at domain2.local"
    User %u at domain2.local

Current Behavior: When using the configuration above, the client
attempts to log in literally as the user %u at domain1.local instead of
expanding %u to the local username (e.g., frank).

I believe adding support for %u in the User directive would greatly
simplify configuration management for users operating in multi-domain
environments with consistent local usernames.

Is this something that could be considered, or is there a technical
limitation regarding the parsing order that prevents this?

Best regards and thank you very much

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