DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 27th July 2010
pico pico is offline
Real Name: Pico
Complete openbsd beginner
 
Join Date: Mar 2010
Location: Scotland
Posts: 19
Thanked 0 Times in 0 Posts
Default ssh restrictions

Forgive my ignorance and I sure tucked away this will be mentioned already.

I have done a few searches but it's knowing what to search for in these situations with regards to terminology.

I have sewn up the ftp by restricting users to only allow access to home folders.

Is there a way to so the same with ssh accounts? It seems a standard test user can traverse the directories. Granted they cannot commit any nasty commands but it would be great to limit them to their designated areas?

Regards

Pico
Reply With Quote
  #2   (View Single Post)  
Old 27th July 2010
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

See the sshd_config(8) man page, and read the section on ChrootDirectory and the section on Subsystem.

See the sftp-server(8) man page.

---

I have never used ChrootDirectory except with sftp-server. My shell users are granted full shell access.

Here's an example that was once in use on one of my systems:
Code:
Subsystem sftp /usr/libexec/sftp-server
Match User carpetsmoker
        ChrootDirectory /home/carpetsmoker
        AllowTcpForwarding no
        ForceCommand internal-sftp
Reply With Quote
  #3   (View Single Post)  
Old 27th July 2010
pico pico is offline
Real Name: Pico
Complete openbsd beginner
 
Join Date: Mar 2010
Location: Scotland
Posts: 19
Thanked 0 Times in 0 Posts
Default

I had a look into sshd_config and couldn't see any mechanism for confining the user to a specified folder or area.

Maybe openbsd does not have any way of doing this? It may be of the opinion that users should be allowed to look around directory structures and the admin must implement the necessary precautions to stop any tinkering by users?

It would be great to stop users seeing the contents of system folders etc. This may give an intruder a slightly harder time of breaking out of the account?

May knowledge is vary little on this subject but I'm surprised a facility does not exist.

regards

Pico
Reply With Quote
  #4   (View Single Post)  
Old 27th July 2010
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

Please see my example, above, for keeping carpetsmoker in his home directory.
Reply With Quote
  #5   (View Single Post)  
Old 27th July 2010
pico pico is offline
Real Name: Pico
Complete openbsd beginner
 
Join Date: Mar 2010
Location: Scotland
Posts: 19
Thanked 0 Times in 0 Posts
Default

Thanks jggimi

Which file should this information be added to.

Regards

Pico
Reply With Quote
  #6   (View Single Post)  
Old 27th July 2010
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

These are server side configuration settings. They were added to /etc/ssh/sshd_config on the server I gave carpetsmoker access to.

Note that these were for sftp connectivity only. No shell access. For shell access, you would have to set up a complete chroot(8) environment, as discussed in the sshd_config(5) man page under ChrootDirectory.

Let us review each of those configuration statements from above, and what they meant.
Code:
 Match User carpetsmoker
The lines under the "Match" were used whenever the userid of the connecting user was carpetsmoker. For other users, those lines were ignored.
Code:
ChrootDirectory /home/carpetsmoker
I locked carpetsmoker to the directory structure under /home/carpetsmoker. For that userid, his root directory "/" was "/home/carpetsmoker" -- he had no access to any other structure.
Code:
AllowTcpForwarding no
I did not permit any port forwarding for carpetsmoker. No SOCKS proxy, no tunnels.
Code:
ForceCommand internal-sftp
No shell access was permitted, only sftp connection, and only using the internal-sftp subsystem.
Reply With Quote
  #7   (View Single Post)  
Old 27th July 2010
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

FYI

If you want to give shell access, you have a lot of work to do. Not just the device list per ssh_config(5), below, but also any programs and libraries that will be needed. Much of /bin, /usr/bin, /usr/lib, /usr/local/bin, /usr/local/lib will be needed along with the appropriate shell and the /dev nodes described in the man page:
Quote:
The ChrootDirectory must contain the necessary files and
directories to support the user's session. For an interactive
session this requires at least a shell, typically sh(1), and
basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4),
stderr(4), arandom(4) and tty(4) devices. For file transfer
sessions using ``sftp'', no additional configuration of the
environment is necessary if the in-process sftp server is used,
though sessions which use logging do require /dev/log inside the
chroot directory (see sftp-server(8) for details).
Reply With Quote
  #8   (View Single Post)  
Old 27th July 2010
pico pico is offline
Real Name: Pico
Complete openbsd beginner
 
Join Date: Mar 2010
Location: Scotland
Posts: 19
Thanked 0 Times in 0 Posts
Default

Ok sounds a very intricate affair.

I may give this one some thought but it does sound rather involved.

Best Regards

Pico
Reply With Quote
  #9   (View Single Post)  
Old 27th July 2010
jggimi's Avatar
jggimi jggimi is online now
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,429
Thanked 214 Times in 189 Posts
Default

No more than any other chrooted environment.

What you create with chroot(8) is a virtual filesystem structure -- it is not a virtual machine, but close enough to one from a filesystem perspective.

Absolutely any file needed will need to be within that virtual filesystem. Every executable with shared libraries will need to be analyzed with ldd(1). Or, you can replicate the entire OS less those things you wish to keep private.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Forum update, restrictions on new users Carpetsmoker Feedback and Suggestions 31 10th January 2011 10:44 PM


All times are GMT. The time now is 04:07 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick