Batch Login Documentation

Who should read this document?

This document is aimed at administrators, engineers and users of Unix or Linux servers. It introduces a powerful automation tool that attempts to ease the difficulty of complex environments from the perspective of different connection protocols, zones (DMZs) and methods. It is not for non-Unix capable administrators or people that do not understand the fundamentals of automation and command-line access to Unix-like environments.

What is the purpose of this document?

This documentation describes two programs: Batch Login Version 2 (bl2) and Batch Login Terminal (blt2). These programs are written in the Korn shell programming language, Java, bash and expect. This document refers to the different languages at times in an effort to help new users adapt BatchLogin to their purposes.

What is the scope of this document?

This is an overview document, aimed at introducing BatchLogin to the uninitiated. Where possible, it points to other documentation that may serve the needs of the moment.

Documents Available:

Introducing Batch Login

BatchLogin is a program that aids in running tasks across multiple groups of servers. It does this by allowing a user to maintain groups of programs and password lists, leveraging the connectivity of the list against the automation provided by the scripts. It depends upon users who understand simple shell scripting and typical authentication methods utilized by command line access to Unix servers.

This program is specifically geared to address the complexity of the large, diverse environments, but can be utilized in any environment where multiple servers are employed. Often, in large enterprise-class environments, servers are configured in a multitude of ways with varying connection methods to each server. By eliminating the typical methods of file transport (ftp/scp/nfs) and concentrating on a simple network connection (ssh/telnet) to create and run automation, BatchLogin simplifies administration by allowing a group of servers that are not alike to be treated as such. BatchLogin gains its producivity edge by eliminating this portion of the solution from the worry of the end user or administrator. Often, questions like "I can't ftp/scp/nfs transport the file from server X" go away.

BatchLogin does this by creating programs and data utilizing simple Unix commands through a shell connection. All an administrator has to do is create a program and the rest is "taken care of" by BatchLogin.

Program configuration

The BatchLogin program depends upon a user maintaining a directory structure in their home directory called ".batch2". Under this directory, 4 different subdirectories can be found:


.batch2
   logs
   passlists
   scripts
   tmp

scripts directory

Programs in the scripts directory are small shell and expect scripts that are to be transported and/or run on the servers. There are two types of programs: scripts (run by the default shell spawned) and .exp scripts. Files that end in .exp are merged into the BatchLogin program and run in the expect interpretor on the starting machine. This is to allow for interactive expect sessions on machines that do not have expect loaded (This is one of the more powerful features of BatchLogin).

passlists directory

Files in this directory typically end in two different extensions: .blf (it stands for blowfish -or- batch login file) and .txt .

BLF files.
These are blowfish encoded password lists. The BatchLogin.crypt program maintains these and is fairly menu driven, although switches for encoding and decoding make some automation possible. Care is taken to prevent passwords from appearing in scripts or in process show commands. The user is expected to understand these limitations if advanced expect automation is attempted.
TXT files.
Text files are not encoded (plain text, in other words). Files that end in _group.txt are sub-groupings that reference servers in the encoded files. Utilizing this convention, a user can have a master password list and reference a sub-group inside the list. This allows a master password list to be easily maintained while separately keeping an overlapping grouping of servers. The BatchLogin.crypt program looks for .txt files as input.
BAK files.
These are created when the BatchLogin.crypt program does an edit on an existing .blf file. It is possible to edit an encrypted file with the batchlogin.crypt EDIT feature. If the file is updated, a backup file is created (usually .enc.bak).

tmp directory

The tmp directory simply houses files that batchlogin creates upon the fly. For forensic reasons, if a session gets killed or errors, the temporary expect script that failed may be found here. This directory may need regular cleaning for this reason.

logs directory

Finally, the "logs" directory contains a log pertaining to every session that is executed. The process id is also embedded into the log file name, preventing overlapping file names. All text that scrolls during a session is logged, so that a user has a concrete diary that can be examined, after the fact, of any session executed.

When batchlogin is called for the first time, this directory structure is created automatically. If the user does not have a password store (likely), the batchlogin program offers to start a batchlogin.crypt session, which allows a user to easily create a passlist store for execution. Note that scripts are not created in the same fashion. If a user does not know how to create a script, it's likely that they shouldn't be using batchlogin in the first place.

What can batchlogin do?

Just about anything that can be done from a command line interface can be automated with this program. It can transfer data (sluggishly) directly through terminal sessions with uuencode/uudecode. It's a great problem solver for a diverse enterprise-class environments. For example, say you need to find all servers that are running a certain piece of software. One option is to log into each one individually, the other might be to schedule a process through some sort of existing enterprise-class automation tool, such as CA-Unicenter or IBM Tivoli. Or, you could write a quick program and fire it off using batchlogin. In the third case, the output is logged, and the results more or less immediate, and you have the ability to interact if needed.

What are the limitations?

Mainly (at the moment) file transport speed. While it can easily transport a small shell script, it's a bad idea (TM) to transport large files across the network over a (potentially) 9600 baud console terminal session (as a worst-case example). That's the main limitation. Fairly reasonable (say several megabyte) tar archives can easily be passed in reasonable (say 2 to 3 minutes) per server, over a fast ssh network connection. Telnet sessions are much slower, but functional. Keep hands and feet away.

It also counts upon the user being somewhat skilled in shell scripting, and it depends upon the administrator being aware of connection protocols and passwords for the machines in question. Finally, it's not an end-all for all situations.

For all of these limitations, it's a great 80/20 solution.

Server Groups

Batch Login Terminal

Batch Login Terminal (BLT) is a variation on the batchlogin process. It uses the same password store as batchlogin, but leverages it to do single sessions on remote Unix servers.

BLT came into being after batchlogin. Watch anyone with a password list, gaining access to a set of servers, and you'll catch part of the reason the program was created. Users have an excel spreadsheets (oh no) or a Cyber-ark session open. They look up a particular server, cut the password for root out of it, and paste it into a terminal program of some kind.

This entire interaction is painstaking and chock full of ways to make an easy mistake (That wasn't the server I wanted, that wasn't the right terminal window, the cut was missed, etc, etc, etc). It was obvious, when I started using the encrypted output of the program the same way, that a simple shortcut could be engineered -- one where the password on the list would be utilized to decrypt the data, and the access would automatically leverage out of that data to give me a login on the box.

BLT (Batch Login Terminal) was born.

The main syntax of BLT is: blt [server]. BLT asks for the users' password that is used to decrypt the data, and batchlogin is spawned either as a sub process, or in a terminal session. It's fired in a special mode that simply loops through the list, looking for the matching server name. Once found, it uses the login data to log onto the server.

Initial startup

BLT uses a configuration file in the users' .batch2 directory called the bltrc . The file looks something like this:

# 
# Written by /opt/fericyde/bl2/batchlogin.sh on Mon Oct  6 15:15:29 EDT 2003
# 
CTLFILE=wsesolpass.enc
SCRIPT=SHELL.exp
PREFIX=no
TERMLOGIN=termstart.sh
#

When a user first starts blt2, it checks for the existence of this file, and if it does not exist, it walks the user through creation of a default bltrc. It finishes by writing the file. Note that by customizing the SCRIPT parameter (in this case, it calls SHELL.exp), a user may set things like default environment items that won't effect other users on the host. For example, by setting and exporting PS1 in the SHELL.exp, a user would be able to have their prompt be something other than the machine default -- and they would see this on any machine called with blt. The change would not be seen by other users, since the customization is done without altering the machines' default .profile.

Utilizing this and other tricks, such as the alias command, automation can be leveraged to make logging into differently configured Unix boxes much less painful.

The CTLFILE parameter controls the default password list that will be scanned for a users' environment. Attempting to log into servers where no password entry exists will result in an error. BLT is not meant to replace the lower connection methods of secure shell (or even, heaven forbid, telnet), but to augment and automate the processes.

BLT2 remembers a connection that is outside of the default password list, allowing the next connection to that same label to occur without prompting for the server list again.

The TERMLOGIN variable is used to designate a program that spawns the terminal itself. Most Unix environments have terminal programs (xterm, dtterm, rxvt, konsole -- it's a long list). All of these programs typically take an argument of a program to run after initialization. A default example using dtterm exists to illustrate how a user can control this environment as well. Colors, fonts, window titles and so on can be easily controlled in this manner. To customize, do a man page or a google search for a man page on your favorite terminal program, and find the options for these items, code them into a script using the default program for an example. It's really that simple.

Where do I go from here?

Create a password list, and run the bl2 program. One of the first things it will do is create the .batch2 directory, and ask to encrypt your password list. Name your list something that you will easily be able to identify, give it a password that no one will be able to guess -- the longer the better. Make it something that won't wear out your keyboard, though.

Next, run the blt2 program and run a test login into your favorite server. You should find it fairly easy to get around this way.