User input disabled with scripts launched for .ssh/rc?
 

Greetings all,

Am needing some expert advice here, hope to get some help :)

I'm currently making use of the $HOME/.ssh/rc file to launch an automated shell script immediately after the user has been verified through ssh.

The current problem that I'm facing now is that I am unable to use the "read" command anymore... seems like the "read" statements are being bypassed as though as they were commands. This poses a huge issue, since I need to run several other scripts with heavy use of the "read" command as subshells.

Is there a way to work around this problem? Or is this part of some security feature in ssh that prevents one from accepting user inputs? I am currently interested in having the rc file launch certain groups of users (whose names can be found in a text file residing on the server) directly into another shell. Was thinking of a more automated approach, but seems like it'll be hard.



Thanks in advance.

From the ssh manpage.
What kind of user input do you need?
Note the (or command) part. You can configure the user's client so that it runs a command instead of the shell. Use that instead of rc.

I think you should use sshd_config "AllowGroups" or "AllowUsers" instead to control access.

Sorry, but this is one of my pet peeves. I see a lot of people posting sample bash programs reading in arguments instead of using the command arguments.

Thanks a bunch! Really useful expert advice you've got there...

Was originally intending to use .ssh/rc to limit what the user can do. My initial plan was to get ssh to launch into one of my script files immediately after verification to prevent the user from having the chance to hit the command prompt. Wonder if this can be achieved without using rc?

Will definitely take into consideration the user and groups access rights method which you recommended :)

It sounds like you want to present the user with a menu of things they can do. Perhaps a shell program using the select/case commands which launches other scripts, based on the users selection. You could use the ForceCommand for that. It launches the users shell with the -c option to run a single command.

If these are users who are only ones allowed to use ssh, and don't have full normal accounts on the server (no home directories), you can change their default shells in /etc/passwd to /bin/rbash. You could create a home directory and use the same home directory for all of these ssh users. Let's say it is /home/sshusers/. That directory could be in multiple home directory entries in /etc/passwd. That gives you the option to create a /home/sshusers/.profile file which could further define the environment and options of the restricted shell.

I'm not certain from the manpages whether or how you could have per-user differences in the ssh server setting. If you want to be able to login remotely yourself, you wouldn't want the "ForceCommand" option. So a user entry like "/bin/rbash -c /home/sshusers/bin/script.sh" for just those users might work out best in this case. This would also allow you to create different groups of these remote users, by creating a home directory for each group, each with a custom ~/.profile script.

Also look through the bash info manual at traps. You might want to trap all errors to prevent a problem from dropping the user into the shell.

You could also run two sshd daemons. One for general use that you and other full access users would use and a second one for these users. Use different ports and either different config files (-f config-file option) or different -o options when they are launched.