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
scpsubsystem 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
.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
ptreeagainst 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
- I made a custom "subsystem" in my personal linux
PermitUserEnvironmenton my machine to try setting SHELL
- Didn't work at all:
SHELL=/bin/bash ssh -o "SendEnv SHELL" localhost
- Kinda worked: Use
~/.ssh/enviornmentto set SHELL
- It kinda worked in that SHELL was set, but it actually executes under my true default shell
- Didn't work at all:
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.