10.1 - Why does it say that I'm in the wrong group when I try to su root?
Existing users must be added to the "wheel" group by hand. This is done for security reasons, and you should be cautious with whom you give access to. On OpenBSD, users who are in the wheel group are allowed to use the su(1) userland program to become root. Users who are not in "wheel" cannot use su(1). Here is an example of a /etc/group entry to place the user ericj into the "wheel" group.
If you are adding a new user with adduser(8), you can put them in the wheel group by answering wheel at Invite user into other groups: This will add them to /etc/group, which will look something like this:
If you are looking for a way to allow users limited access to superuser privileges, without putting them in the "wheel" group, use sudo(8).
10.2 - How do I duplicate a filesystem?
To duplicate your filesystem use dump(8) and restore(8). For example. To duplicate everything under directory SRC to directory DST, do a:
# cd /SRC; dump 0f - . | (cd /DST; restore -rf - )
dump is designed to give you plenty of backup capabilities, and it may be an overkill if you just want to duplicate a part of a (or an entire) filesystem. The command tar(1) may be faster for this operation. The format looks very similar:
# cd /SRC; tar cf - . | (cd /DST; tar xpf - )
10.3 - How do I start daemons with the system? ( Overview of rc(8) )
OpenBSD uses an rc(8) style startup. This uses a few key files for startup.
The main files a system administrator should concentrate on are /etc/rc.conf, /etc/rc.local and /etc/rc.shutdown. To get a look of how the rc(8) procedure works, here is a the flow:
Most daemons and services that come with OpenBSD by default can be started on boot by simply editing the /etc/rc.conf configuration file. To start out take a look at the default /etc/rc.conf file. You'll see lines similar to this:
ftpd_flags=NO # for non-inetd use: ftpd_flags="-D"
A line like this shows that ftpd is not starting up with the system. ( At least not via rc(8), read the Anonymous FTP FAQ to read more about this. ) In any case, each line also has a comment showing you the flags for NORMAL usage of that daemon or service. This doesn't mean that you must run that daemon or service with those flags. You can always use man(1) to see how you can have that daemon or service start up in any way you like. For example, Here is the default line pertaining to httpd(8).
httpd_flags=NO # for normal use: "" (or "-DSSL" after reading ssl(8))
Here you can obviously see that starting up httpd normally no flags are necessary. So a line like: " httpd_flags=""" would be necessary. But to start httpd with ssl enabled. (Refer to the SSL FAQ or ssl(8)) You should start with a line like: "httpd_flags="-DSSL"".
For other daemons that you might install with the system via ports or other ways, you will use the /etc/rc.local file. For example, I've installed a daemon in which lie's at /usr/local/sbin/daemonx. I want this to start at boot time. I would put an entry into /etc/rc.local like this:
if [ -x /usr/local/sbin/daemonx ]; then echo -n ' daemonx'; /usr/local/sbin/daemonx fi
From now on, this daemon will be run at boot. You will be able to see any errors on boot, a normal boot with no errors would show a line like this:
Starting local daemons: daemonx.
/etc/rc.shutdown is a script that is run a shutdown. Anything you want done before the system shuts down should be added to this file. If you have apm, you can also set "powerdown=YES". Which will give you the equivlent of "shutdown -p".
10.4 - Why do users get relaying access denied when they are remotely sending mail through my OpenBSD system?
# cat /etc/mail/sendmail.cf | grep relay-domains
The output may look something like this:
If this file doesn't exist, create it. You will need to enter the hosts who are sending mail remotely with the following syntax:
.domain.com #Allow relaying for/to any host in domain.com sub.domain.com #Allow relaying for/to sub.domain.com and any host in that domain 10.2 #Allow relaying from all hosts in the IP net 10.2.*.*
Don't forget send a 'HangUP' signal to sendmail, (a signal which causes most daemons to re-read their configration file):
# kill -HUP `cat /var/run/sendmail.pid`
Most issues dealing with POP are problems with temporary files and lock files. If your pop server sends an error message such as:
-ERR Couldn't open temporary file, do you own it?
Try setting up your permissions as such:
permission in /var drwxrwxr-x 2 bin mail 512 May 26 20:08 mail permissions in /var/mail -rw------- 1 username username 0 May 26 20:08 username
Another thing to check is that the user actually owns their own /var/mail file. Of course this should be the case (as in, /var/mail/joe should be owned by joe) but if it isn't set correctly it could be the problem!
Of course, making /var/mail writeable by group mail opens up some vague and obscure security problems. It is likely that you will never have problems with it. But it could (especially if you are a high profile site, ISP,...)! Try running cucipop or another POP daemon from the OpenBSD ports collection. Or, you could just have the wrong options selected for your pop daemon (like dot locking). Or, you may just need to change the directory that it locks in (although then the locking would only be valueable for the POP daemon.)
PS: Notice, OpenBSD does not have a group name of "mail". You need to create this in your /etc/group file. An entry like:
mail:*:6:would be sufficent.
10.6 - Setting up a Secure HTTP server with SSL(8)
Starting with OpenBSD 2.8, OpenBSD ships with an SSL-ready httpd and RSA libraries. However, if you are using OpenBSD 2.6 or 2.7 you must use provided SSL packages to use SSL. For more information, man 8 ssl.
For use with httpd(8), you must first have a certificate created. This will be kept in /etc/ssl/private/. The steps shown here are taken in part from the ssl(8) man page. Refer to it for further information. This FAQ entry only outlines how to create an RSA certificate for web servers, not a DSA server certificate. To find out how to do so, please refer to the ssl(8) man page.
To start off, you need to create your server key and certificate. To use the RSA features, you must have upgraded your libssl. Now you can create your key. Using OpenSSL:
# openssl genrsa -out /etc/ssl/private/server.key 1024
Or, if you wish the key to be encrypted with a passphrase that you will have to type in when starting servers
# openssl genrsa -des3 -out /etc/ssl/private/server.key 1024
The next step is to generate a Certificate Signing Request which is used to get a Certifying Authority (CA) to sign your certificate. To do this use the command:
# openssl req -new -key /etc/ssl/private/server.key -out /etc/ssl/private/server.csr
This server.csr file can then be given to Certifying Authority who will sign the key. One such CA is Thawte Certification which you can reach at http://www.thawte.com/. Thawte can currently sign RSA keys for you. A procedure is being worked out to allow for DSA keys.
If you cannot afford this, or just want to sign the certificate yourself, you can use the following.
# openssl x509 -req -days 365 -in /etc/ssl/private/server.csr \ -signkey /etc/ssl/private/server.key -out /etc/ssl/server.crt
With /etc/ssl/server.crt and /etc/ssl/private/server.key in place, you should be able to start httpd(8) with the -DSSL flag, enabling https transactions with your machine on port 443.
10.7 - I edited /etc/passwd, but the changes didn't seem to take place. Why?
If you edit /etc/passwd, your changes will be lost. OpenBSD generates /etc/passwd dynamically with pwd_mkdb(8). The main password file in OpenBSD is /etc/master.passwd. According to pwd_mkdb(8),
FILES /etc/master.passwd current password file /etc/passwd a Version 7 format password file /etc/pwd.db insecure password database file /etc/pwd.db.tmp temporary file /etc/spwd.db secure password database file /etc/spwd.db.tmp temporary file
In a traditional Unix password file, such as /etc/passwd, everything including the user's encrypted password is available to anyone on the system (and is a prime target for programs such as Crack.) 4.4BSD introduces the master.passwd file, which has an extended format (with additional options beyond what was provided by /etc/passwd) and is only readable by root. For faster access to data, the library calls which access this data normally read /etc/pwd.db and /etc/spwd.db.
OpenBSD does come with a tool with which you should edit your password file. It is called vipw(8). Vipw will use vi (or your favourite editor defined per $EDITOR) to edit /etc/master.passwd. After you are done editing, it will re-create /etc/passwd, /etc/pwd.db, and /etc/spwd.db as per your changes. Vipw also takes care of locking these files, so that if anyone else attempts to change them at the same time, they will be denied access.
10.8 - What is the best way to add and delete users?
For OpenBSD 2.6 users, the adduser(8) command is available for adding users. In OpenBSD 2.7, the user(8) command was added to deal with adding and removing both users and groups.
The best way to add a user in OpenBSD is to use the adduser(8) script. You can configure this to work however you like by editing /etc/adduser.conf. You can add users by hand via vipw(8), but this is the recommended way to add users. adduser(8) allows for consistency checks on /etc/passwd, /etc/group, and shell databases. It will create the entries and $HOME directories for you. It can even send a message to the user welcoming them. This can be changed to meet your needs. For further instructions on adding users read the adduser_proc(8) man page. Here is an example user, testuser being added to a system. His/Her $HOME directory will be placed in /home/testuser, and given the group guest, and the shell /bin/ksh.
# adduser Use option ``-silent'' if you don't want to see all warnings and questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_]: testuser Enter full name : Test FAQ User Enter shell csh ksh nologin sh [ksh]: ksh Uid : <Enter> Login group testuser [testuser]: guest Login group is ``guest''. Invite testuser into other groups: guest no [no]: no Enter password : Enter password again : Name: testuser Password: **** Fullname: Test FAQ User Uid: 1002 Gid: 31 (guest) Groups: guest HOME: /home/testuser Shell: /bin/ksh OK? (y/n) [y]: y Added user ``testuser'' Copy files from /usr/share/skel to /home/testuser Add another user? (y/n) [y]: n Goodbye!
To delete users you should use the rmuser(8) utility. This will remove all existence of a user. It will remove any crontab(1) entries, their $HOME dir (if it is owned by the user), and their mail. Of course it will also remove their /etc/passwd and /etc/group entries. Next is an example of removing the user that was added above. Notice you are prompted for the name, and whether or not to remove the users home directory.
# rmuser Enter login name for user to remove: testuser Matching password entry: testuser:$2a$07$ZWnBOsbqMJ.ducQBfsTKUe3PL97Ve1AHWJ0A4uLamniLNXLeYrEie:1002:31::0:0:Test FAQ User:/home/testuser:/bin/ksh Is this the entry you wish to remove? y Remove user's home directory (/home/testuser)? y Updating password file, updating databases, done. Updating group file: done. Removing user's home directory (/home/testuser): done.
Starting in the 2.7 release of OpenBSD, many commands were added for dealing with users and groups. These tools are less interactive than the adduser(8) command, which helps facilitate using these in a script.
Being that user(8) is not interactive, the easiest way to add users efficiently is to use the adduser(8) command. The actual command /usr/sbin/user is just a frontend to the rest of the /usr/sbin/user* commands. Therefore, the following commands can be added by using user add or useradd, its your choice as to what you want, and doesn't change the use of the commands at all.
In this example, we are adding the same user with the same specifications as the user that was added above. useradd(8) is much easier to use if you know the default setting before adding a user. These settings are located in /etc/usermgmt.conf and can be viewed by doing so:
$ user add -D group users base_dir /home skel_dir /etc/skel shell /bin/csh inactive 0 expire Null (unset) range 1000..60000
The above settings are what will be set unless you specify different with command line options. For example, in our case, we want the user to go to the group guest, not users. One more little hurdle with adding users, is that passwords must be specified on the commandline. This is, the encrypted passwords, so you must first use the encrypt(1) utility to create the password. For example: OpenBSD's passwords by default use the Blowfish algorigthm for 6 rounds. Here is an example line to create an encrypted password to specify to useradd(8).
$ encrypt -p -b 6 Enter string: $2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq
Now that we have our encrypted password, we are ready to add the user.
# user add -p '$2a$06$YOdOZM3.4m6MObBXjeZtBOWArqC2.uRJZXUkOghbieIvSWXVJRzlq' -u 1002 \ -s /bin/ksh -c "Test FAQ User" -m -g guest testuser
Note: Make sure to use '' around the passord string, not "" as the shell will interpret these before sending it to user(8). In addition to that, make sure you specify the -m option if you want the user's home directory created and the files from /etc/skel copied over.
To see that the user was created correctly, we can use many different utilites. Below are a few commands you can use to quickly check that everything was created correctly.
$ ls -la /home total 14 drwxr-xr-x 5 root wheel 512 May 12 14:29 . drwxr-xr-x 15 root wheel 512 Apr 25 20:52 .. drwxr-xr-x 24 ericj wheel 2560 May 12 13:38 ericj drwxr-xr-x 2 testuser guest 512 May 12 14:28 testuser $ id testuser uid=1002(testuser) gid=31(guest) groups=31(guest) $ finger testuser Login: testuser Name: Test FAQ User Directory: /home/testuser Shell: /bin/ksh Last login Sat Apr 22 16:05 (EDT) on ttyC2 No Mail. No Plan.
In addition to these commands, user(8) provides its own utility to show user characteristics, called userinfo(8).
$ userinfo testuser login testuser passwd * uid 1002 groups guest change Wed Dec 31 19:00:00 1969 class gecos Test FAQ User dir /home/testuser shell /bin/ksh expire Wed Dec 31 19:00:00 1969
To remove users with the user(8) hierarchy of commands, you will use userdel(8). This is a very simple, yet useable command. To remove the user created in the last example, simply:
# userdel -r testuser
Notice the -r option, which must be specified if you want the users home directory to be deleted as well. Alternatively, you can specify -p and not -r and this will lock the user's account, but not remove any information.
10.9 - How do I create an ftp-only account (not anonymous FTP!)?
There are a few ways to do this, but a very common way to do such is to add /usr/bin/false into /etc/shells. Then when you create the user set his shell to /usr/bin/false, they will not be able log in interactively, but will be able to use ftp capabilities. adduser(8) will give them a home dir by default of /home/<user>. If this is what you desire it doesn't need to be changed, however you can set this to whatever directory you wish. You can force this user to only be able to see files in their home directory by adding their username to /etc/ftpchroot. Using the -A option to ftpd(8), you can allow only ftpchroot logins!
10.10 - Setting up Quotas
Quotas are used to limit users space that they have available to them on your drives. It can be very helpful in situations where you have limited resources. Quotas can be set in two different ways.
The first step to setting up quotas is to make sure that option QUOTA is in your Kernel Configuration. This option is in the GENERIC kernel. After this you need to mark in /etc/fstab the filesystems which will have quotas enabled. The keywords userquota and groupquota should be used to mark each fs that you will be using quotas on. By default the files quota.user and quota.group will be created at the root of that filesystem to hold the quota information. This default can be overwritten by doing, userquota=/var/quotas/quota.user. Or whatever file you want to use for holding quota information. Here is an example /etc/fstab that has one filesystem with userquotas enabled.
/dev/wd0a / ffs rw,userquota=/var/quotas/quota.user 1 1
Now it's time to set the user's quotas. To do so you use the utility edquota(8). A simple use is just edquota <user>. edquota(8) will use vi(1) to edit the quotas unless the environmental variable EDITOR is set to a different editor. For example:
# edquota ericj
This will give you output similar to this:
Quotas for user ericj: /: blocks in use: 62, limits (soft = 0, hard = 0) inodes in use: 25, limits (soft = 0, hard = 0)
To add limits, edit it to give results like this:
Quotas for user ericj: /: blocks in use: 62, limits (soft = 1000, hard = 1050) inodes in use: 25, limits (soft = 0, hard = 0)
In this the softlimit is set to 1000 blocks and the hardlimit is set to 1050 blocks. A softlimit is a limit where the user is just warned when they cross it and have until their grace period is up to get their disk usage below their limit. Grace periods can be set by using the -t option on edquota(8). After the grace period is over the softlimit is handled as a hardlimit. This usually results in an allocation failure.
Now that the quotas are set, you need to turn the quotas on. To do this use quotaon(8). For example:
# quotaon -a
This will go through /etc/fstab to turn on the filesystems with quota options. Now that quotas are up and running, you can view them by the quota(1). Using a command of quota <user> will give that users information. When called with no arguments the quota command will give your quota statistics. For example:
# quota ericj
Will result in output similar to this:
Disk quotas for user ericj (uid 1001): Filesystem blocks quota limit grace files quota limit grace / 62 1000 1050 27 0 0
By default quotas set in /etc/fstab will be started on boot. To turn them off use
# quotaoff -a
10.11 - How to Setup Kerberos Clients and Servers under OpenBSD
As a user/administrator of OpenBSD systems, you are fortunate that KerberosIV is an pre-installed component of the default system. Here is a guide to setting up both the Kerberos realm server, as well as a client.
An *EXTREMELY* important point to remember is that Kerberos clients and servers must have their system clocks synchronized. If there is more than a 5 minute time skew, you will receive wierd errors that do not immediately reveal themselves to be caused by time skew, such as:
kinit: Can't send request (send_to_kdc)Another more accurate error is:
kauth: Time is out of bounds (krb_rd_req)
An easy way to synchronize system clocks is with xntpd, available in the ports tree at /usr/ports/sysutils/xntpd/.This FAQ entry assumes you have prior knowledge of the Kerberos concepts. For a great, easy to understand, reference, see:
We will be setting up the CIARASYSTEMS.COM realm, with avalanche.ciarasystems.com as the main server.
To start off, we will need to edit our configuration files. These files are located at /etc/kerberosIV/. The two files we are concerned about are krb.realms and krb.conf. Let's start off with krb.conf.
[root@avalanche kerberosIV] cat krb.conf CIARASYSTEMS.COM CIARASYSTEMS.COM avalanche.ciarasystems.com admin server
As you can see, this tells kerberos that the domain is CIARASYSTEMS.COM (or logical realm) and that within that domain, avalanche is the administration server. Next we will look at krb.realms. For more information on this refer to krb.conf.
[root@avalanche kerberosIV] cat krb.realms avalanche.ciarasystems.com CIARASYSTEMS.COM .ciarasystems.com CIARASYSTEMS.COM
krb.realms provides a translation from a hostname to the Kerberos realm name for the services provided by that host. Each line of the translation file is in one of the following forms (domain_name should be of the form .XXX.YYY). So in this example, avalanche is the hostname of a computer on the CIARASYSTEMS.COM realm. And .ciarasystems.com is the domain name on the realm CIARASYSTEMS.COM. Again, for further information read the krb.realms. man page.
Next we will run kdb_init(8) to create the initial Kerberos database.
[root@avalanche kerberosIV] kdb_init Realm name [default NO.DEFAULT.REALM ]: CIARASYSTEMS.COM You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master password: not shown Verifying password - Enter Kerberos master password:
Next we need to use kstash(8) which is used to save the Kerberos key distribution center (KDC) database master key in the master key cache file.
[root@avalanche kerberosIV] kstash Enter Kerberos master password: Current Kerberos master key version is 1. Master key entered. BEWARE! Wrote master key to /etc/kerberosIV/master_keyThis saves the encrypted master password in /etc/kerberosIV/master_key.
Next, we need two principals to be added to the database for each system that will be secured with Kerberos. Their names are kpasswd and rcmd. These two principals are made for each system, with the instance being the name of the individual system. These daemons, kpasswd and rcmd allow other systems to change Kerberospasswords and run commands like rcp, rlogin and rsh.
# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: passwd Instance: avalanche <Not found>, Create [y] ? y Principal: passwd, Instance: avalanche, kdc_key_ver: 1 New Password: <----- Use 'RANDOM' as password Verifying password - New Password: Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? 2001-12-31 Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd Instance: avalanche <Not found>, Create [y] ? y Principal: rcmd, Instance: avalanche, kdc_key_ver: 1 New Password: <----- Use 'RANDOM' as password Verifying password - New Password: Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 1999-12-31 ] ? 2001-12-31 Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <----- Hit <ENTER> to end
A srvtab file is the service key file. These must be extracted from the Kerberos key distribution center database in order for services to authenticate using Kerberos. For each hostname specified on the command line, ext_srvtab(8) creates the service key file hostname-new-srvtab, containing all the entries in the database with an instance field of hostname.
[root@avalanche kerberosIV] ext_srvtab avalanche Enter Kerberos master password: Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'avalanche-new-srvtab'.... [root@avalanche kerberosIV] mv avalanche-new-srvtab srvtab [root@avalanche kerberosIV] chmod 600 srvtab
Now we can add users to our database.
[root@avalanche kerberosIV] kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. Principal name: jeremie Instance: <Not found>, Create [y] ? y Principal: jeremie, Instance: , kdc_key_ver: 1 New Password: <---- enter a secure password here Verifying password New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: <---- null entry here will cause an exit or you can add more entries.
So now all the Kerberos particulars are setup. All that is left is to enable boot-time loading of the Kerberos server and to enable Kerberized-daemons.
In /etc/rc.conf, set:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -k klogin stream tcp nowait root /usr/libexec/rlogind rlogind -k kshell stream tcp nowait root /usr/libexec/rshd rshd -k kauth stream tcp nowait root /usr/libexec/kauthd kauthdThen, either reboot, or:
[root@avalanche /] kill -HUP `cat /var/run/inetd.pid` [root@avalanche /] /usr/libexec/kerberos >> /var/log/kerberos.log & [root@avalanche /] /usr/libexec/kadmind -n >> /var/log/kadmind.log &
Note: this is a rather simple server setup. Usually, redundant servers are setup (as slave servers) so that if one server goes down, all the services that depend on Kerberos don't go down. We can also add 'su' privileges to a specific principal, see the FreeBSD Handbook.
We will be setting the workstation named gatekeeper to be in the CIARASYSTEMS.COM realm, with avalanche.ciarasystems.com as the main server.
To start off, we need to setup our krb.conf and krb.realms like the above machine. This is so gatekeeper will know what server is the KDC and what domain it is on. Again here are the file contents.
[root@gatekeeper kerberosIV] cat krb.conf CIARASYSTEMS.COM CIARASYSTEMS.COM avalanche.ciarasystems.com admin server [root@gatekeeper kerberosIV] cat krb.realms avalanche.ciarasystems.com CIARASYSTEMS.COM .ciarasystems.com CIARASYSTEMS.COM
Now that is set up, we need to initialize kerberos. To obtain a ticket you use kinit(1).
xyz:jeremie% kinit The OpenBSD Project (gatekeeper) Kerberos Initialization Kerberos name: jeremie Password:
Now we have identified we can list our tickets with klist(1).
xyz:jeremie$ klist Ticket file: /tmp/tkt1000 Principal: jeremie@CIARASYSTEMS.COM Issued Expires Principal Jun 28 01:03:25 Jun 28 11:03:25 krbtgt.CIARASYSTEMS.COM@CIARASYSTEMS.COM
Looks like we are set now. All that's left to do is test it. Here we will test it with rlogin(1) and telnet(1).
xyz:jeremie% telnet avalanche Trying 192.168.0.38... Connected to avalanche. Escape character is '^]'. [ Trying mutual KERBEROS4 ... ] [ Kerberos V4 accepts you ] [ Kerberos V4 challenge successful ] Last login: Sun Jun 27 22:52:25 on ttyp1 from gatekeeper Warning: no Kerberos tickets issued. OpenBSD 2.5 (AVALANCHE) #5: Tue Apr 6 01:18:16 EDT 1999and
xyz:jeremie% rlogin avalanche Last login: Sun Jun 27 22:53:39 on ttyp1 from gatekeeper Warning: no Kerberos tickets issued. OpenBSD 2.5 (AVALANCHE) #5: Tue Apr 6 01:18:16 EDT 1999
We can tell that it is indeed using Kerberos to authenticate the rlogin session. To get rid of any tickets issued, you would use kdestroy(1). For example:
xyz:jeremie% kdestroy Tickets destroyed. xyz:jeremie% rlogin avalanche krcmd: No ticket file (tf_util) rlogin: warning, using standard rlogin: can't provide Kerberos auth data. avalanche: Connection refused
Do not worry about 'Warning: no Kerberos tickets issued.' This is because we're only doing kerberos authentication, not ticket passing. If you want ticket passing, use OpenSSH which has support. Stock KerberosIV doesn't have support for tgt passing, either - only the AFS kaserver's implementation of krb4, since the regular KerberosIV kdc checks client IP address listed in the ticket.
10.12 - Setting up Anonymous FTP Services.
Anonymous FTP allows users without accounts to access files on your computer via the File Transfer Protocol. This will give an overview of setting up the anonymous FTP server, and its logging, etc.
To start off, you need to have an account on your system of "ftp". This account shouldn't have a useable password. Here we will set the login directory to /home/ftp, but you can put it wherever you want. When using anonymous ftp, the ftp daemon will chroot itself to the home directory of the 'ftp' user. To read up more on that, read the ftp(8) and chroot(2) man pages. Here is an example of adding the ftp user. I will do this using adduser(8). We also need to add /usr/bin/false to our /etc/shells, this is the "shell" that we will be giving to the ftp user. This won't allow them to login, even though we will give them an empty password. To do this you can simply echo /usr/bin/false >> /etc/shells. Also if you wish for that shell to show up during the adduser questions, you need to modify /etc/adduser.conf.
oshibana# adduser Use option ``-silent'' if you don't want see all warnings & questions. Reading /etc/shells Check /etc/master.passwd Check /etc/group Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_]: ftp Enter full name : anonymous ftp Enter shell csh false ksh nologin sh tcsh zsh [sh]: false Uid : Login group ftp [ftp]: Login group is ``ftp''. Invite ftp into other groups: guest no [no]: no Enter password : Use an empty password? (y/n) [y]: y Name: ftp Password: **** Fullname: anonymous ftp Uid: 1002 Gid: 1002 (ftp) Groups: ftp HOME: /home/ftp Shell: /usr/bin/false OK? (y/n) [y]: y Added user ``ftp'' Copy files from /usr/share/skel to /home/ftp Add another user? (y/n) [y]: n Goodbye!
Along with the user, this created the directory /home/ftp. This is what we want, but there are some changes that we will have to make to get it ready for anonymous ftp. Again these changes are explained in the ftp(8) man page.
Note that all these directories should be owned by ''root''. Here is a listing of what the directories should look like after their creation.
oshibana# pwd /home oshibana# ls -laR ftp total 5 dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 . drwxr-xr-x 7 root wheel 512 Jul 6 10:58 .. dr-x--x--x 2 root ftp 512 Jul 6 11:34 etc dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 pub ftp/etc: total 43 dr-x--x--x 2 root ftp 512 Jul 6 11:34 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 .. -r--r--r-- 1 root ftp 316 Jul 6 11:34 group -r--r--r-- 1 root ftp 40960 Jul 6 11:34 pwd.db ftp/pub: total 2 dr-xr-xr-x 2 root ftp 512 Jul 6 11:33 . dr-xr-xr-x 5 root ftp 512 Jul 6 11:33 ..
With ftpd you can choose to either run it from inetd or the rc scripts can kick it off. These examples will show our daemon being started from inetd.conf. First we must become familiar with some of the options to ftpd. The default line from /etc/inetd.conf is:
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -US
Here ftpd is invoked with -US. This will log anonymous connections to /var/log/ftpd and concurrent sessions to /var/run/utmp. That will allow for these sessions to be seen via who(1). For some, you might want to run only an anonymous server, and disallow ftp for users. To do so you should invoke ftpd with the -A option. Here is a line that starts ftpd up for anonymous connections only. It also uses -ll which logs each connection to syslog, along with the get, retrieve, etc, ftp commands.
ftp stream tcp nowait root /usr/libexec/tcpd ftpd -llUSA
Note - For people using HIGH traffic ftp servers, you might want to not invoke ftpd from inetd.conf. The best option is to comment the ftpd line from inetd.conf and start ftpd from rc.conf along with the -D option. This will start ftpd as a daemon, and has much less overhead as starting it from inetd. Here is an example line to start it from rc.conf.
ftpd_flags="-DllUSA" # for non-inetd use: ftpd_flags="-D"
This of course only works if you have ftpd taken out of /etc/inetd.conf.
OpenBSD's ftpd(8) is setup by default to be able to handle this very easily. This is accomplished via the file /etc/ftpchroot. Since users cannot always be trusted, it might be necessary to restrain them to their home directories. This behavior is NOT on by default. Here is an example of what the default behavior is like.
$ ftp localhost Connected to localhost. 220 oshibana FTP server (Version 6.4/OpenBSD) ready. Name (localhost:ericj): ericj 331 Password required for ericj. Password: ********* 230- OpenBSD 2.6 (GENERIC) #690: Fri Oct 29 16:32:17 MDT 1999 230- 230- Welcome to OpenBSD: The proactively secure Unix-like operating system. 230- 230- Please use the sendbug(1) utility to report bugs in the system. 230- Before reporting a bug, please try to reproduce it with the latest 230- version of the code. With bug reports, please try to ensure that 230- enough information to reproduce the problem is enclosed, and if a 230- known fix for it exists, include that as well. 230- 230 User ericj logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd / 250 CWD command successful. ftp> ls 227 Entering Passive Mode (127,0,0,1,60,7) 150 Opening ASCII mode data connection for 'file list'. altroot bin dev etc home mnt root sbin stand tmp usr var bsd sys boot 226 Transfer complete. ftp> quit 221 Goodbye.
As you can see here, access is granted to the whole server. In a perfect world this is ok, where all users can be trusted, but this isn't so. To limit a user, simply add their name to the file /etc/ftpchroot. Here is an example showing user "ericj" being restricted.
$ cat /etc/ftpchroot # $OpenBSD: faq10.html,v 1.51 2001/01/27 22:19:47 ericj Exp $ # # list of users (one per line) given ftp access to a chrooted area. # read by ftpd(8). ericj
This is enough to keep the user "ericj" from escaping from his own directory. As you can see in the next example. The / directory has suddenly changed to his home dir!
$ ftp localhost Connected to localhost. 220 oshibana FTP server (Version 6.4/OpenBSD) ready. Name (localhost:ericj): ericj 331 Password required for ericj. Password: ********* 230 User ericj logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd / 250 CWD command successful. ftp> ls 227 Entering Passive Mode (127,0,0,1,92,171) 150 Opening ASCII mode data connection for 'file list'. .login .mailrc .profile .rhosts .ssh .cshrc work mail src 226 Transfer complete. ftp> quit 221 Goodbye.
The OpenBSD source tree is constantly changing and improving, along with this fixes to common problems are often made and patches released to the public. These patches appear on the errata web page located at http://www.openbsd.org/errata.html, and are separated into categories. These categories correspond to patches that should be applied to different architectures or architecture independent patches.
Note, however, that patches aren't made for new additions to OpenBSD, and are only done for important reliability fixes or security problems that should be addressed right away, although the choice to do so is, as always, up to the administrator.
For the examples I will be patching talkd(8) with a security fix from the patch obtained from errata.html.
All patches posted at http://www.openbsd.org/errata.html are patches directly against the latest releases source tree. Patches against the latest CVS tree might also include other changes that wouldn't be wanted on a release system.
Patches for the OpenBSD Operating System are distributed as diff's, which are text files that hold differences to the original source code. They are NOT distributed in binary form. This means that to patch your system you must have the source code from the RELEASE version of OpenBSD readily available. This does not mean that you must have ALL source code to the OpenBSD operating system to patch your system, but must have all code for the program which you are patching. For instance, if you are patching the kernel you must have all source for the kernel on hand.
cvs(1) is a very handy tool that can be used to grab only the source that you need via any of the anonymous cvs servers located around the world. You can get a listing of these servers at http://www.openbsd.org/anoncvs.html.
To retrieve the current releases source code using cvs(1), you would use the following line:
$ cvs -firstname.lastname@example.org:/cvs co -rOPENBSD_2_7_BASE src/libexec/talkd/ cvs server: Updating src/libexec/talkd U src/libexec/talkd/announce.c U src/libexec/talkd/talkd.c U src/libexec/talkd/talkd.h
To find the CVS path to the code that you need, you can find this in the patch on the Index: line. In this case, the CVS path was src/libexec/talkd/. Always check out the revision of OPENBSD_version_number_BASE. Without "BASE" you will be checking out the stable branch, which might contain other changes that will interfere. If you are already tracking the patch branch, the patches should already be in that source, however you should always check and make sure. You can always look at http://www.openbsd.org/plus.html to see which patches have been applied to the patch branch. If the patches haven't been applied yet, you will need to grab the latest release source using the commands above.
Also, for those users that bought official OpenBSD CD's, you can get the source code directly off of the CD. Refer to the CD insert on how to extract the source from the CD. In which case you won't need to obtain the source via anoncvs.
Apply by doing: cd /usr/src patch -p0 < 026_talkd.patch cd libexec/talkd make obj && make depend && make && make install Index: libexec/talkd/announce.c <------ Path to sources =================================================================== RCS file: /cvs/src/libexec/talkd/announce.c,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- libexec/talkd/announce.c 1998/08/18 03:42:10 1.8 +++ libexec/talkd/announce.c 2000/07/06 00:01:45 1.9 @@ -160,6 +160,6 @@ *(bptr++) = '\n'; } *bptr = '\0'; - fprintf(tf, big_buf); + fprintf(tf, "%s", big_buf); fflush(tf); }
Once you've obtained the proper sources, you can obtain the patch and place it in src/
$ cd /usr/src $ patch -p0</path/to/026_talkd.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Apply by doing: | cd /usr/src | patch -p0 < 026_talkd.patch | cd libexec/talkd | make obj && make depend && make && make install | |Index: libexec/talkd/announce.c |=================================================================== |RCS file: /cvs/src/libexec/talkd/announce.c,v |retrieving revision 1.8 |retrieving revision 1.9 |diff -u -r1.8 -r1.9 |--- libexec/talkd/announce.c 1998/08/18 03:42:10 1.8 |+++ libexec/talkd/announce.c 2000/07/06 00:01:45 1.9 -------------------------- Patching file libexec/talkd/announce.c using Plan A... Hunk #1 succeeded at 160. <------------ Patch Succeeded done $ cd /usr/src/libexec/talkd/ $ ls CVS announce.c print.c table.c talkd.c Makefile announce.c.orig process.c talkd.8 talkd.h $ make obj && make depend && make making /home/ericj/lsrc/src/libexec/talkd/obj mkdep -a /home/ericj/lsrc/src/libexec/talkd/talkd.c /home/ericj/lsrc/src/libexec/talkd/announce.c /home/ericj/lsrc/src/libexec/talkd/process.c /home/ericj/lsrc/src/libexec/talkd/table.c /home/ericj/lsrc/src/libexec/talkd/print.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/talkd.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/announce.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/process.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/table.c cc -O2 -c /home/ericj/lsrc/src/libexec/talkd/print.c cc -o ntalkd talkd.o announce.o process.o table.o print.o nroff -Tascii -mandoc /home/ericj/lsrc/src/libexec/talkd/talkd.8 > talkd.cat8 $ sudo make install install -c -s -o root -g bin -m 555 ntalkd /usr/libexec install -c -o root -g bin -m 444 talkd.cat8 /usr/share/man/cat8/talkd.0 /usr/share/man/cat8/ntalkd.0 -> /usr/share/man/cat8/talkd.0
Once you have done that, you should restart that service.
[Back to Main Index] [To Section 9.0 - Migrating from Linux] [To Section 11.0 - Performance Tuning]