 |  |  |
 |
How the Shaman Agent worksA normal SSH interaction is based on a password that is sent to the remote server, which verifies it. SSH protects this exchange by encrypting all traffic to and from the remote server, and by establishing the identity of the remote server before asking for the password. When logging in with a password, the process looks like: 
With a token, all these protections stay in place, but the password exchange between SSH and the remote server is replaced with challenge/response; this exchange is founded in strong cryptography. This in turn avoids many password-related problems. Once properly setup, the remote system sends a cryptographic challenge to the client, based on a suitable SSH Key. Only the token is capable of responding properly to that challenge, because only the token holds the secret key that is needed to construct the response. 
The token is protected by a PIN to avoid that token theft would make its SSH Keys vulnerable. A background program called the Shaman Agent links OpenSSH, PuTTY or WinSCP to the token; this agent requests the PIN when needed, notably when the token was recently plugged in. After the PIN is sent to the token, the agent wipes it is automatically logged out from the token when the token is unplugged. Therefore, when the token is plugged back in, the agent will ask for the PIN once more. The access privileges of the Agent are not available to other programs, although they could independently login to the token. The normal OpenSSH commands already know to look for the Shaman Agent, and the distribution packages install code to start it automatically. All that fresh users must do to get started is create an SSH Key on the token and instruct remote servers to accept that key as a proof of client authenticity. This setup can be done with the graphical Shaman Setup utility. Why use a token with SSH?The OpenSSH system for remote access to files, shells and generic tunnels is widely used to make network snooping ineffective, but it does not compensate for keyboard loggers, password reminders under keyboards, short and fixed passwords, and similar inherent problems. To solve that as well, more than just the password should be used to gain access. It is possible to use public key cryptography to overcome these last issues as well. Unfortunately, this introduces another nightmare, namely that of storing private SSH Keys on a system that is as weakly protected as a desktop. At this point, cryptographic tokens can be used to keep the private SSH Keys external to the desktop, securely encapsulated inside a token. Cryptographic tokens come in the shape of smart cards and USB tokens, and they are addressed over the standard interface known as Cryptoki or PKCS 11, over which private keys can be used without extracting them off the token. The Shaman links Cryptoki and OpenSSH, and it pulls in PAM to implement Single Sign-on. When the Shaman is installed on a system, a wealth of OpenSSH-based applications automagically become token-enabled. Advanced use: Avoiding lockoutSecurity applications like these provide such strong protection that loss of a token locks out respectable users. If this happens to end users, an administrator is usually able to revoke the rights related to their missing token from server accounts, but what if an administrator looses a token or, equivalently, forgets the token PIN? SSH can solve this elegantly -- it supports multiple independent keys that can access a single account. So if needed, multiple tokens can be used to access the same account. In situations with multiple administrators with equal rights, each can have a token to access the administrator account on server systems. When only one administrator is active in an administrative domain, it is possible to simulate the situation with multiple administrators by using multiple tokens, each securely stored in a differernt place, and each enabled on all the servers. It is helpful if other people are informed about these tokens, not just the administrator. A good design guideline is that there should be no single point of failure. Posted on Mon, 28 Jun 2004, 12:00. |
spin-off |  |