How can I configure sshd to only allow connections for login (ssh name@host) and not allow remote commands like (ssh name@host who)?

This is on Red Hat 6.X.

Create the login as a "jailed" user and only put the commands you want them to have in their jailed account. This would also restrict them to only see files in the jail so they can't see the rest of the OS.

You can also restrict the jail to only allow sftp and not full ssh command line access.

Thanks for the information, but I am looking for a solution that is not User Specific, but overall System. This is for an Application Server where when the user (100's of different ones) logs in, they use the same /home directory and the .profile then executes the Application. They have no access to the shell to do commands. A security audit pointed out that a User could use Putty and configure it to run a command like /bin/bash and drop into an interactive shell and run various commands. The examples in my original post was to show I want to restrict them to just logging in and not be able to run other commands.

That is totally up to the shell the user is given.

That is sometimes called a "jailed user", "captive user", or "restricted shell".

They are limited to what the shell allows.

Naturally you don't allow them to use a compiler.

You can even create a shell that uses a chroot environment, then only put the commands they are allowed to use in that environment.

Ah this takes me back.

Years ago we wanted to restrict users so they could only access the application.

The way we achieved that was to simply "exec" the application in the user profiles. exec says to replace the shell with the application command. When they exit the application instead of dropping to a shell prompt they are exiting the system completely. Any command that terminates automatically exits. (e.g. try "exec ls")

We also had to trap signals so smart users couldn't break out of the login process before it got to the exec. We'd put the trap statement in the /etc/profile (system profile used by ksh - you'd want something like /etc/bashrc instead for bash). The exact details of what I did then are long gone from memory but this link seems to have a good explanation of the concepts along with a lot of good overview information.

That is pretty mush what we are doing. As I said, all the User use the same ${HOME}directory and they all run ksh not rksh, so it uses the .profile in the ${HOME} and it does do (exec application) so they never get a shell prompt and when they exit the Application they are logged off. This all works fine if there Putty Configuration does not specify to run a command, just login. But if the Putty Configuration specifies as an example (/bin/bash -i) then it does not use the ${HOME} .profile and they get a shell prompt.

I have looked at the ForceCommand in /etc/ssh/sshd_config thinking that would only affect sshd when the User specified a command, but it also runs when no command is specified.

So I am looking for some other sshd_config parameter that will not affect a basic ssh connection to do a login. It may be a combination of parameters I have to set and was hoping somebody else has already been down this road and I don't have to spend hours tying various combinations.

I have already Googled and found nothing. There are lots of suggestion to use AllowUsers and DenyUsers and another parameter I cannot remember now that specifies what a commands a user can run based on their Keys.

I don't believe you will find one.

ssh always executes the users specified shell. Even with login (and the use of "trap") isn't guaranteed to work as it simply sets up a race condition - does the interrupt occur before the setting of "trap" or after?

Been there, and even broke it - usually it depends on some rather busy disk traffic to slow down the shell accessing the .profile. But it is possible.

The only thing that really works is to set the users shell to a specific restricted shell or application.

Nothing else works reliably.

Here is what I have done. I have users that need to execute maybe 2-3 different commands. I wrote a Haskell program that acts as their shell and presents a menu. They choose the menu item and it makes an exec system call that does what they need to do. It might be overkill for you since it has a config file that it reads, sets environment variables, emails sysads, can run things as a particular user, etc.

I wonder if you are doing it backwards. Is it just a single application that gets launched? If so, why not set their shell to a wrapper script that runs the application?

Can you clarify what you mean by login? Surely once they are logged in with an interactive session they will be able to run whatever programs they want with whichever options they choose to apply.

You might be able to use "pam" to force it to just execute the application. Haven't done it myself but this link tells you how to run specific commands via "pam".

PAM is non-standard and complex and prone to error. The way to force commands would be "ForceCommand" in sshd_config or prepending command="..." to the public key in authorized_keys. See "man sshd_config" and "man sshd" respectively. However, neither would allow a normal interactive shell, unless the forced command is the shell itself. I guess either could call on the $SHELL variable which should be set by that time already. However, it'd still help to get clarification from the OP.

Say what? Pam exists and is used by default on most Linux distros for basic authentication so far as I'm aware. Modifying it is certainly something one must do carefully but many people do so for assorted and sundry reasons.

Your sshd idea might be the way to go but I couldn't find much on forcing sshd to use a specific login command when I did a web search and in fact found many saying it couldn't be done in sshd as that isn't its purpose. It was at that point I began looking for how one might accomplish it via pam and found the link I provided.

Yes, Pluggable Authentication Modules (PAM) are present on most distros, but apparently there are quite a few overlapping, but not quite the same, variations. PAM are better than what came before them but really need re-working now that a few decades have passed. However, it may be too big a task to do without major buy-in and the systemd fiasco has made everyone even more resistant to what might be perceived as change for the sake of change.

I should get Michael W Lucas' book on PAM just to reward him for digging through all that muck. However, since PAM was first released, I've only needed to adjust it three times. The rest of the time, I've been able to work directly with the services in question.

This problem might be a case of TMTOWTDI.

I think the OP would be happy if he got multiple ways to do it so he could pick one. So far none of us have given him a single way - just hints on how we'd go about it if we had to do it.