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.
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.
(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@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.
(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
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 ```
(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).
I know this is getting off-topic, but can you help me here? I tried adding an "ssh" operation to test if the current setting is valid, and only query if it can't get through: Match originalhost thatHost !exec "ssh -T -F ~/.ssh/HACK/thatHost thatHost true" exec "~/.ssh/HACK/queryID thatHost" include ~/.ssh/HACK/thatHost I can run the "ssh" part on the command-line and see the exit-code is 0 or 1 of it does/doesn't work. But inside the ssh_config it seems to always return 255, and I'm thinking that "ssh" ops may be illegal inside the config-file. Is this true? Since I'm invoking it with a different config-file, there's no real recursion going on.