I think you can achieve the "best" outcome as follows. (1) sshd forces the user to run a particular command, e.g. with the ForceCommand mechanism or "command=" in authorized_keys. This command is a script that works as follows.
(2) The script checks to see what the user-requested command is (stored in the SSH_ORIGINAL_COMMAND environment variable). (3a) If SSH_ORIGINAL_COMMAND is blank or doesn't contain "mosh-server", the script runs the BBS program. End. (3b) If SSH_ORIGINAL_COMMAND contains "mosh-server": (4) The script scans the command-line and collects the -s, -i, -p, and -c arguments, if any. (5) The script then runs mosh-server new [args] -- bbs_program. End. Another option is just to edit the mosh-server source code to just hardcode the BBS program as the thing it runs (ignoring any command-line argument or the user's shell). Hope this helps. Cheers, Keith On Sun, Aug 4, 2013 at 11:13 PM, Gordon Morehouse <[email protected]>wrote: > Hi there, > > I have an old BBS program that allows ssh login by means of simply > executing it as the user's shell; this presents problems for mosh users. > > I'm wondering how to work around it. > > Best: mosh users connect to the same [email protected] as everyone else > > Good: mosh users connect to a different [email protected], mosh starts > up, then they immediately must execute the BBS shell with no > chance to 'escape' (eg, run a real shell) > > Any other possibilities? > > Ways to run certain programs (eg mosh-server) and *then* weird shells or > a set program that (in general) doesn't allow the user to escape to a > real shell? > > Thanks much, > -Gordon M. > _______________________________________________ > mosh-users mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/mosh-users >
_______________________________________________ mosh-users mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/mosh-users
