SSH user without any rights on a server

Jordon Bedwell jordon at envygeeks.com
Fri Jun 24 18:58:53 UTC 2011


On 6/23/2011 7:01 PM, Frank wrote:
> - sshd is listening on port XXXXX instead of port 22

Port scanning fixes that obscurity. Don't bother trying to obscure now
days, they will find it if they want to. This is why on our servers we
leave it as port 22 and then ban ip's as they come.  It's easier for us
to mix fail2ban with custom scripts and remove IP's from the ban list
than it is to try and be clever in a world where obscurity is not clever

> - I added a user "reverseuser" and a group "reversegroup"
> - The user "reverseuser" is not part of any other group but

Non-unique groups that are locked to a sole purpose should not have an
individual group.  Create a group "reverse" and add all fowarding users
to that group that way you can ACL the group and make security
management cleaner.

> - The only allowed user to login on the SSH server is "reverseuser"

As it should be.  Use a TTY for root. Most good providers provide one.

> - The home directory of "reverseuser" is /dev/null
> - the login shell for "reverseuser" is /bin/ssh-dummy-shell
>   ssh-dummy-shell is a script containing "bash -r -c read"

Instead of doing that fumbled mess of improper management, one should
create a key for the user, disable password logins, and then when you
put the key on the server for it to authenticate add: "no-pty,
command="/bin/false" [Key stuff here]" you can also add
permitopen="[IP]:[PORT]" to it as well. This will attempt to prevent an
adversary from abusing the forwarding.  This is a simple pre-"ACL" that
we do on our proxy servers to attempt to deter compromise from an
outside adversary.  You then further that with a PAM backup that does
the same.

More on this can be found here:
http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html < it's
simple to understand.

> The idea behind all that is to allow "reverseuser" from PC A to login to
> the server only to set up the reverse ssh connection and nothing else.
> The server accepts the login request, the ssh link is established. As
> soon as the "reverseuser" presses any key, the connection will be lost.
> And that's OK ! :-)

That's not okay IMO, any good system administrator would not accept such
a fault by design.  You should reject the terminal period, not attempt
to play clever trickery, there is no need for the trickery or gotchas,
whatever you want to call it.

> By the way, the password associated to "reverseuser" is very weak. The
> reason of the whole thing is to be able to assist some friends on their
> Ubuntu laptops. 

Tisk tisk. Arrogance and assumption in this industry leads to a
compromise, ask Sony about that, ask the FBI about that, ask RSA about
that.  You'll regret compromising your own security (and yes, in my eyes
you did compromise your own security)  My suggestion is to use a key,
and if you don't use a key, implement a strong password policy.




More information about the ubuntu-users mailing list