Discussion:
SSH Chroot in Nexenta?
Roger Bumgarner
2008-08-12 17:17:25 UTC
Permalink
I have a zone on my Nexenta box that I want to use as my external
facing SSH gateway. I wanted to set the user(s) up in a chroot
environment so all they could SSH in with RSA keys and then SSH and
authenticate on other boxes / zones in the network. However, I've
been reading a lot and trying a variety of different things and have
been unable to get things working. One of the articles even claimed
that Solaris 'ldd' fails to report everything.

Does anyone have any tips or places to read? Or alternative solutions?

Thanks,
-rb
Tim Spriggs
2008-08-12 18:19:00 UTC
Permalink
Why not just dedicate the zone to ssh?

Zone's are a lot more protection from the main system than a chroot env.
Putting a chroot in a zone seems like extra effort for not much gain.

Failing that, what problems are you experiencing when attempting to
build the chroot env?

Cheers,
-Tim
Post by Roger Bumgarner
I have a zone on my Nexenta box that I want to use as my external
facing SSH gateway. I wanted to set the user(s) up in a chroot
environment so all they could SSH in with RSA keys and then SSH and
authenticate on other boxes / zones in the network. However, I've
been reading a lot and trying a variety of different things and have
been unable to get things working. One of the articles even claimed
that Solaris 'ldd' fails to report everything.
Does anyone have any tips or places to read? Or alternative solutions?
Thanks,
-rb
_______________________________________________
gnusol-beginners mailing list
http://lists.sonic.net/mailman/listinfo/gnusol-beginners
Roger Bumgarner
2008-08-15 07:15:26 UTC
Permalink
Why not do both? I don't want the SSH users to have any access beyond
connecting and ssh to other servers. It does seem excessive, but it's
partially a learning experience too.

The main problem is even getting a shell to open. Neither 'bash' or
'sh' seem to be satisfied with having all the libraries from 'ldd
/usr/bin/bash' in the chroot. I even tried using 'truss bash' and
grepping the output for file opens, but nothing new showed up.

In lieu of making a chroot, I was thinking I could just change
permissions for everything that ssh-users dont need to something like
700, but that solution poses the same problem: just what exactly DO
ssh-users need?

Thanks again,
-rb
Post by Tim Spriggs
Why not just dedicate the zone to ssh?
Zone's are a lot more protection from the main system than a chroot env.
Putting a chroot in a zone seems like extra effort for not much gain.
Failing that, what problems are you experiencing when attempting to build
the chroot env?
Cheers,
-Tim
Post by Roger Bumgarner
I have a zone on my Nexenta box that I want to use as my external
facing SSH gateway. I wanted to set the user(s) up in a chroot
environment so all they could SSH in with RSA keys and then SSH and
authenticate on other boxes / zones in the network. However, I've
been reading a lot and trying a variety of different things and have
been unable to get things working. One of the articles even claimed
that Solaris 'ldd' fails to report everything.
Does anyone have any tips or places to read? Or alternative solutions?
Thanks,
-rb
_______________________________________________
gnusol-beginners mailing list
http://lists.sonic.net/mailman/listinfo/gnusol-beginners
Tim Spriggs
2008-08-16 05:37:04 UTC
Permalink
I'm all for learning experiences...

So what errors are you seeing exactly?

I imagine that you'll need the device tree available in the chroot for
proper access. You can probably get a good idea from lsof or the dtrace
equivalent. To do this you should look at lofs (kind of like a bind
mount in Linux)

When you ldd, don't forget to ldd the shared libs. It's a multi-level
dependency that needs to be resolved.

without actual errors I am just stabbing in the dark.


Another solution is to implement (or find) a minimal shell that highly
restricts user activity.

Yet another solution is ssh-proxy (no experience here, I just know OF it)

-Tim
Post by Roger Bumgarner
Why not do both? I don't want the SSH users to have any access beyond
connecting and ssh to other servers. It does seem excessive, but it's
partially a learning experience too.
The main problem is even getting a shell to open. Neither 'bash' or
'sh' seem to be satisfied with having all the libraries from 'ldd
/usr/bin/bash' in the chroot. I even tried using 'truss bash' and
grepping the output for file opens, but nothing new showed up.
In lieu of making a chroot, I was thinking I could just change
permissions for everything that ssh-users dont need to something like
700, but that solution poses the same problem: just what exactly DO
ssh-users need?
Thanks again,
-rb
Post by Tim Spriggs
Why not just dedicate the zone to ssh?
Zone's are a lot more protection from the main system than a chroot env.
Putting a chroot in a zone seems like extra effort for not much gain.
Failing that, what problems are you experiencing when attempting to build
the chroot env?
Cheers,
-Tim
Post by Roger Bumgarner
I have a zone on my Nexenta box that I want to use as my external
facing SSH gateway. I wanted to set the user(s) up in a chroot
environment so all they could SSH in with RSA keys and then SSH and
authenticate on other boxes / zones in the network. However, I've
been reading a lot and trying a variety of different things and have
been unable to get things working. One of the articles even claimed
that Solaris 'ldd' fails to report everything.
Does anyone have any tips or places to read? Or alternative solutions?
Thanks,
-rb
_______________________________________________
gnusol-beginners mailing list
http://lists.sonic.net/mailman/listinfo/gnusol-beginners
David M Johnson
2008-08-17 06:49:15 UTC
Permalink
The other option I would have thought is to look at Role Based Access
Control (RBAC) as this should mean that you could set the using logging
in to the system to only be able to run a restricted set of commands

Cheers

David
Post by Tim Spriggs
I'm all for learning experiences...
So what errors are you seeing exactly?
I imagine that you'll need the device tree available in the chroot for
proper access. You can probably get a good idea from lsof or the
dtrace equivalent. To do this you should look at lofs (kind of like a
bind mount in Linux)
When you ldd, don't forget to ldd the shared libs. It's a multi-level
dependency that needs to be resolved.
without actual errors I am just stabbing in the dark.
Another solution is to implement (or find) a minimal shell that highly
restricts user activity.
Yet another solution is ssh-proxy (no experience here, I just know OF it)
-Tim
Post by Roger Bumgarner
Why not do both? I don't want the SSH users to have any access beyond
connecting and ssh to other servers. It does seem excessive, but it's
partially a learning experience too.
The main problem is even getting a shell to open. Neither 'bash' or
'sh' seem to be satisfied with having all the libraries from 'ldd
/usr/bin/bash' in the chroot. I even tried using 'truss bash' and
grepping the output for file opens, but nothing new showed up.
In lieu of making a chroot, I was thinking I could just change
permissions for everything that ssh-users dont need to something like
700, but that solution poses the same problem: just what exactly DO
ssh-users need?
Thanks again,
-rb
Post by Tim Spriggs
Why not just dedicate the zone to ssh?
Zone's are a lot more protection from the main system than a chroot env.
Putting a chroot in a zone seems like extra effort for not much gain.
Failing that, what problems are you experiencing when attempting to build
the chroot env?
Cheers,
-Tim
Post by Roger Bumgarner
I have a zone on my Nexenta box that I want to use as my external
facing SSH gateway. I wanted to set the user(s) up in a chroot
environment so all they could SSH in with RSA keys and then SSH and
authenticate on other boxes / zones in the network. However, I've
been reading a lot and trying a variety of different things and have
been unable to get things working. One of the articles even claimed
that Solaris 'ldd' fails to report everything.
Does anyone have any tips or places to read? Or alternative solutions?
Thanks,
-rb
_______________________________________________
gnusol-beginners mailing list
http://lists.sonic.net/mailman/listinfo/gnusol-beginners
_______________________________________________
gnusol-beginners mailing list
http://lists.sonic.net/mailman/listinfo/gnusol-beginners
Loading...