Restricting users direct access to specific users

[Turgay Cavdar]

We have an application user, and we want normal users to logon the system with their own names and su to application user. But we want that application user can still use scp and sftp but direct login disabled for the application user. Can we do such a config from sshd_config file?

[larsoncu]

i'm pretty sure you'd have to be able to login to be able to do scp or sftp. And, if your able to login your going to be able to ssh too.

but maybe there are some key options that might be helpful.

could you explain a little more about why you want the user to have to su?

is the same user doing the scp and sftp as the one you don't want to be able to login?

[Tim Nelson]

Check out your sshd_config man page.

You can set up allowed or denied users for direct login.

Keep in mind that if you do not diable telnet completely they can still sneak in via telnet and circumvent the ssh rules.

[Turgay Cavdar]

What we want is to audit user commands (with execv and execve system calls) . If the application user is shared then you cant understand from audit logs which user run which command, but if they su to application user, yhen you can see which user runs which command from audit log. With DenyUsers directive in sshd_config it is possible to prevent direct login but this way the denied user cant use scp or sftp.

[larsoncu]

for what your doing the answer is no

you can use the no-pty key option to disable interactive login but that still allows commands to be run, as in ssh yourhost 'runmyscript'. If that occurs it is logged by sshd to the log file.

you could use the command option to force which command is run, but then scp won't work.

The best of securing this is to set a separate account to do your file transfers. This account privileges should be limited to just those necessary to do its job.

(to transfer a file all that is needed is read permission on the file and write permission on where the file is going.)

you'll need to keep the account's private key as private as possible (only those that know it could use it to login). separate account, separate home directory (700 perms), separate home/.ssh directory (700 perms), etc.

your probably going to run this out of cron so the account can have its login disabled and it doesn't even need a shell.

use the options on the key in the authorized key file to limit what the key can be used for. use from to only allow the specific user@hosts, and no-pty, no-port-forwarding, no-X11-forwarding, no-agent-forwarding

[Heironimus]

You could probably do it by using scponly or rssh as the application user's shell and using sudo instead of su for shell/command access.