Ever since networking came out, one important issue, to a various
extent over the time, has been how to give the legitimate users the
right access – authentication, which is one of the three basic elements
in security: authentication, authorization and access control.
Over the last decade, we have seen telnet being replaced by the ssh
protocol, which ensures secure encrypted traffic including the
passwords. However, no matter how secure the technology is, users can
always open up a security hole for the sake of convenience. In the case
of Openssh, one common misused feature is the RSA/DSA key
authentication system. Imagine the following situation: John is a new
system administrator in a small company, who is responsible for twenty
Linux machines. His tasks require his logging into different systems
and copying files from each other. He knows that ssh and scp (secure
copy) is a much more secure option than telnet. However, he soon finds
typing passwords for every login and scp very tedious. Therefore, he
wants a passwordless authentication. With some googling in the
Internet, John found his solution: RSA/DSA key authentication. Then
John set up his passwordless login in ten minutes with an UNENCRYPTED
private key sitting in his harddisk. Unfortunately, his private key was
stolen by some spyware. The next day, John finds his boss furious that
all servers’ data were erased by someone. And our poor John lost his
first job.
In this article, I’m going to show you how to properly set up a
passwordless DSA key authentication using Keychain. Then I will explain
what is happening behind the scene, and evaluate the benefits and risks
of such a setup; and finally I will look at some other possible use of
the keybased authentication technology.
The following instructions are based on a Gentoo Linux system:
$ ssh-keygen -t dsa
(Accept the default values, and enter a STRONG passphrase.)- Append localhost:~/.ssh/id_dsa.pub to remotehost:~/.ssh/authorized_keys
$ emerge keychain
$ keychain --clear ~/.ssh/id_dsa
(Enter your passphrase.)- Append “source ~/.keychain/$HOSTNAME-sh” to your ~/.bashrc ONCE.
- Start a new prompt, and ssh to remotehost.
Note: the $ indicates a prompt input.
Now, you should be able to log into remotehost without a password.
So what’s the magic behind all this wonderful passwordless login? Let
us look at the steps one by one.
In step 1, we created an asymmetric DSA key pair – one public key
that you can give to anyone and one private key that you keep strictly
to yourself. DSA stands for Digital Signature Algorithm, which
reasonably ensures the infeasibility to recover the private key from a
known public key, and decrypt messages encrypted with the public key
without the private key. As the name implies, the DSA key pair is some
kind of signature to prove your identity. This key pair is the core
part of the DSA key authentication. The way it works in a deployed
key-based authentication system is: the server generates a random
number and encrypts it with your public key. Then the encrypted message
is sent to the client through the already established ssh secure
channel. Next, the client uses your private key to decrypt the number
and send it back to the server to prove that you are the holder of the
matched private key, thus your identity is verified and the server logs
you in. Step 2 is simply installing your public key to the remote host,
i.e. the server.
Note that you have to enter a STRONG passphase in the key generation
to encrypt your private key. Otherwise, you will find yourself in the
same shoes as our poor John. I know an unencrypted private key is the
quick, but insecure, way to achieve passwordless login. But hold on, we
have a better way. And it’s just a three-step process.
In step 3, I installed keychain, the bash-based ssh-agent frontend
that helps us accomplish passwordless logins. In step 4, I started
keychain with the –clear option, which I will explain later, using my
newly created encrypted private key. This step starts a ssh-agent
daemon (a background process), which caches your unencrypted private
key after you enter the correct passphrase. The cache is valid until a
new login happens. In step 5, I set up the user profile so that
ssh-agent’s PID (process ID) and its authentication sock are exported
to the appropriate environment variables whenever a new prompt is
started. Now any subsequent ssh or scp operation can grab the cached
private key through ssh-agent and establish a secure connection without
passwords.
Most users will stop right here and enjoy their new found
convenience. However, we cannot stop without understanding its
ramification when the security mechanism is altered. Next, I will lay
out the benefits and risks pertaining to this keybased passwordless
setup.
Benefits
1 . Passwordless.
People love convenience. If a user is annoyed enough by the system,
s/he will try to find way to get around it, usually opening up serious
security holes. For example, s/he might use a short and easy to
remember password or use an unencrypted private key. Given a choice, I
would prefer safer convenience to dangerous convenience. Thus, the
keychain solution is shown here.
2 . Agent forwarding.
Here is the context: you are using your own machine, A, which holds
your private key and has a ssh-agent running. And you have access to
two untrusted remote machines, B and C. Both have the keybased
authentication set up. Now, you connect to B from A without a password
because you already have a running ssh-agent daemon. Then you want to
connect to C from B. If machine B has agent forwarding enabled, it will
forward the challenge from machine C to A, and forward the response
from A to C in order for machine C to authenticate you. This is called
agent forwarding. The benefit is that you don’t need to put your
private key in the untrusted machine B lest it is stolen; and you don’t
need to type your password in machine B to connect to C lest a key
logger is installed in machine B to tap your passwords.
3 . Enabling ssh connections for cron jobs.
If a cron job requires a remote connection to some other machines,
some people will resort to embedding the passwords in the cron job
itself using telnet or ftp. However, this is a bad practice. Instead,
the keychain passwordless keybased authentication is a better solution.
Remember the –clear option in step 4? It’s designed specifically for
cron jobs. It tells keychain to flush the cache key whenever a new
login happens, but keep the cache when a user logs out. The rationale
is a new login poses some security risk as it could be an intruder that
just has stolen your password. However, a logout shouldn’t pose any
security risk. So that even after user logout, the cron jobs can still
use the running ssh-agent to establish a secure connection.
Risks
1 . Bathroom break hijack.
Please lock your computer before going to bathroom. Otherwise, your
roommates or whoever has physical access to your unlock session might
do nasty things to your remote hosts. So don’t complain when your
CSC309 essay is gone somehow.
2 . Memory dump to acquire unencrypted private key.
There might be a possibility for a highly-skilled hacker to force a
ssh-agent memory dump and steal the unencrypted private key, given that
he has broken into your system. A solution to this problem could be the
Trusted Platform Module (TPM), which is a hardware chip that stores the
sensitive information, such as private keys. With TPM, the private key
will reside in the chip instead of the main memory, so that a memory
dump attack will be futile. Some laptops already feature this
technology.
Looking forward
Keybased only authentication has a pretty good future in banking
industry. People are worried about their Internet banking passwords
stolen by spyware in their computers, so that they could suffer
financial damage. One solution would be: The bank sets up a keybased
only authentication system for their online banking. Then user can
create a DSA key pair with his/her own STRONG passphase either online
or preferably in the bank branches. Then the bank will create a Linux
live CD with the encrypted private key and send it to the user or offer
a dynamic link for the user to download the ISO image. Then s/he can
boot the computer with the Live CD and do online banking securely. This
will solve the spyware concerns and even if the password is stolen, the
villain will still need the physical copy of the Live CD with the
private key to tamper the system.
Conclusion
In this article, I have shown how to properly set up a passwordless
authentication in remote connection. It is a compromise between
security and convenience, however a compromise is a compromise. Users
need to fully evaluate the benefits and risk before taking the plunge.
Hopefully, this article will help minimize the number of insecure
convenient practice.
About the author:
Raymond Lai is a fourth year student at University of Toronto. He
received a full scholarship to study his Computer Science degree. He
had two work terms at IBM as a Webservice Tooling developer. His career
interest is in the consulting industry.
References
Gentoo Linux Keychain Guide
http://www.gentoo.org/doc/en/keychain-guide.xml
Openssh Key Management by Daniel Robbins
http://www-128.ibm.com/developerworks/linux/library/l-keyc.html
http://www-128.ibm.com/developerworks/linux/library/l-keyc2/
http://www-128.ibm.com/developerworks/linux/library/l-keyc3/
Openssh FAQ
http://www.openssh.com/faq.html
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
But having previously read the DeveloperWorks articles by Daniel Robbins and the Gentoo keychain guide, this article doesn’t really say anything new.
I suppose it serves some purpose as a summary of those articles, though.
Why use DSA over RSA?
The article is wrong. You should never forward your ssh agent to an untrusted machine. Anyone who has root access on the remote machine can access your agent. Very bad.
That third A is usually for accounting, the processes of logging actions (usually authenticated and authorized ones).