I'm self-answering, as I've finally discovered the secret. Neither
-t option for
-l option for
bash will lead to login shell on their own - but in combination they work.
ssh email@example.com -t 'cd /some/where; FOO=BAR NUMBER=42 bash -l' changes directory, sets environment variables, and then starts proper login shell (the only difference I've found so far is that
/etc/motd isn't displayed this way - it's normally
login's responsibility, not
bash's - other than that everything seems to work perfectly, and all environmental variables are identical).
These environment / directory changes happen after ssh, so they're not restricted by
PermitUserEnvironment and related settings (exactly as planned), but before
.profile get executed. This has upsides and downsides - it is harder to just override something that gets set from bash init scripts like
PS1, but easier to pack exactly the right values into
ssh command lines, and have
.profile do all the heavy lifting.
And if really necessary, it's actually pretty easy to get bash to execute something after
.profile with command line like
ssh firstname.lastname@example.org -t 'cd /mnt; echo ". ~/.bash_profile; PS1=\"\\h-\w \"" >~/xxx; bash --init-file ~/xxx' - very ugly when put that way, but these alternative
.profile files can be prepared before.
(as far as I can tell
bash has a few candidate locations for
.profile script and will execute the first one found -
. file doesn't have such automatic fallbacks, so you'll need to check where's your normal
profile if you want to do that)