Shell – ssh without using the user’s default shell

There was a vote to close this as "unclear what you're asking". Apparently being thorough isn't a good thing, so I'll be terse:

When you SSH to a remote host: is it possible to execute a program directly instead of being executed under the user's default shell.

• the network is air gapped
• everyone on the network has shell access to every machine
• IT can make whatever changes would be needed, provided those changes wouldn't increase the risk of someone getting a root shell (beyond what's already possible anyway).
• As proof that something like it is possible: sftp, an ssh "subsystem", is able to execute without running the user's default shell, whereas the scp subsystem still uses it.
  • I tried implementing a subsystem, but it still executed under the user's default shell.

I don't think there is a good solution to this problem (short of convincing a large number of non-*nix people to abandon the crutch they've been leaning on for years), but I thought I'd put the question out there in hopes I'm mistaken.

Below is the less terse question.

In my office there's a large number of people (3-500+) all using a variety of strange and bizarre configurations. It's very hard to predict how the software we write will behave for a given user since their environment could totally violate our expectations.

To workaround this I changed our build to strip the user's environment so it couldn't affect the build, and based on the success of that strategy we further wrapped our software's execution in a shell script that does the same sort of thing.

Unfortunately, the launcher can still be affected by the user's environment. When it is executed remotely, the user's .cshrc/.login typically have a bunch of junk that causes long delays before the launcher even begins executing.

Normally I'd be inclined to say "fix your crap", but we're not talking about *nix-savvy people; this is a crutch they've leaned on for years and they're more inclined to continue to blame our software for their configuration issues.

In short, I'm looking for a way to completely short-circuit their goofy environment scripts.

To simulate this situation I set my default shell to tcsh and put hostname; sleep 10 in my .cshrc, then ran a few tests:

• sftp does not print/sleep — though, the target machine in that case was solaris where sftp is built into sshd, and I didn't think to test against a linux box. Running ptree against the process tree servicing the sftp connection shows it's not running under a shell.
• scp prints the text & sleeps for 10s
• every variant of executing commands on the remote host through ssh causes the command to run under the user's default shell; I tried:
  • The obvious — pass a command in over ssh
  • command= in .ssh/authorized_keys
  • I made a custom "subsystem" in my personal linux /etc/ssh/sshd_config
• Enabled PermitUserEnvironment on my machine to try setting SHELL
  • Didn't work at all: SHELL=/bin/bash ssh -o "SendEnv SHELL" localhost
  • Kinda worked: Use environment= or ~/.ssh/enviornment to set SHELL
    • It kinda worked in that SHELL was set, but it actually executes under my true default shell

I managed to use netcat to forward a shell over an existing ssh session, but that seems like using a sledge to crack an egg — both messy and highly inappropriate.

One person in our organization suggested making another user that, through whatever means, everyone would be able to login as that user over ssh, then ::cloudy bubble solution with a lot of hand waving:: to get the program running as the original user.

I'm a little dubious about doing something like that. It may not be as bad as forwarding a shell with netcat, or something heavy-handed and brittle like temporarily renaming their .cshrc, but I'm still not fond of it.

Any suggestions are welcome.