John Daily <[EMAIL PROTECTED]> writes:
> I'm currently fighting a losing battle to restrict SSH client access to my
> server, and I thought I would pass along my thoughts to the developers of
> lsh and any other SSH clones. (And if anyone has fought this battle and
> won, I'd love to hear about it!)
I definitely see your problem. I would like to provide as fine grained
control as possible. Not only for sysadmins, but also for users: I'd
like to be able to say in my .lsh/authorizations that users owning
certain keys, certificates or passwords should be granted certain
permissions on certain files and directories.
> As I see it, SSH provides 6 general features:
>
> 1) ftp
> 2) Remote copy
> 3) Remote login
> 4) Remote command execution
> 5) TCP port forwarding
> 6) X11 forwarding
>
> Because my interest in SSH is in providing encrypted file transfers to and
> from a specific directory, I'm trying to restrict all of the above except
> for #2, and even that only within the client's home directory.
>
> However, the developers of SSH do not appear to have contemplated this
> need. I can disable 5 and 6 at compile time, and I can use restricted bash
> to make #3 relatively harmless. I can remove the sftp-server to eliminate
> #1, but that breaks #2 as well. Neither #1 nor #4 seem to use the shell
> defined in /etc/passwd.
I think its quite difficult to put restrictions on scp; from the
servers point of view, scp is exactly the same as host ssh scp
--server; i.e. it is just a special case of remote command execution.
As for remote command execution, I think the Right thing is to execute
commands with login-shell -c command (in the protocol, a command is a
string, not an argument vector).
If the remote command execution is fixed to use the login shell, you
could get some restrictions by instaling a special login shell that
allows particular invokations of scp, and nothing else (I'm not very
familiar with the restricted shell, perhaps this is exactly what it
does?). But it does seem kludgy to me, and I also suspect that scp was
not designed to be run by untrusted people.
For sftp, I really don't know. I suspect it is a more natural
candidate for restricting access, but I have not seen any spec about
how it works.
> Anyway, any suggestions are welcome, and I would suggest that developers
> allow the sysadmin to restrict the feature set. I would also suggest that
> features 1-4, if implemented, use the shell defined in /etc/passwd!
For 2-3, I agree completely. For 1, I'm not so sure it's a good idea.
/Niels
