Kerberos for users

Last updated -[Sun Oct 9 10:12:27 2005 by cxh]-

Places to go

  • Departmental Kerberos page for users user documentation at /usr/sww/share/doc/security/KERBEROS/quick-start
  • MIT
  • My Toplevel Kerberos Page
  • Secure Shell (ssh)

    • Contents

  • Kerberos Introduction
  • Setting up kerberos on Unix machines, where you don't have root or sww
  • Setting up kerberos under Unix, where you have root, but no sww
  • Setting up kerberos on a Mac
  • Setting up kerberos under Windows
  • Local Kerberos FAQ

    • Kerberos Introduction

    Kerberos is an authentication scheme that helps avoid snooping problems. See the Departmental Kerberos page for users for instructions on how to use kerberos. This page is a supplement to the sww instructions, not a replacement.

    You can register yourself from argon.EECS, conviction.CS, mho.EECS diva.EECS, fred.EECS, hera.EECS, karenin.EECS, perth.CS, po.EECS, radon.EECS, toe.CS, or vangogh.CS with the /usr/kerberos/bin/register program. Note that there might be a delay of one hour before your ticket is propagated around correctly.

    The binary to run is /usr/kerberos/bin/register

    You can try using /usr/kerberos/bin/kinit to initialize a ticket on your local machine. Don't run kinit over the net, you should run it before you start X in the morning, or in your console window.

    To use kerberos rlogin and other binaries, place /usr/kerberos/bin in your path. Note that Solaris machines have kerberos too, so /usr/kerberos/bin should be before /usr/bin in your path. Some solaris users have reported that to see the Kerberos man pages, they have to use man -k, which forces the man command to use the MANPATH environment variable

    Why use kerberos?

  • kerberos protects you against typing your password in plain text over the net
  • kerberos makes .rhosts files obsolete. .rhosts files are a very serious security hole.
  • If someone does get your ticket file, the ticket expires in 9 hours so they can't use your ticket for ever.

    • Kerberos Problems

  • Your ticket is not propagated from machine to machine, so you have to use rkinit to pass your ticket to a new machine. In otherwords you can't log from A to B to C, unless B has your ticket.
  • If you are running a screen based application, such as emacs, then you should start up rlogin in 8 bit mode instead of the default 7 bits. The way to do this is to do rlogin -8 hostname.
  • If you want to encrypt your session, use the -x option: rlogin -x. You can combine options with: rlogin -8x hostname.
  • If the Unix clock is more than 5 minutes different, kerberos won't work.
  • The annexes don't understand kerberos, so you still need to type your kerberos password in over the net if you log in via an annex. If you are running PPP from home, then you can install a kerberized telnet and use that.
    Xylogics, the makers of the annexes, say that there is not enough demand for kerberos for the annexes,see http://www.xylogics.com/prod/white/pages/kerberos.htm
  • If, under Solaris, when you do kinit, you see: cxh@watson 89% kinit SunOS (watson.eecs.berkeley.edu) Kerberos Initialization Kerberos name: Then you don't have your path properly configured. You should see: cxh@watson 90% kinit WARNING: Your password may be exposed if you enter it here and are logged in remotely using an unsecure (non-encrypted) channel. Kerberos Password:

    • Setting up kerberos on Unix machines, where you don't have root or sww

    These instructions are for users who are running Unix at a remote site, and don't have access to sww and do not have root access to their remote machine.
  • If you have access to sww, see the Kerberos sysadmin instructions.
  • If you have root access to your machine, see Setting up kerberos under Unix, where you have root, but no sww, below.

    • The idea here is that you download a rlogin binary to your remote machine do a little configuration and then use the rlogin binary to connect to a kerberos only machine. The rlogin binary should prompt you for a kerberos password before connecting to a kerberos machine.

    If you are in the UCB eecs department, see the Kerberos distribution page for tar files for certain architectures. To use these binaries, do the following

    1. Ftp the appropriate binary to your remote site. The binaries are not available via anonymous ftp, so there is a bit of a chicken and egg problem. If you have an account on the Mho cluster, but can't log in because you don't have kerberos setup locally then send mail to me (cxh).
    2. The binary must be renamed to rlogin, or you will get a usage message: visigoth.EECS.Berkeley.EDU 32# ./rlogin.sol2 usage: rlogin host [-option] [-option...] [-k realm ] [-t ttytype] [-l username] where option is e, 7, 8, noflow, n, a, x, or c You should also make it executable: mv sparc-sun-sunos4.1.3-cygin rlogin chmod a+x rlogin
    3. Because of a minor bug in the binaries, you will need to copy /etc/krb.conf to /tmp/kerberos.lib.krb.conf on your local machine. You can change this path by editing the binary with emacs, but the new path must have the same length as the old path.
    4. Note that you can use the -x option to encrypt your session: rlogin -8x watson.eecs.berkeley.edu

    Setting up kerberos under Unix, where you have root, but no sww

    Here's what I had to do to set up kerberos on a SunOS machine at home, where I had root access.
    1. Copy /usr/sww/kerberosIV/bin to the remote HIP machine. On a campus machine of the right architecture I did:cd /usr/sww/kerberosIV/bin; /usr/sww/bin/gtar -zcf /tmp/sww.krb.bin.sol2.tar.gz . Use rcp or ftp to transfer the file to the remote HIP machine.
      If you are in the UCB eecs department, see the Kerberos distribution page for tar files for certain architectures, along with a copy of kerberize, which you will also need.
    2. Then on the remote machine, as root I did mkdir -p /usr/sww/kerberosIV/bin cd /usr/sww/kerberosIV/bin; set path = ($path /usr/sww/bin) /usr/sww/bin/gtar -zxf /tmp/sww.krb.bin.sol2.tar.gz
    3. Copy /usr/sww/etc/kerberize to the remote HIP machine.

      You may see a message about broken pipe at the end of the kerberize script, which you can ignore.

    4. kerberize needs /usr/sww/bin/perl5. On the campus machine, you may want to do cp /usr/sww/bin/perl5 /tmp; gzip /tmp/perl5 and then copy over the compressed binary to /usr/sww/bin/perl5
    5. On the remote HIP machine, as root, run /usr/sww/etc/kerberize. You will be prompted for the /etc/krb.srvtab file, which is used only if you want to allow kerberized logins into your machine. If your machine is in the eecs subdomain, then you can follow the instructions in the /usr/sww/share/doc/security/kerberos/quick-start Otherwise, you can just proceed.
    6. Place /usr/sww/kerberosIV/bin in your path. You should then be able to run kinit

    Setting up kerberos on a Mac

    If you are in the UCB eecs department, see the Kerberos distribution page for a Macintosh Self Extracting archive containing a kerberized version of NCSA telnet The same version is available on cory and po in /usr/sww/share/src/mac/CS_Kerberos_Telnet.sea.hqx.

    Mac Kerberos Problems

  • If you have problems extracting the distribution with stuffit, if you ftp the file, make sure that you downloaded the file with binary mode turned on.
  • If you have problems with installing kerberos, try removing the kerberos preferences file and reinstalling it. You might also try removing the NCSA telnet preferences file.
  • Tom Parks repors that Kerberized NCSA Telnet does not support long kerberized passwords. 8 or 9 characters is probably the limit.

    • Setting up kerberos under Windows

    If you are in the UCB eecs department, see the Kerberos distribution page for a Windows zip file containing kerberos distribution

    The cns and telnet binary seem to work ok with NT.

    Under NT, Kerberos for windows uses two files C:\WINNT\krb.con and C:\\WINNT\krb.rea. These correspond to the Unix files /etc/krb.conf and /etc/krb.realms, except they have only three letters in their prefix. The two links below are copies of /etc/krb.conf and /etc/krb.realms, which you can download to your NT box.

  • krb.con
  • krb.rea
    • Under Windows3.1, Mike Williamson said that putting these files in c:\windows worked for him.

    To get a ticket, run the CNS binary, and type in your kerberos Id, which should be the same as your login, and the realm, which should be EECS.BERKELEY.EDU. The Instance field should be left blank. Then hit the Login button, and after a few seconds, you should get a ticket.

    To login, start up the cns telnet binary, and type in a hostname. It seems that the cns telnet binary may fail to connect to Solaris machines that are not set up for kerberos only logins. As of 12/2/96, I was able to log into brahe.eecs.berkeley.edu and diva.eecs.berkeley.edu.

    If you resize the telnet window by grabbing the lower left corner, then the next time you restart cns telnet, the window should come up in the new size. When you telnet into solaris, you may need to type reset so that the solaris side gets the window dimensions

    CNS Telnet troubleshooting

  • Make sure that you have installed krb.con and krb.rea. Under NT, these files should be in C:\WINNT.
  • In the CNS binary, make sure that the path to the conf and realm files are right by checking under the 'File' 'options' choice.
  • If you get messages about Can't send request (send_to_kdc), then check that you can ping kerberos1.CS.Berkeley.EDU. Also, be sure that DNS name resolution is working properly.

    send_to_kdc is in: /usr/tools/cns/cns-96q1/usr/kerberos/src/src/lib/krb/send_to_kdc.c 

    
/*
 * send_to_kdc() sends a message to the Kerberos authentication
 * server(s) in the given realm and returns the reply message.
 * The "pkt" argument points to the message to be sent to Kerberos;
 * the "rpkt" argument will be filled in with Kerberos' reply.
 * The "realm" argument indicates the realm of the Kerberos server(s)
 * to transact with.  If the realm is null, the local realm is used.
 *
 * If more than one Kerberos server is known for a given realm,
 * different servers will be queried until one of them replies.
 * Several attempts (retries) are made for each server before
 * giving up entirely.
 *
 * The following results can be returned:
 *
 * KSUCCESS	- an answer was received from a Kerberos host
 *
 * SKDC_CANT    - can't get local realm
 *              - can't find "kerberos" in /etc/services database
 *              - can't open socket
 *              - can't bind socket
 *              - all ports in use
 *              - couldn't find any Kerberos host
 *
 * SKDC_RETRY   - couldn't get an answer from any Kerberos server,
 *		  after several retries
 */
    Mike Williamson had a similar problem under Windows3.1, and to solve the problem, he ended up removing c:\windows\kerberos.ini and restarting cns. He suspects that the problem was in setting the cns options for krb.rea and krb.con. It might be best to not change these defaults.

    • CNS Telnet Windows bugs

  • There is no encrypted mode
  • There is no way to propagate a ticket to remote machines using rkinit
  • The cns telnet binary does not work perfectly with emacs. If you insert characters into the middle of a line, then you have to redraw the screen with Control-L
  • Under windows95 and NT4.0, the arrow keys move the screen up and down, they don't behave as the should in the app.

    • Local Kerberos FAQ

    Below are some frequently asked questions about the local Kerberos installation. The Top Level Kerberos page has links to faqs about Kerberos in general. If you are having problems with a particular platform, look at the appropriate section above.
    Why are we doing this?
    Basically for security reasons. It is very easy to sniff the net and get passwords. Winter break is the time when most breakins occur. Staff is frequently on vacation, and crackers get new toys for xmas, and have plenty of time on their hands.
    I log in from offsite, and kerberos makes is difficult.
    Sorry. The machines on campus are primarily for people on campus. Unfortunately, remote users take the brunt of the burden of switching over to kerberos. I'm willing to work with remote users, but there is only so much I can do, so I'm expecting remote users to help out a little.
    How can I set my kerberos password if I am never on campus?
    The easiest way to do this is to register for a kerberos password and start up an encrypted rlogin session and change your password with kpasswd.
    Be sure to use /usr/sww/krb5/bin/kpasswd instead of /usr/kerberos/bin/kpasswd or /usr/sww/kerberosIV/bin/kpasswd. To start an encrypted session:
  • Unix: Use rlogin -x
  • Mac: In the 'Session' window under the 'File' menu, if you click on Authenticate, then you can click on Encrypt. Then your session will be encrypted.
  • Windows: The CNS Telnet binary does not support encryption, so you would have to find a Mac or Unix box to start an encrypted session.
    • See the Departmental Kerberos page for users for information about kpasswd.
    I'm having problems with XXX.
    Make sure that /usr/kerberos/bin is in your path first. Carefully read this page and the Departmental Kerberos page for users
    I lost my password.
    Check out the instructions in the Departmental Kerberos page for users
    When I try to register, I get 
    	kerberos1.CS.Berkeley.EDU: Principal not unique
    Instead of getting the confirmation message 
    	kerberos1.CS.Berkeley.EDU: Update complete
    The most likely cause is that you have already registered once. If you forgot your password, see the question above.
    One way to tell if you have registered before is to try the kinit command with your uid: 
    	cxh@kahn 5% kinit  cxh
	Kerberos Initialization for "cxh"
	WARNING: Your password may be exposed if you enter it here and are logged 
	         in remotely using an unsecure (non-encrypted) channel.
	Kerberos Password:
	kinit: Password incorrect
    Here is an example of running kinit on a uid that is not yet registered into the Kerberos system: 
    	cxh@kahn 6% kinit notregistered
	Kerberos Initialization for "notregistered"
	WARNING: Your password may be exposed if you enter it here and are logged 
	         in remotely using an unsecure (non-encrypted) channel.
	kinit: Principal unknown
    Why aren't we using XXX instead of this nasty Kerberos system?
    Kerberos is what the department has embraced, I'm sure that there are other systems out there. However, I personally don't have the time to research other systems. For a replacement to kerberos to be considered it should have the following features
  • Binaries for Macintosh, Windows3.1, Windows95, WindowsNT(3.51 and 4.0), Solaris, SunOS, HPUX, DEC OSF/1, SGI Irix
  • Encryption
  • Source code would be nice.
  • The ability to handle a few thousand users.
    • What about pop and ftp?
    The non-kerberized versions of pop and ftpwill continue to work until we get working kerberized versions installed, and we get kerberized pop and ftp clients that work under Unix, Mac and Windows.
    We have not yet been able to get a kerberized popd to run, see the kerberos administrators guide for more information. We have a ftpd daemon working, though it is a little buggy, see the kerberos administrators guide.
    Well, doesn't having non-kerberized popd and ftpd defeat the purpose of kerberizing telnetd and rlogind?
    Yes, having non-kerberized popd and ftpd definitely undermine kerberos.
    Also, having the rest of the department making kerberos mandatory is also a big lose.
    However, most users do not use pop, and only a few ftps by cluster users occur every day. However, there are many logins from outside the cluster everyday.
    You can always grab files without typing your password by telnetting in with kerberos, placing files in your public_html directory and grabbing them via netscape. If you are really paranoid, you can create a ~/public_html/uploads directory and put a .htaccess file in that directory that only allows access from your own list of machines
    To place files on the mho cluster, you must use ftp. In theory, we could set up an anonymous ftp server on another machine that would allow people to place files in an uploads directory.
    I've tried to setup kerberos, but I'm behind a firewall.
    As of 12/11/96, I don't know of anyone who has used the above binaries from behind a firewall. If you get kerberos working from behind a firewall, let me know.
    I'm not a big firewall expert, but my guess is that the firewall is filtering out the kerberos traffic because it is not on a port that is allowed to pass through.
    You might ask your local network guru if they have ever successfully used kerberos from behind the firewall.
    Perhaps if you ask real nicely, they might allow the firewall to be modified so that you can log in to remote machines with out typing in your password over the net in clear text, or having a ~/.rhosts file.
    What is krb.srvtab?
    This file is only needed if you want to allow kerberized logins into your machine. krb.srvtab is different for each machine. Kerberos uses krb.srvtab to to verify that each machine is really the machine it says it is.

    If your machine name ends in cs.berkeley.edu or .eecs.berkeley.edu, then you can request a krb.srvtab file, see Sww user documentation at /usr/sww/share/doc/security/kerberos/quick-start (Dead link)

    cxh at eecs