|
||||||
|
||||||
|
User Information Home
 NCSA's Help Desk is available 24 hours a day, seven days a week, 365 days a year: Introduction to UNIX Kerberos Clients
Table of Contents
General Information about Kerberos clientsAt NCSA the binaries for Kerberos 5 clients (telnet, rlogin, ftp, rcp, and rsh among others) are installed in /usr/local/krb5/bin. These binaries are restricted by US export control laws and so users should be aware of this if they copy them from this location. See the notes on Kerberos and export control for details. These clients will all work connecting to non-kerberos as well as kerberos servers, so you can safely put this directory near the front of your path. Note that some operating systems (Solaris, at least) come with Kerberos 4 clients that have the same names as the kerberos 5 clients. You need to check and be sure you are running the clients out of /usr/local/krb5 or you will run into problems. For systems that do not have Kerberos installed in /usr/local/krb5, your path will need to be adjusted accordingly. Getting started: kinitThe first thing you need to do is get a Kerberos ticket. You will do this with the kinit program. When you run kinit you will be prompted for your Kerberos password, which you may also know as your AFS password. Your Kerberos ticket is an encrypted piece of data that is used to authenticate you to other hosts and services over the network. It allows you to login to other hosts without having to type your password again. It serves as your authentication. Using it you can log into any number of hosts as many times as you like and you will never be prompted for a password. On NCSA systems that are running AFS you will also notice that whenever you use kinit to get a Keberos ticket, you will also get an AFS token as well. So if you are used to the klog command, you can now use kinit instead. Ticket expirationWhat's this about my Kerberos ticket expiring?All Kerberos tickets have a built in expiration time after which they are no longer valid. This is to help prevent a ticket from being used by someone it's not intended to. It does this in two ways. First if a ticket inadvertantly gets left somewhere it will expire on it's own, reducing the chances of someone coming along and finding a good ticket. Second, if someone does manage to get ahold of a good ticket, it's only good for so long before it becomes worthless to them. At NCSA all tickets expire after 25 hours. If you try to use an expired ticket you'll get errors of the sort "ticket has expired". What this means is that you'll have to run kinit again at which point you'll be good for another day. Most users get in the habit of just running kinit each morning when they come in or using the Kerberos modified xlock program which will get a ticket for them when they unlock their X display. How can I check my Kerberos ticket?The klist program shows your Kerberos ticket and when it expires. For example: (computer) /tmp>klist Ticket cache: /tmp/krb5cc_tty1 Default principal: vwelch@NCSA.EDU Valid starting Expires Service principal 24 Mar 98 14:22:50 25 Mar 98 15:22:40 krbtgt/NCSA.EDU@NCSA.EDU 24 Mar 98 14:22:51 25 Mar 98 15:22:40 afs/ncsa.uiuc.edu@NCSA.EDU 24 Mar 98 14:44:45 25 Mar 98 15:22:40 host/pecos.ncsa.uiuc.edu@NCSA.EDU The above output shows us a number of things. The first line tells us that my Kerberos tickets are being kept in the ticket cache file /tmp/krb5cc_tty1. In general you don't care about where your tickets are being kept. The second line tells us that the tickets are for the user vwelch@NCSA.EDU. NCSA.EDU is NCSA's domain, and vwelch is my user name in that domain. The rest of the lines show the tickets that I have in my cache. The first one is the krbtgt or Kerberos ticket-granting-ticket (or tgt), this is the one that we really care about and is what constitutes what we generally refer to as the Kerberos ticket. This line tells me three things, first that I have a valid ticket-granting-ticket. Second that it is valid starting at 2:22pm on March 24th. The time listed under "Expires" is the one you really care about. This is telling me that at 3:22pm on March 25th, my ticket will expire and I will have to run kinit and get a new one. Underneath my ticket-granting-ticket you notice there are two other tickets. These are called service tickets and you normally don't have to worry about them. Whenever you authenticate yourself to something using Kerberos you actually use your ticket-granting-ticket to get a service ticket, and then the service ticket is used to authenticate you. This all happens automatically and you never notice it except when you look at your tickets. In this case I have two services tickets, the first is for afs and kinit got this for me when it got an AFS token for me. The second is for host pecos, which means I used Kerberos to login to pecos recently. Ok, I have a ticket. What can I do with it?Kerberos has replacement programs for a number of the standard unix network utilites. These programs all use your Kerberos ticket instead of your password to authenticate you to the remote machine.Using Kerberos rlogin, rcp and rshThe kerberos rlogin, rsh and rcp programs are very similar to their standard counterparts. Basically just use them as you normally would. As long as you have a valid Kerberos ticket you can login and execute things remotely without having to type your password or set up a .rhosts file. If you are prompted for a password, this means that the Kerberos authentication failed and and the program fell back to doing a non-Kerberos connection. Do not type your password. Any password you type will not be encrypted and will go over the network in the clear. A failure like this is usually caused by one of two things, either your ticket has expired or the remote host is not running a Kerberos rlogind server.Try running kinit again and retrying. If that doesn't work contact kerberos@ncsa.uiuc.edu and let us know about the problem. A sometimes useful option with these commands is '-x'. This will cause the client to encrypt your session to the remote host giving you a great deal of privacy even against network sniffing. Using Kerberos telnetTo use the telnet program without having to type your password, you need to use it with the '-a' option. Otherwise you will be prompted for your password when you try to connection. Do not type your password. Any password you type will not be encrypted and will go over the network in the clear. If you use the '-a' option and it fails to log you in, this is normally becuase your Kerberos ticket has expired and you need to run kinit again. If this still fails please contact kerberos@ncsa.uiuc.edu and let us know about the problem. telnet also supports the '-x' option to encrypt your session and protect it's privacy.
Using Kerberos ftpTo use the Kerberos ftp program, run it as you normally would. Running ftp <hostname>, you'll notice that you will still be prompted for your username. That's normal, just hit return and you should find youself logged in.You can avoid having to enter your username if you create a file in your home directory called .netrc . This file should contain a list of enteries, one on a line, like the following: machine mss login vwelchWhere mss is the hostname and vwelch is the username to use. Again with the Kerberos ftp you should not be prompted for a password when trying to connect. If you are, do not type your password. Any password you type will not be encrypted and will go over the network in the clear. To protect the privacy of your session, enter the command private at the ftp command prompt. For example: Name (computer:vwelch): 232 GSSAPI user vwelch@NCSA.EDU is authorized as vwelch 230 User vwelch logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> private 200 Protection level set to Private.This will cause your session and data to be encrypted.
Back to NCSA Kerberos Information
Questions or comments about this page may be sent to kerberos@ncsa.uiuc.edu
|
||||||
|
|
||||||
