How to Kerberize your site 


Mail comments and suggestions to Jim Rome, the keeper of this page.
Visit my Home Page to look at my other acitvities. I would welcome the addition of your Kerberos installation logs.

Contents

Introduction
Pick a Kerberos server machine (kdc)
DCE and Kerberos
Install the Kerberos server
Compiling Kerberos
Configuring the Kerberos kdc
Setting up a host server
Kerberos clients
Getting a ticket for another realm
Kerberos authentication option in SSL
Security problems
The Kerbnet solution
Available Kerberized goodies
Questions and answers
Other Kerberos links

Introduction

There's a lot of talk on the Internet about security and the lack of it on UNIX systems. This is, in part, a by-product of the world of the net in which we choose to do business. We can do some things to help counteract the possibility of attack on our systems.

One way to help is with Kerberos. Kerberos is an authentication and encryption scheme that allows a user to become "known" by an authenticating server and then use that authentication to access systems and services on the net. The services can then transpire in an encrypted fashion to further secure transactions occurring over the net. The philosophy behind the creation of Kerberos, and a short summary of how it works is available, but here we assume that you know what Kerberos is, and wish to implement a Kerberos domain on your network. But, we also assume that you are not a hot-shot UNIX programmer, so we intend to lead you by the hand in a step-by-step fashion through the entire process. In other words, this is our version of "Kerberos for Dummies."

Several commercial integrators provide enterprise Kerberos solutions as well as technical support and maintenance.  In particular, perhaps the easiest way to install Kerberos V5 is to use Kerbnet from Cygnus solutions. Kerbnet is free and has clients for Win32 machines, Macintoshes and Unix hosts, and has KDC software for Unix and NT as well as host servers for Unix platforms.

Check out the MIT Kerberos Web Site for the latest Kerberos release news.  Another good source of information is the Kerberos FAQ compiled by Ken Hornstein.

Pick a Kerberos server machine (kdc)

The machine that you pick as your Kerberos server is the key to your network security. Therefore, it must be as secure as possible. Here is a non-exhaustive list of things to consider when selecting your server machine:

DCE and Kerberos

There is alternate mode of operation which uses the DCE Security Service as the K5 KDC. Several sites (such as ESnet) are doing this. This is a good idea if you have DCE at your site because it allows you to have just one database of users rather than having users registered in two places.

 If anyone has questions about using MIT Kerberos 5 tools with a DCE based KDC, send a message to:
[email protected]

More information on the issues involved in accessing the distributed file systems AFS and DFS from Kerberos are discussed by Doug Engert.

If you use the DCE based KDC, you still need to compile the MIT Kerberos 5 software. But you will not run the MIT Kerberos key server (/krb5/sbin/krb5kdc) or the MIT kadmind server (/krb5/sbin/kadmind).

 

Install the Kerberos server

Be sure to get Kerberos version 5 patch level 1 (or greater) to fix two serious security holes.

In these instructions, your typing is shown in italics.

Consider obtaining the Kerbnet code from Cygnus Solutions. This code is prebuilt and well-documented.

Obtain the necessary code

  1. Create a directory for your kerberos code.

    2. mkdir /kerberos
    cd /kerberos
  2. ftp to MIT to obtain the code. It is easiest if you use your Web browser.

    3. ftp://athena-dist.mit.edu/pub/kerberos
    An alternate site for all of the software is ftp://prep.ai.mit.edu/pub/kerberos.
  3. In the /pub/kerberos directory, get the README.KRB5 file:
  4. Read the file to find out the name of the directory containing the code (it changes periodically)

    5. For me, this was dist/961209, but it may have changed. You must go to this directory in one step!
    ftp://athena-dist.mit.edu/pub/kerberos/dist/961209
  5. Retrieve all the files (in binary!). The .asc files are the digital signatures for the corresponding files so that you can ensure that they have been unchanged.
  6. gunzip all the files and extract them. If you do not have gunzip, you can obtain it from the same place:

    7. ftp://athena-dist.mit.edu/pub/gnu/gzip-1.2.4.tar

Do you need more code?

Kerberos requires an ANSI-compatible C compiler and you will encounter fewer problems if you use the free gnu C compiler, gcc. So, you may have to make a temporary detour and obtain and compile all of the gnu tools. You can get a complete list at ftp://athena-dist.mit.edu/pub/gnu/.

To properly build the C compiler (gcc), you will first need to get and install bison and the gnu assembler (as). The assembler is found in the binutils package. Without the gnu assembler, I obtained numerous warnings during the compilation procedure, all of which disappeared when the gnu as was used. You might also be more successful if you use the gnu make facility. If you do not have a C library on your machine, you will also need to obtain glibc from the gnu distribution (this should NOT be necessary on a UNIX machine). For debugging, obtain the gnu debugger, gdb.

It will probably take an afternoon to build all of these tools. In each case, installation is fairly straight forward. As root, gunzip and untar each of the above .tar.gz files and switch into the program's root directory, which is always the utility name followed by the release number. To be safe, read the INSTALL file or README file if the former does not exist. You can use gzcat to save disk space by doing both of these steps at once:

gzcat filename.tar.gz | tar -xpf -

Building the gnu tools

I suggest making the tools in the order bison, make, binutils. In each case, the process is similar. Switch to the program's main source directory and
  1. Create the Makefile by running

    2. ./configure
  2. Make the program by doing

    3. make
  3. Install the utilities in /usr/local/bin by doing

    4. make install

Building the gnu C compiler

You are now ready to make the gnu C compiler. This is fairly complicated, so you need to read the INSTALL file and follow the instructions. Be sure to use the gnu assembler, as.
  1. In the gcc_version directory, run

    2. ./configure --with-gnu-as
  2. Build the stage 1 compiler. Just type make LANGUAGES=c in the compiler directory. This will take some time.
  3. Copy the initial compiler build into the stage1 subdirectory by typing

    4. make stage1
  4. Copy the gnu assembler into the stage1 directory. For example,

    5. cp /usr/local/bin/as ~/gnu/gcc-2.7.2.1/stage1/as
  5. Compile the compiler with itself to make the stage 2 compiler.

    6. make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2" LANGUAGES="C C++"
    If you do not wish to have a C++ compiler, just use LANGUAGES="C".
  6. Finally, to be safe, test the compiler by compiling it with itself one more time. Install any other necessary GNU tools (such as the gnu assembler or the GNU linker) in the `stage2' subdirectory as you did in the `stage1' subdirectory, then

    7. make stage2
    make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
    This is called making the stage 3 compiler. Aside from the `-B' option, the compiler options should be the same as when you made the stage 2 compiler. But the `LANGUAGES' option need not be the same. The command shown above builds compilers for all the supported languages; if you don't want them all, you can specify the languages to build by typing the argument `LANGUAGES="LIST"', as described above.
  7. You can compare the stage2 and stage 3 compilers (they should be identical) by running

    8. make compare
    However, I have had no luck doing this. The two stages are always quite different on my machine.
  8. Install the compiler driver, the compiler's passes and run-time support with `make install'. Use the same value for `CC', `CFLAGS' and `LANGUAGES' that you used when compiling the files that are being installed. One reason this is necessary is that some versions of make have bugs and recompile files gratuitously when you perform this step. If you use the same variable values, those files will be recompiled properly.

    9. For example, if you have built the stage 2 compiler, you can use the following command:
    make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="C C++"
    This should copy the files `cc1', `cpp' and `libgcc.a' to files `cc1', `cpp' and `libgcc.a' in the directory `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the compiler driver program looks for them. Here TARGET is the target machine type specified when you ran `configure', and VERSION is the version number of GNU CC. This naming scheme permits various versions and/or cross-compilers to coexist. This step also copies the driver program `xgcc' into `/usr/local/bin/gcc', so that it appears in typical execution search paths.

On my system, the make install step hung when it tried to use the makeinfo utility that was not present on my system. So, I had to edit the Makefile. I changed the lines for the action install-normal:

install-normal: install-common $(INSTALL_HEADERS) $(INSTALL_LIBGCC) \
install-libobjc install-man lang.install-normal install-driver

to eliminate install-info from the second line. Then gcc was successfully installed! 

Compiling Kerberos

In general, you will have the best results if you use the GNU version of make. If you get weird errors during the make process, try the GNU make and see if they don't go away.

It is also good to get advice from experts. So, obtain the README file from Doug Engert's ftp site at Argonne National Laboratory:

ftp://achilles.ctd.anl.gov/pub/kerberos.v5/README

For example, for my HP-UX 10 system, Doug suggests many options in the configure command:

../src/configure --with-cc=gcc \
--with-ccopts="-O " --prefix=/krb5\
--with-cppopts='-DANL_DCE -DAFS524 '

The prefix option places the resulting source into the directory /krb5 rather than the default. In general, I had much better success getting configure to work properly if I put the --prefix command near the beginning of the configure argument string rather than at the end. It shouldn't make any difference, but it did.

For Solaris 2.6 I used the Sun c89 compiler and make (no gnu utilities) and had no problems at all. I used the configure command:

../src/configure --with-cc=c89 \
--enable-shared \
--with-ccopts="-O "\
--with-cppopts="-DANL_DCE -DANL_AFS_PAG -DANL_DFS_PAG -DAFS524 -DNO_MOTD "\
--prefix=/krb5

For AIX 3.2.x, I had the IBM ANSI compiler, but the build only worked if I used --with-cc=cc as opposed to xlc or c89. On this platform, all components built properly with the configure command:

../src/configure --with-cc=cc \
--with-ccopts="-O " \
--with-cppopts='-DANL_DCE -DAFS524 '\
--prefix=/krb5

For AIX 4.1.3, I used the IBM (cc) compiler and the configure command:
../src/configure --with-cc=cc --prefix=/krb5 \
--with-cppopts='-DANL_DCE -DAFS524 -ULOGIN_CAP_F '

For AIX 4.2 with the IBM C/C++ compiler, configure would not work unless I used the command:
../src/configure --with-cc=cc --prefix=/krb5 \
--with-cppopts='-DANL_DCE -DAFS524 -ULOGIN_CAP_F '

However, make will fail in the /src/util/pty directory unless you edit the Makefile to remove the two switches -DHAVE_SETUTXENT=1 -DHAVE_UTMPX_H=1
Having both utmp.h and utmpx.h included causes the utmp structure to be multiple defined, and the definition in utmpx is not the one that is needed.

 The code for the telnetd will not compile because the include in the file src/appl/telnet/telnetd/termios-tn.c is incorrect. Change #include <termios.h>
to #include <sys/termio.h>

For all platforms

  1. In the /krb5-1.0/src directory, run the above configure command.
  2. Make the code by doing

    3. make
    in the src directory.
    If you are using the GNU make, and have renamed it to gmake, use the command
    gmake MAKE=gmake
  3. Install Kerberos using

    4. make install
    (or  gmake MAKE=gmake install)
    which puts the code into /krb5, as specified by the prefix option in configure.

Configuring the Kerberos kdc

The next step is to print out and read the three Kerberos manuals, located in the docs directory of the Kerberos distribution. Unfortunately, the configuration process is not totally obvious.

Create the configuration files

Create the krb5.conf and kdc.conf files using mine as boiler plate. krb5.conf needs to be in /etc, and the location of kdc.conf can be specified in the krb5.conf file. However, initially, Kerberos cannot find the file unless it is in the var directory inder the root kerberos installation location. Therefore, we put it in /krb5/var/krb5kdc/kdc.conf. Note that the realm names are case sensitive! Use the same case in both files and when making a connection to the realm.

Edit these files to reflect your Kerberos domain instead of mine (dsdoe.ornl.gov).

Create the Kerberos databases

Create the Kerberos database using the kdb5_util command

/krb5/sbin/kdb5_util create -r dsdoe.ornl.gov -s
Initializing database '/krb5/lvar/krb5kdc/principal' for realm 'dsdoe.ornl.gov',
master key name 'K/[email protected]'

You will be prompted for the database Master Password. It is important that you NOT FORGET this password.

Enter KDC database master key:
your_master_key
Re-enter KDC database master key to verify:
your_master_key

Replace our domain name with yours. The -s creates a stash file which is used to authenticate the KDC to itself.

Create an administrator kadm5.acl file following the instructions in the Kerberos manual. Put it in the location specified in the 'acl_file =' section of kdc.conf.

Add your administrator(s) to the KDC database as per the manual

 /krb5:738: sbin/kadmin.local
kadmin.local: addprinc admin/[email protected]
Enter password for principal "admin/[email protected]": your_password
Re-enter password for principal "admin/[email protected]": your_password
Principal "admin/[email protected]" created./krb5/sbin/kadmin.local

Create the keytab file on the server. kadmind uses this to determine what access it should give to administrators. The manual is wrong here. Stay in kadmin.local and give the command:

kadmin.local: ktadd -k /krb5/var/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw
Entry for principal kadmin/admin with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/krb5/var/krb5kdc/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/krb5/var/krb5kdc/kadm5.keytab.
kadmin.local: quit

Edit the /etc/services file to include the following kerberized servcies. This list shows all the available servcies. Your key server should only have the uncommented lines on the key server machine. The other services are used for Kerberized hosts.

# # Kerberos (Project Athena/MIT) services
#
#kerberos 88/udp kdc # Kerberos 5 kdc
#kerberos 88/tcp kdc # Kerberos 5 kdc
#klogin 543/tcp # Kerberos rlogin -kfall
#kshell 544/tcp krcmd # Kerberos remote shell -kfall
krb5_prop 754/tcp # Kerberos v5 slave propagation
kerberos-adm 749/tcp # Kerberos v5 admin/chpwd
kerberos-adm 749/udp # Kerberos v5 admin/chpwd
#eklogin 2105/tcp # Kerberos encrypted rlogin -kfall
kpasswd 761/tcp kpwd # Kerberos "passwd" -kfall
#ktelnet 545/tcp # Kerberized telnet v4/v5
#kftp-data 546/tcp # Kerberized ftp data V5
#kftp 547/tcp # Kerberized ftp v5
#

Start the Kerberos key servers

Start the master KDC and the Kerberos administration demons:

/krb5/sbin/krb5kdc
/krb5/sbin/kadmind

If you want the two servers to start up automatically when your kdc machine is rebooted, you need to add them to your rc.local, inittab, or init.d or whatever your system uses to start processes at boot time.

 

Getting the kadmin demon to work

kadmin allows you to administer the Kerberos databases remotely (and securely). If you just run kadmin, you will obtain an error message like:

kadmin: Client not found in Kerberos database while initializing kadmin interface

To be able to use the kadmin interface, you need to register yourself as a database administrator.

On the KDC machine, in kadmin.local add an administrator role for yourself:

kadmin.local: addprinc jar/[email protected]
Enter password for principal "jar/[email protected]": your_password
Re-enter password for principal "jar/[email protected]": your_password
Principal "jar/[email protected]" created.
kadmin.local: quit

Now, on a remote machine (on which you have also installed Kerberos), you can get a ticket as an administrator.

 dsrocf:/krb5/bin: ./kinit jar/admin
Password for jar/[email protected]: your_password
dsrocf:/krb5/bin: ./klist

Now you can check to see that you have the correct ticket
Ticket cache:

/tmp/krb5cc_0
Default principal: jar/[email protected]
Valid starting Expires Service principal
18 Dec 96 14:13:52 19 Dec 96 00:13:26 krbtgt/[email protected]

NOTE: This HP-UX machine has DCE clients installed as part of the operating system. BE SURE TO USE THE PROGRAMS IN THE /krb5 DIRECTORY TREE. THE DCE VERSIONS ARE NOT COMPATIBLE WITH KERBEROS V5.

Now you can access kadmin on the Kerberos server (dsroc3) from dsrocf.

dsrocf:/krb5/sbin:409: ./kadmin
Enter password: your_password
kadmin:

Tip

A very easy way to see whats going wrong is to use strace. You can see what the program is trying to do and where it fails. To use strace on kadmin for example: strace kadmin.

Setting up a host server

A host is a machine that offers kerberized services (telnet, ftp, rlogin,?) to users. We want to configure dsrocf as a Kerberized host. To allow this, we need to create a /etc/krb5.keytab file. This is easy now that we can run kadmin remotely on the KDC. You need to be root on the host machine in order to be able to write into /etc. In kadmin, add the host as a principal:

kadmin: add_principal host/dsrocf.dsdoe.ornl.gov
Enter password for principal "host/[email protected]":
Re-enter password for principal "host/[email protected]":
Principal "host/[email protected]" created.

Then add its keytab entry in the LOCAL (dsrocf) /etc/krb5.keytab file. This process securely shares a secret key to be used for communication between the Kerberized host and the KDC server.

kadmin: ktadd host/dsrocf.dsdoe.ornl.gov
Entry for principal host/dsrocf.dsdoe.ornl.gov with kvno 4,
encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5.keytab.

Repeat this process for every host in your realm.

Finally, you should add the following lines to the end of the /etc/inetd.conf file on each host so that the Kerberos daemons start up automatically when your host is rebooted:

 #
#Kerberos daemons
#
klogin stream tcp nowait root /krb5/sbin/klogind klogind -ki
eklogin stream tcp nowait root /krb5/sbin/klogind klogind -eki
kshell stream tcp nowait root /krb5/sbin/kshd kshd -ki
ktelnet stream tcp nowait root /krb5/sbin/telnetd telnetd -a user
kftp stream tcp nowait root /krb5/sbin/ftpd -a

If you change the inetd.conf file, you must inform the inet daemon to put them into effect. It is done differently on different systems. For example, on AIX  run the refresh -s inetd or kill -1 InetdPID command. On HP-UX, use the command inetd -c.

Domain names

Kerberos uses gethostbyname() to determine the fully qualified domain name of each Kerberos host. On my system, this returned the short name and caused the Kerberos server to deny authorization. To test this function, run

/krb5/src/tests/resolve/resolve [hostname]

for each host. I had to edit the /etc/hosts file to be sure that the long host name came before the short name.

 

Kerberos clients

Kerberos for Windows NT

A snapshot of the NT (Intel platform) release is available from MIT. This is a preliminary alpha release, but it seems to work well. To use this version, unzip all the files into a subdirectory (e.g., D:\KRB5). Move the dlls to C:\WINNT\SYSTEM32. Put your krb5.ini file into the C:\WINNT directory. krn5.ini has the same contents as the krb5.conf file that is used on Unix systems. 

Getting a ticket for another realm

Doug Engert (ANL) has extended DCE to support Kerberos tickets and to do cross-realm authentication. Here are the steps that I had to use to log on securely to a machine in Doug's domain. Note that we exchanged passwords over the telephone and later changed them in a face-to-face meeting.

Both of us had to perform these steps on our KDCs using our secret shared password:

/krb5/sbin/kadmin.local -e des:v4
addprinc -kvno 1 -pw [yourpassword] krbtgt/[email protected]
addprinc -kvno 1 -pw [your password] krbtgt/[email protected]

Next, I had to run kinit (as myself) to get a ticket from my KDC.

dsrocf:/home/jar:7: /krb5/bin/kinit jar
Password for [email protected]:
dsrocf:/home/jar:8:

Then I was able to test to see if I could rlogin to a machine at ANL from ORNL:

/krb5/bin/rlogin caliban.ctd.anl.gov -x -l b17783
caliban.ctd.anl.gov% exit
caliban.ctd.anl.gov% logout
Connection closed.
Local flow control on

It worked! We can examine the ticket cache to see how this worked.

dsrocf:/krb5:11: bin/klist
Ticket cache: /tmp/krb5cc_11192
Default principal: [email protected] Valid starting Expires Service principal
05 Dec 96 16:13:33 06 Dec 96 02:13:33 krbtgt/[email protected]
05 Dec 96 16:14:33 06 Dec 96 02:13:33 krbtgt/[email protected]
05 Dec 96 16:14:40 06 Dec 96 02:13:33 host/[email protected]
dsrocf:/krb5:12: 

Kerberos security problems

There has been discovered a security-hole in kerberized rsh, rcp and rlogin.

Everyone who has setuid-bits set on these applications is adviced to disable  them.  The hole allows any user on the system to gain privilegies of any other user  including root.

The hole has been successfully tested on kth-kerberos, but is suspected to
exist on any other versions of kerberos.

Artur Grabowski (administrator on stacken.kth.se)

-------------------------------------------------------------------

Serious buffer overrun vulnerabilities exist in many implementations of Kerberos 4, including implementations included for backwards compatibility in Kerberos 5 implementations. Other less serious buffer overrun vulnerabilites have also been discovered. ALL KNOWN KERBEROS 4 IMPLEMENTATIONS derived from MIT sources are believed to be vulnerable.
 
 

Kerberos authentication option in SSL

Netscape's Secure Socket Layer (SSL 3.0) has been modified to support the Kerberos authentication option as described in draft-ietf-tls-kerb-cipher-suites-01.txt of the Internet Engineering Task Force (IETF). A reference implementation is available at:
ftp://prospero.isi.edu/pub/ssl-krb
The draft (presented at the IETF's Transport Layer Security (TLS) working group meeting, Dec. 1996) proposes the addition of new cipher suites to the TLS protocol (SSL 3.0) to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication.

Note: The reference implementation uses MIT's Kerberos V5 beta 6.

The draft and reference implementation are the work of Ari Medvinsky and Matt Hur at the CyberSafe Corporation.

Available Kerberized goodies

CVS Code revision control system

Wolfgang S. Rupprecht has created a version of the  CVS code revision control system that uses Kerberos authentication of users. An excellent online CVS manual (for the unkerberized version) is available at http://www.brandonu.ca/~weingart/misc/cvstrain/cvstrain.html

CygnusKerbnet for NT, Macs, and Unix

In September, 1997 Cygnus Solutions released a free implementation of Kerberos V5 including clients for Windows 95, Windows NT, and Macintoshes.  Kerbnet comes with source code, precompiled binaries and excellent documentation. For the first time, you can set up a KDC on an NT platform which offers some security advantages over Unix.

Unfortunately, the CygnusKerbnet version of Kerberos is no longer available. However, Cygnus offers a PC environment called Cygwin that emulates Unix. The Kerberos source code has been modified by Vern Staats to run on Windows 2000 including ssh.
 

Questions and answers

Question:

When I do the rlogin, who am I, and how did I get a ticket?

Answer:

You should be known to Kerberos as the identity you used when you ran kinit. In my case, this was [email protected]
You can have a different local UNIX uid, since Unix does not understand the concept of realms. All UNIX uids are local, or local to the default NIS domain. (domain, realm, cell all meant about the same thing in this regard.)

rlogin itself really does not understand realms either, so when you startup an rlogin session, it takes your local UNIX uid, and tries to use it at the remote site. the -l option overrides this, and gives the local UNIX id to use for the rlogind to use. rlogind looks this -l uid up in the local password file getpwent() and finds your home directory. It then looks at the .k5login file to see which Kerberos principals it will allow to use this local uid.

Question:

How can I do X-windows securely?

Answer:

Support for Kerberos V5 has been added to SSH 1.2.19. This code which was provided by Glenn Machin, allows the sshd to either accept a Kerberos userid and password, or a ticket for authentication. The ssh and sshd can also forward a ticket too. (There are other options too.)

The ability to get an encrypted X session back is a nice feature, as is the ability it use the ticket obtained or forwarded to get a AFS token or DCE context.

 The F-Secure program from DataFellows implements SSH on Windows, and can be used with the sshd on a unix system. The F-Secure ssh client on Windows does not currently use Kerberos authentication, but since it does provide an encrypted channel, you can send a Kerberos passsword to the sshd when login in. The encrypted X works here as well.

 I have tried Exceed on Windows 95, with F-Secure to a Solaris 2.5 system, running sshd linked with the MIT Kerberos 5-1.0 libs. The system also has AFS and DCE 1.1, and I can get a AFS token and DCE context. It alos works between AIX 4.1.4 and Solaris. Will be testing HPUX 10, SGI 6 and SunOS 4 soon.

See: http://www.cs.hut.fi and http://www.datafellows.com

 Douglas E. Engert ([email protected])
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

To enable Kerberos V5 support when you make ssh, use the following configure command:
./configure --with-kerberos5=/krb5 --enable-kerberos-tgt-passing

More advice on SSH/Kerberos gotchas.
 

Question:

How can I transfer files securely?

Answer:

By default, Kerberos's version of ftp encrypts your username and password, and leaves the file's contents unencrypted. However,  you can use the ftp command private to tell the Kerberos ftp to also encrypt your data.

In addition, the Kerberos rcp command also supports encryption with the -x option which encrypts all information transferring between hosts.  To use the rcp command, you must either have the same user id on the remote host, or you must have an entry in the remote host's .k5login file in the destination user's login directory.
 

Question:

Can I integrate Kerberos with some form of hardware token?

Answer:

Ken Hornstein at Naval Research Labs has modified the Kerberos distribution to include support for the SecureID card.

 

Other Kerberos links

Information gathered from the [email protected] mailing list
The kerberos news group
Updated: Wednesday, 01-Oct-2003 12:30:20 EDT
Visitors:
Back to the top of the page