Bekijk de volledige versie : Restricting SSH access with non-root users
Hi,
I would like to set up a user account for my friend and make the account accessible through SSH. The purpose of the account is to allow my friend to create a dynamic SSH tunnel via my router. Everything else should be restricted. For example I don't want to give shell access, or if I can't avoid that, then restrict the commands down to the absolute minimum.
I have done some research and here are the options I have encountered:
1. Use dropbear. However I do not know how to restrict dropbear. I read somebody trying to change the users shell to /bin/false but that prevents using the account all together (e.g. in my case, can't create the tunnel).
2. Install openssh. And use rssh. Has anyone tried this on their ASUS router? Are they both supported?
usage of sshd from openssh is a correct solution. Then create key for the user and tune authorized_keys file to establish specific restrictions for a particular user. RTFM sshd.
Well, it turns out you don't need to install OpenSSH for this. I got it working with the default dropbear just fine. I love dropbear!
I'll try to write a post how I did it sometime... If I forget and someone is interested, PM me.
well, you are right, partial support of this feature was added in 0.52:
0.52 - Wed 12 November 2008
...
- Allow restrictions on authorized_keys logins such as restricting commands
to be run etc. This is a subset of those allowed by OpenSSH, doesn't
yet allow restricting source host.
...
well, you are right, partial support of this feature was added in 0.52:
or you could make a user with a script as console?
like in /etc/passwd you can set what will happen after a user logs on
like:
#!/bin/sh
echo press enter to exit
read var
exit
or am I wrong?:p
Just tried your script and it works as expected.
In my solution I just used /bin/false as the shell of the restricted user, and then set no-pty in authorized_keys. However this doesn't leave any graceful way to terminate the connection. But I didn't want to give the user any change of having any kind of shell or interaction with the server (except the tunnel).
Do you think using your script or any custom script will have some security loop holes because of the interaction etc? Can you escape the script somehow? I would rather use a custom script, because it closes the connection in a proper way. But security is top priority.
By the way, one thing worth noting when changing the default shell: You have to remember to add the shell to /etc/shells. Otherwise it won't work:
Oct 18 18:06:66 dropbear[666]: user 'farawayfriend' has invalid shell, rejected
sorry, it's behind my theoretical background. As minimum I know that the login shell should be listed in /etc/shells. The rest requires experimentation ;)
Just tried your script and it works as expected.
In my solution I just used /bin/false as the shell of the restricted user, and then set no-pty in authorized_keys. However this doesn't leave any graceful way to terminate the connection. But I didn't want to give the user any change of having any kind of shell or interaction with the server (except the tunnel).
Do you think using your script or any custom script will have some security loop holes because of the interaction etc? Can you escape the script somehow? I would rather use a custom script, because it closes the connection in a proper way. But security is top priority.
By the way, one thing worth noting when changing the default shell: You have to remember to add the shell to /etc/shells. Otherwise it won't work:
Oct 18 18:06:66 dropbear[666]: user 'farawayfriend' has invalid shell, rejected
nah, I don't think it will leave a security hole if you always end with exit. since with exit bash console will close what results in ssh tunnel closes as far as I know:)
Never tried it myself, but I thought it could be done by setting the shell to: /bin/sh /path/to/script
now you just set the shell to your script and add it to /etc/shells right?:)
if it works like the 2nd way, it should be really safe, because the script doesn't allow anything to execute :)
sorry, it's behind my theoretical background. As minimum I know that the login shell should be listed in /etc/shells. The rest requires experimentation ;)
By default the custom firmware doesn't have /etc/shells at all. So I created it and added two lines
/bin/sh
/bin/false
and everything works perfectly.
As I mentioned in my previous post, without these lines you can't login with ssh if the shell is set to a non-standard shell like /bin/false.
nah, I don't think it will leave a security hole if you always end with exit. since with exit bash console will close what results in ssh tunnel closes as far as I know:)
Never tried it myself, but I thought it could be done by setting the shell to: /bin/sh /path/to/script
now you just set the shell to your script and add it to /etc/shells right?:)
Right, this is the way I tried it and it worked.
Here's hoping it doesn't have any holes! :p