PATH variable wouldn't make any difference: if the users can run a shell command, then they could still set the variable, or run commands by giving their full path. If they somehow get access to a shell, you've lost.
Changing their shell to another does mean that their confined to that program — and anything they manage to launch from that program.
There is another way to restrict users who can only log in with SSH: you can give them a key (and not put a password on the account, so that the only way to log in is with the key), and put a
command=… restriction in
authorized_keys (see the
sshd man page. This allows setting different commands on different keys for the same account, which may or may not be useful. Note that if you rely on restrictions in
~/.ssh/authorized_keys, you should make the user's home directory, the
.ssh directory and its content owned by root so that the user cannot modify them.
If the program you want to give access to uses terminal interactions or is a stream filter, then dedicated SSH access is a good way to provide that service. If the program only produces output from a tiny amount of input, or if the program uses a fill-in-a-form type of interaction, then HTTPS would be more suited. Don't invent your own protocol on top of SSL for this — use whichever of remote shell (via SSH) or HTTP (via HTTPS) is the best for your program's interface. HTTPS will be easier to use for most users.
If you want to give the users some limited shell access that only allows them to run a limited set of commands, you can make their shell
rbash, a restricted shell. Beware that restricted shells are hard to set up correctly: you need to make sure that none of the available programs have a shell escape (GNU
sed, non-restricted versions of
To confine the users more, jail them as much as possible. This can range from a mere
chroot (which limits the files that the users can access if they manage to trick your program) to giving them an account only inside a full-blown virtual machine.