AutoSSH ( or simply ASSH ) is a UNIX based software to provide auto logon

capability for OpenSSH's ssh program. Unlike ways using host-based authentication

or using public key authentication with null passphrase for private key, AutoSSH

provides you a secure way for automating ssh.

Why need AutoSSH:

SSH auto logon can be achieved by using HostbasedAuthentication on

SSH server or using a private key with null passphrase protection on the client

when SSH server is using PubkeyAuthentication.

However, both ways are not good for security: Hostbased Authentication

uses host key which has no passphrase protection. And using a private

key with no passphrase protection gives you the same issue.

AutoSSH allows you to use PubkeyAuthentication for auto logon without

giving up the passphrase protection for your private key.

Using AutoSSH for ssh auto logon is also more secure than using ssh-agent:

with the source code available for everybody, it's not difficult for a malicious

person to know the full detail of ssh-agent program and using debugger to

retrieve your unprotected private keys from the ssh-agent. And unlike the way

using ssh-agent, once setup, AutoSSH allows you to achieve ssh auto logon

without any human intervention: even after system reboot.

How to use it:

AutoSSH program assh can be run in 2 different names:

assh: need pre-encrypted password/passphrase file generated

by asshkey.

asshc: need pre-encrypted password/passphrase file generated

by asshckey.

The difference between assh and asshc is asshc will only run when

command argument is given on command line, and will log all the

commands requested to run in /var/log/assh.log file.

Let assume that you are on an UNIX machine Mclnt with accout Uclnt, and

want to automate logon to a machine Msvr with SSH server running and

using Usvr as ssh account to connect.

First, you can setup pre-encrypted password/passphrase file on Mclnt

machine use Uclnt account by running:

/usr/local/bin/asshkey Usvr@Msvr

for assh to use; or

/usr/local/bin/asshckey Usvr@Msvr

for asshc to use.

This command will ask you the password for Usvr on Msvr if password

authentication method is used or the passphrase for your private key if public

key authentication method is used and then it will encrypt the

password/passphrase using AES and save to the file:

/usr/local/etc/assh/[c.] YourUID.Usvr@Msvr

which can only be used by Uclnt account.

After that, Uclnt can run

/usr/local/bin/assh Usvr@Msvr [command]

or

/usr/local/bin/asshc Usvr@Msvr "commands"

to logon to access server Msvr commandline using Usvr account or run

the [command] or "commands" on Msvr as user Usvr.

With the auto logon capability provided by assh and the power of ssh

client, now you can even schedule routine system maintenance work using

cronjob on a central control workstation:

0 23 * * * /usr/local/bin/asshc root@remote-host "commands"

How to install and setup:

First, download the wzpkg formatted assh package file from www.wziss.com,

and move the file to your machine’s /tmp or /var/tmp directory, turn on

execution bit for the file you downloaded, as root run it:

# ./assh-Ver_OS.platform-mbits.wzpkg

Note: if your machine hasn’t got wzpkgadm package installed, you need to

download that package and install it first.

then put the license for the machine in /etc/assh.lic file and the certificate for

number of connections allowed for the AutoSSH in /etc/assh.cap file.

Make sure the /etc/assh.lic and /etc/assh.cap files are readable by all users

that will run assh.

What also needed before you can run assh successfully is certificates for the

/usr/bin/ssh (or /usr/local/bin/ssh) program. To be able to generate a

certificate, you need to first run wzappkey:

/usr/local/bin/wzappkey -p assh

to setup a password for assh certificates administration. You will be asked for

the 32-character HEX Key for your AutoSSH license.

After that, you can run asshcreg

/usr/local/bin/asshcreg

This will generate and register new certificates for ssh command and the

libraries used by the command, save in /usr/local/etc/wzcert/assh file.

The certificates registered will help you to combat Trojan Horse attack,

including the OpenSSH Ebury Trojan. If you are sure, you can run asshcreg

with environment variable LIB_CERT set to FALSE for only generate and

register certificate for ssh command itself:

LIB_CERT=FALSE /usr/local/bin/asshcreg

When you run assh or asshc, all the registered certificates will be verified

before password/passphrase got decrypted and send to ssh.

Remember, if you change any file on your machine which belongs to the

assh package, ssh, or OS update which could update some libraries, you may

need to rerun the asshcreg to generate new certificates. You can run

/usr/local/bin/asshcchk

to verify if some files registered in /usr/local/etc/wzcert/assh have got change,

and then decide whether you should re-run asshcreg to re-generate and

register the certificates.

When you want to regenerate a certificate, you need first to remove

/usr/local/etc/wzcert/assh and /usr/local/etc/wzcert/assh.sum files.

For security reason, it is strongly recommended the 32-character HEX Key for

assh license and the certificate admin password to be securely protected and

is controlled by security officer instead of by system administrator.

Password Protection and Privilege Segregation:

AutoSSH uses sophisticated mechanisms to prevent a malicious person to

steal your passphrase/password or use stolen password file to attack

your server.

This software uses the AES for password encryption/decryption.

To further protect the encrypted password file, the file is set to be

readable only by root, same as the /etc/shadow file.

Moreover, the password encryption algorithm is license, ownership and

current server setup dependent, means even user A got user B's

encrypted password file, he still won't be able to run assh using the

'stolen' password file. Even a backup/restore could make the password

file invalid. (This is good for security, but it has side effect: in a high-avalability

clustered environment, even you will only run assh on one machine at a time,

you can't copy license and encrypted password file for it to work after fail-over

to another machine in the cluster:

You must locally setup license and encrypted password files on each

machine that will run assh.)

Also, password encrypted by AutoSSH is not interchangable with password

encryped by AutoSFTP.

To keep system administrator clean, the 32-character HEX Key for assh

license and the assh certificate administration password should be kept and

used by security officer only: a user which has root privilege may be able to

get decrypted password from encrypted password file no matter it belongs to

which user by replacing ssh program and generating certificates for the fake

programs if that person knows the HEX key or the certificate administration

password.

When properly managed, using AutoSSH could be more secure than

manually running ssh program: assh is not vulnerable to trojan horse

attack after encrypted password / passphrase file has been ready for

assh use while manual ssh is.

Also, AutoSSH is not vulnerable to system call tracing while manual ssh is.

Logging:

When AutoSSH program assh is named and run as asshc, it will not run if no

command argument is given on the command line.

And when asshc is used, the commands run by it will be logged into

/var/log/assh.log file with both begin and end time stamp.

This feature is useful when you want to use AutoSSH to build a central

control workstation for administering other servers: in this situation, one

important security control that your security department may require is to

record all commands issued from the control workstation.

By rejecting free command-line access, and logging down the commands

requested to run, asshc provides security officer a clear picture on what

commands have been requested to run on which server at what time and by

whom. And as assh will not and can not use the same encrypted

password/passphrase file used by asshc, you can avoid such situation that

some guy claims he accidently got a command-line access on a server by

running the wrong AutoSSH command.

Note:

AutoSSH can work with SSH servers which are compatible with openSSH

client software.

To run AutoSSH, you need install openSSH client software on the

machine AutoSSH resides. The ssh command need be installed either under

/usr/bin or /usr/local/bin.

When AutoSSH program is run as assh, it will use following sequence to

search the private key to be used for the connection:

1. /etc/ssh_rundirect/Uclnt/assh.key.Usvr@Msvr

2. /etc/ssh_rundirect/Uclnt/assh.key

3. ~Uclnt/.ssh/assh.key.Usvr@Msvr

4. ~Uclnt/.ssh/assh.key

5. as defined by the ssh_config file

Otherwise, when AutoSSH program is run as asshc, it will use following

sequence to search the private key to be used for the connection:

1. /etc/ssh_rundirect/Uclnt/asshc.key.Usvr@Msvr

2. /etc/ssh_rundirect/Uclnt/asshc.key

3. ~Uclnt/.ssh/asshc.key.Usvr@Msvr

4. ~Uclnt/.ssh/asshc.key

5. as defined by the ssh_config file

( Here, Msvr is the SSH server name; Usvr is the account name on Msvr for

SSH connection; Uclnt is the account name who runs the assh command. )

It will use the first key file found. Remember, the private key file, no matter

where to save it, must be readable by the client user (here: Uclnt), but not

others except root.

As such, Uclnt can make a private key file for AutoSSH use only.

Although other accounts on your machine will not be able to directly use your

encrypted password/passphrase file for logging on to the server through assh,

but anybody with root access is able to use your account and thus will be able

to use the encrypted file for that purpose. So be warned by this potential

security issue.

In a mission critical environment, for some special tasks, you may

consider to run AutoSSH with chroot jail environment controlled by

ssh_rundirect or other software you could trust (please read

ssh_rundirect.readme for more detail).

A commonly asked question is after an user runs

asshkey remote-user@remote-host.mydomain.com

later, the same user runs

assh remote-user@remote-host

the program will still complain no encrypted password, why?

This is because assh will use the "remote-user@remote-host" given by

the user on the assh command line to generate the name for encrypted

password file.

When you want to regenerate the encypted password/passphrase file,

you will need to key in the old password/passphrase for verification. If you

forgot the old password/passphrase, you need to ask system

administrator to remove the file:

/usr/local/etc/assh/YourUID.remote-user@remote-server

used by assh; or

/usr/local/etc/assh/c.YourUID.remote-user@remote-server

used by asshc.

If you really need, AutoSSH allows you to setup a "default" password /

pass phrase file by using the generic "user@server" as argument when

you run asshkey or asshckey:

asshkey user@server

or

asshckey user@server

Later, when you run assh

assh remote-user@remote-host ...

the command will first try to use

/usr/local/etc/assh/YourUID.remote-user@remote-host

as the encrypted password/passphrase file. And only when the file does not

exist, the command will then look for

/usr/local/etc/assh/YourUID.user@server

Similarly, for asshc, the sequence will be first

/usr/local/etc/assh/c.YourUID.remote-user@remote-host

if it does not exist, then

/usr/local/etc/assh/c.YourUID.user@server

AutoSSH's usage is controlled by license and link capacity: each non-generic

password/passphrase file saved under /usr/local/etc/assh/ consumes one link

capacity, while each generic password/passphrase file generated by

asshkey user@server

or

asshckey user@server

consumes 20 link capacities.

AutoSSH installation using DEMO license only allows 2 link capacities, and as

such generic password/passphrase file is not allowed for DEMO. (When you

run assh/asshc/asshkey/asshckey and see a message like "Insufficient link

capacities" or "Not enough link capacities", it means files under

/usr/local/etc/assh have consumed or will consume more link capacities than

the allowed capacities defined in /etc/assh.cap, or 2 if you are using a DEMO

license.

You can buy more link capacities when you need them by sending your

request to us together with the existing contents of /etc/assh.lic and

/etc/assh.cap files. Unlike updating /etc/assh.lic license file, adding more link

capacities to /etc/assh.cap file will not break your existing encrypted

password/passphrase files under /usr/local/etc/assh.

Possible Issues

If the remote server’s hostkey got changed, you need to manually

remove that server’s old hostkey from your known_hosts file before

assh/asshc can work again.

If openSSH software on your client machine got updated, you need to

ask your security officer to re-certify the new ssh binary, but to do that,

you need first remove the old ssh certificate files

/usr/local/etc/wzcert/assh

/usr/local/etc/wzcert/assh.sum

And then your security officer needs to run

/usr/local/bin/asshcreg

If for whatever reason, the system has to be re-installed or restored

from backup. That could cause all encrypted password/passphrase

files become invalid. So, under this situation, you need to re-setup

those encrypted files. This is not a bug, but is by design for better

security.

Got error: Insufficient link capacities!

This means you have used up all the link capacities you bought for this

machine so far. If you want, you can buy more link capacities in

addition to the current one you have. To do so, please send

/etc/assh.lic and /etc/assh.cap files together with how many more link

capacity groups (each link capacity group contains 5 link capacities)

through email to sales @ wziss . com. Once we received your payment

for the purchase, we will send you the updated assh.cap which will

have your original number of links allowed plus the new add on.

I can use

assh RemoteUser@RemoteServer.mycompany.com ls

but not

assh RemoteUser@RemoteServer ls

and

ping RemoteServer

works fine also. Why?

When AutoSSH searchs for encrypted password/passphrase file to use,

it will use the same name you gave on the command line, and if when

you set up the encrypted file, you used a different name, even when

both names are for same server, it won’t work. So, you have to use the

same name.

Certificate file checksum integrity verification:

To use password protected checksum verification, you can run

asshcchk –i

this will ask you the checksum protection password and then verify

whether the recorded certificate file checksum has been illegally

changed or not based on password encrypted checksum.

When running asshcchk without arguments, it will check calculate the

certificate file’s checksum and compare it with the recorded one to see

if any illegal change has been made to the certificate file.