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: [email protected]
          Reporter: [email protected]

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@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
"[email protected]"
    User %[email protected]

Host server2
    Hostname server2.example.com
    # If local user is "frank", this should resolve to
"[email protected]"
    User %[email protected]

Current Behavior: When using the configuration above, the client
attempts to log in literally as the user %[email protected] 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.
_______________________________________________
openssh-bugs mailing list
[email protected]
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

Reply via email to