I am trying to set up a restricted shell for a user. I want to restrict it to only a few commands. I was going to use rbash, but I don't have that. I have bash -r which cannot be set as the default shell like rbash can.

What I have tried:
tried using chsh to set to /bin/bash -r
modified /etc/passwd to say /bin/bash -r: got error that it can't find it.
created /bin/rbash which justs executes /bin/bash -r and set the shell to that, got an error (not to mention that 'exit' would just put the user in the unrestricted shell).
I tried putting /bin/bash -r in .ssh/rc but I that did not put me in the restricted shell (and would have had the same flaws as the last one)

Everything I have looked up says to just use rbash for the default shell, and comments for people that don't have rbash, they just say to use bash -r.

How do I get into restricted mode when a user logs in?

Can I ask what it's for, what kind of user this is (human, application, has persistent home, is allowed network access) and what commands you want to restrict access to?

human that can only run certain commands. I am creating an account for a specific set of users, that will be running a limited set of commands (specific commands which I could put in its own PATH, most are proprietary). The issue is that the UN/PW are published in an internal document There is concern that if it got into the wrong hands, and they were to somehow access the machine on its isolated network, there would be some protection. I'm not really going down this path anymore, but it would be nice to know how to do it if I ended up having to go back and make it more secure.

OK, so basically we're answering this one for, what?

I'd force SSH access to the box if possible since pubkey auth can't be circumvented (of course the sshd needs to deny password auth), it allows for starting an auditing trail, it allows you to force them running a command and it allows you to restrict network access. For the applications I'll assert they're CLI-only and I'll try to make sure there's enough of a logging trail to audit for morons, mischief and malice. There's a few methods I can think of right now, each with their own strengths and weaknesses. Some elements can be mixed I'm sure. Additions and corrections welcome. In no particular order:
0. GRSecurity with TPE enabled. GRSecurity enhances host security (amongst others chrooting), enhances logging (audit trail) and Trusted Path Execution denies users to execute commands outside their set path. Con: you'll need to patch the kernel. In 2.6 SELinux and GRSecurity seem to be able to live together but I haven't tried that myself.
1. SELinux. With the MLS policy there is absolutely *no* access allowed without proper context. A derivative would be to use the easier targeted policy instead but have those users not run as "user_u:system_r:unconfined_t" but subject to a custom policy that confines their movement. Con: MLS appears to be intensive to set up. A custom policy means adding the framework for these accounts, the applications and any transitions.
2. Virtualisation. The app runs inside a VM which can only be accessed from localhost through certain accounts.
3. PAM. On PAM-enabled systems users have no access to commands run as root unless they have the password. Basically this is done by setting the users PATH elelments so that /usr/bin precedes say /sbin and the link to the application triggers the PAM 'userhelper' / /etc/security/console.* stuff. Cons: probably, if DAC permissions are excessive.
4. Rootsh plus login menu plus sudo. Users are presented with a text-based menu on login instead of a shell. The menu doesn't allow for it to be backgrounded, allows only access to a set of commands, accepts no other input and logs the user out in case of breakage. The menu runs inside rootsh which provides a wrapper (audit trail again) which logs all commands. The applications run under different users than those logged in and can onyl be accessed with NOPASSWD sudoers entries. Con: can't think of any right now.