Helpful Information
 
 
Category: BSD Help
OpenSSH

I'm trying to install openssh. Here are the steps I took and the errors I got:

1) cd /usr/ports/security/openssh
2) make install clean

Error I got

building shared library pam_ssh.so
/usr/libexec/elf/ld: cannot find -lgcc_pic
*** Error code 1

Stop in /usr/ports/security/openssh/work/ssh/pam_ssh.
*** Error code 1

Stop in /usr/ports/security/openssh/work/ssh.
*** Error code 1

Stop in /usr/ports/security/openssh.
*** Error code 1

Stop in /usr/ports/security/openssh.
*** Error code 1

Stop in /usr/ports/security/openssh.
*** Error code 1

Stop in /usr/ports/security/openssh.


Thanks!

1) What is your uname -r
2) Last modified-time and size of /usr/ports/security/openssh/Makefile
3) What version of OpenSSH are you expected to install?

1) What is your uname -r4.3-RELEASE


2) Last modified-time and size of /usr/ports/security/openssh/Makefile1) April 2, 2001
2) 3018 (bytes I think?)


3) What version of OpenSSH are you expected to install?It is OpenSSH 2.2.0

Thanks for the help btw.

4.3-RELEASE already got OpenSSH_2.3.0. Run ssh -V and see.

How can I uninstall this? I'm trying to use a tutorial on how to create a jail and make it so when a person is in ssh, they can't cd above their directory or to any home directory. I just want them to be able to use editors, maybe compilers, get mail, and chmod stuff in ssh. I already got ftp set up so there home directory is there / directory. The tutorial has stuff in it that I can't find on the machine like ssh-dummy-shell or something like that. Is there an easier way to do this? I saw something about chroot but couldn't figure out how to get it to work. Thanks!

>> maybe compilers

That's no way. When you compile something, your source will rely on other files all over the system.

>> I already got ftp set up

That's as simple as putting the username in /etc/ftpchroot file.

>> Is there an easier way to do this?

No and I don't think you are ready for it as there are so many essential things (couple thousands) you should first do or learn before even bother to try chrooting sshd.
Since you are running an old version and tracking -RELEASE branch, which don't even quality to be called a FreeBSD user, why don't you at least try to upgrade to 4.4-STABLE and recompile a kernel. There are just so many other things you should first do to secure your system internally or externally instead of chrooting sshd.

>> I just want them to be able to use editors, maybe compilers, get mail, and chmod

1) editors
Why your users need to use editors at all? Why can't they edit stuff on their own PC?

2) check mail
Why can't they just check messages with their email client or perhaps you can run a webmail?

3) compilers
Why they need to compile stuffs?

4) chmod
They can chmod via FTP and they should have the permission to chmod files owned by them. If you are talking about allowing them to chmod something owned by someone, that defeats the purpose of setting up sshd in chroot.

Why don't you disable shell access altogether or enable it and secure your local environment like assigning them in a special group or so. Check /etc/login.conf (5).

Mainly what I'm doing, I have two computer running freebsd, one at home, one at school on a small lan. I'm trying to learn the stuff so that I can use it in the future. Right now, there are accounts that some other people (students and teachers) use to login. I want them to be able to use startx and all that, but I don't want them to be able to access other people's files or root files like the group and passwd files. I already made it so they can't access other people's files, except now, when they try to access their sites (for testing purposes) through ip.ad.dr.ess/~user, they get a forbidden error. I just want the root files to be secure and their own files to be secure so they have a safe place to store stuff. Thanks!

>> through ip.ad.dr.ess/~user, they get a forbidden error

Check your <Directory "/home/*/public_html>. If you haven't enabled Indexes, and the user doesn't have index.html file in their docroot, then you will get [403].
Keep in mind, the user Apache runs as need search access to /home/user/public_html directory. If not, you also will get [403]. Search access is Read + Execute permission. That said, if Apache runs as nobody, you need to chmod /home, /home/username and /home/username/public_html to 755 (drwxr-xr-x).

>> I just want the root files to be secure and their own files to be secure so they have a safe place to store stuff

If your box mainly is to serve as a web server, and you are concern about security that much, try suEXEC. Do a seach in Apache forum under my username with the keyword suEXEC, then read the threads from oldest to newest.

I'm sorry, but I still can't figure out how to use suexec? I can't download it and I couldn't find a module for apache. Is it already built into apache? Do I have to rebuild apache? Thanks.

>> I still can't figure out how to use suexec?

You should read the docs from Apache website.

>> Is it already built into apache?

No but it's in the src and you can enable it.

>> Do I have to rebuild apache?

Yes.

Here is an example of directory layout and permission for post-install configuration -> http://forums.devshed.com/showthread.php?s=&threadid=18485&forumid=15

Here is how to enable suexec (you can alter this file directly -> /usr/ports/www/apache13/Makefile or send make options:

CONFIGURE_ARGS= --prefix=${PREFIX} \
--enable-module=most \
--enable-shared=max \
--with-perl=${PERL} \
--with-layout=${FILESDIR}/FreeBSD.layout:FreeBSD \
--suexec-docroot=/www/htdocs \
--enable-suexec \
--suexec-caller=www \
--suexec-logfile=/var/log/apache/suexec_log \
--suexec-userdir=public_html \
--suexec-uidmin=1000 \
--suexec-gidmin=1000 \
--suexec-safepath=/usr/local/bin:/usr/bin:/bin \
--without-confadjust \
--enable-module=auth_db \
--disable-module=auth_dbm \
--enable-module=mmap_static \
--enable-module=define

And in this example, of course, you need to create a user and group called www as shown in above --suexec-caller.

You should do further search, maybe do a search in all open forums under my username. Like the link I posetd above is actually in PHP forum.

Isn't suexec just a cgiwrapper? Will this stop people from editing files like passwd and group? Will this keep people out of other users directories? Thanks.

Take a look at this thread again -> http://forums.devshed.com/showthread.php?s=&threadid=18485&forumid=15 since it answers all of your permission questions.

I really don't want to throw you the answers, that doesn't help at all. suexec, if configure properly, can be very secure internally. On the other hand, if you don't have deep understanding of it, it's worse off and you can make your box vulnerable for local abuse. Please take a few moment and read thru all my posts by searching all open forums with the keyword suexec under my username.

>> Will this keep people out of other users directories?

To put it simple, they can't even cd into other user's dirs.

I tried the stuff you said though and nothing worked. I made all the directories, enabled suexec (it says it's enabled with httpd -l), and did the permissions. Now what is supposed to happen? Sorry, I'm just a little confused on what this does still. So suexec is running. The suexec-docroot=/www (accidentally did this instead of /www/htdocs, hopefully it won't hurt anything). I made users have a directory in /www/htdocs/username and then did all the permissions like in the other thread. I'm not sure what to do now. Sorry.

>> The suexec-docroot=/www

This actually is the correct path for vhost environment so that a vhost path can be /www/vhosts/vhost.com/htdocs, which is under /www.

>> I made users have a directory in /www/htdocs/username

No. Userdir depends on what you set for --suexec-userdir=public_html. In this case, user's docroot is at ~username/public_html (usually /home/username/public_html).

Here is the permission for userdir:

/home - 755 (drwxr-xr-x) - root:wheel
/home/matt - 755 (drwxr-xr-x) - matt:matt
/home/matt/public_html - 755 (drwxr-xr-x) - matt:matt
/home/matt/private - 750 (drwxr-x---) matt:matt #this dir is not under your docroot nor is this directory searchable by anyone except root and yourself. But files within this dir are writable only by your CGI scripts

What happened to /www/vhosts/domain.com? Don't their directories have to be under /www since that is the suexec docroot?

>> Don't their directories have to be under /www

That's why as I said for vhost environment, set suexec-docroot=/www option in /usr/ports/www/apache13/Makefile.
You were talking about user environment, that's for userdir configuration and setting --suexec-userdir=public_html should do just fine for that. Keep in mind, they are different thing.

Here is how the directory layout might look like under vhost environment:

/www - root:wheel - 755 (drwxr-xr-x)
/www/htdocs - root:www - 2750 (drwxr-s---)
/www/icons - root:www - 2750 (drwxr-s---)
/www/cgi-bin - root:www - 750 (drwxr-x---)
/www/vhosts - root:www - 755 (drwxr-xr-x)
/www/vhosts/vhost1.com - vhost1:www - 750 (drwxr-x---)
/www/vhosts/vhost1.com/htdocs - vhost1:www - 2750 (drwxr-s---)
/www/vhosts/vhost1.com/cgi-bin - vhost1:www - 750 (drwxr-x---)
/www/vhosts/vhost1.com/cgi-bin/script.cgi - vhost1:vhost1 - 700 (-rwx------)
/www/vhosts/vhost1.com/private - vhost1:vhost1 - 700 (drwx------)
/www/vhosts/vhost1.com/private/passwd.txt - vhost1:vhost1 - 600 (-rw-------)

Create another vhost (vhost2.com) respectively under /www/vhosts/.

In this setup, nobody except root and user vhost1 can cd to your private directory. As you can see, passwd.txt has 600 permission, thus, nobody execpt vhost1 and root can read+write to it. Well, actually other users can't even cd to your private directory because they don't have search access and unable to stat files within it.
Now let's take a look cgi-bin directory. It has 750 permission owned by vhost1 and grouped by www but deny all others seach access.
Why give www search access?
Because the user Apache runs as (www) needs to stat your script (locate the script), but not necessarily read or write it. To have search access, hint, one needs READ + Exec. To have Exec access, vhost needs READ + Exec, hint, you can't exec it if you can't even READ it. That said, your script.cgi with 700 permission is the appropriate permission in suEXEC environment. Technically, you can even chmod your script to be 500 (-r-x------) if you don't plan on editing it in the future.
The htdocs directory with 2750 permission (drwxr-s---), note the s with sticky-bit set, so that the same group is preserved when creating files or uploading files via FTP into your htdocs directory.
So what's the permission for /www/vhosts/vhost1/htdocs/index.html?
That's 640 (-rw-r--). User www just need READ access and that's all. Yes, www can read it but vhost2 can't.
Here is another issue I addressed in my other post, let me post it here again in case you missed it.
User vhost2's CGI scripts run as vhost2, not www, therefore, vhost2 has no access to your CGI scripts. If he writes a CGI script to open your index.html for reading, he can't either, because his script will run as vhost2. In mod_php, however, will be execute as www user, so it's possible for vhost2 to write a script.php and browse your cgi-bin directory, but still unable to READ your script.cgi.

The $HOME for vhost1 should be set to /www/vhosts/vhost1.com in this case.

This starts getting off-topic. If you have further questions, please start a new thread in Apache forum.










privacy (GDPR)