If you're running Linux, you should be aware that using telnet is a no-no. With the wide availability of network sniffers and automated password grabbing tools, telnet is simply not a secure way to work. Instead, use ssh and keep your passwords in keychain.
If you’re running Linux, you should be aware that using telnet is a no-no. With the wide availability of network sniffers and automated password grabbing tools, telnet is simply not a secure way to work.
The Secure Shell (ssh, http://www.openssh.com) is the de-facto replacement for telnet. ssh uses a passphrase and a strong public/private key encryption system to entirely avoid sending passwords (encrypted or not) across the network.
While ssh works well, you may quickly become frustrated having to type a long passphrase every time you login to a remote host. ssh-agent helps, but it doesn’t always work perfectly. However, if you login on the console of your workstation and run a series of commands like the following, you’ll be able to freely ssh to other hosts without ever having to re-type your passphrase.
$ exec ssh-agent bash
$ ssh-add ~/.ssh/identity
… enter your passphrase …
The sequence shown above works well, but it’s becoming less and less common for users to login on a console and manually start X. Instead, most Linux distributions start X automatically and present a graphical login window. While convenient, this makes it difficult to get ssh-agent running beforehand.
Even if you manage to configure things properly for X, what about running personal cron jobs? Without setting up a passphrase-less key or jumping through some other hoops, there’s still no easy way to do that.
keychain is the answer to all of these problems. The idea behind keychain is simple: each user has a single perennial agent process instead of a per-session or per-login process.
keychain is a cross-platform shell script that can be included from any of your bash (or other sh-compatible shell) startup files. When executed, keychain starts an ssh-agent process running (if need be) or hooks into an existing ssh-agent. Once an ssh-agent is running, keychain loads all of your private keys into the agent.
With keychain you type your passphrase once and both ssh from an interactive shell and ssh from cron jobs are a painless experience.
Putting keychainto Use
Figure One: Starting ssh-agent from bash
if [ -n "$PS1" ]; then
/usr/local/bin/ ~/.ssh/identity ~/.ssh/id_dsa
. ~/.ssh-agent-`uname -n`
/usr/local/bin/keychain –quiet ~/.ssh/identity ~/.ssh/id_dsa
. ~/.ssh-agent-`uname -n
After downloading keychain and putting the script in /usr/local/ bin, you’ll need to add a few entries to your shell’s startup files. For this example, we’ll use the $HOME/.bashrc file.
|Figure Two: keychain after spawning an xterm|
When running as a non-interactive shell, you need to make sure that keychain does not produce output (this keeps cron jobs “quiet”). On the other hand, during interactive use, you probably want some indication that keychain is working. Figure One shows a script snippet you can add to $HOME/ .bashrc to accomodate both requirements.Testing the $PS1 variable is a simple way to tell if a shell is interactive or not.
Notice that you can specify multiple keys for keychain to load. keychain saves the necessary information (the process ID of the agent and the path to its local socket) in a file and reading that file sets the necessary environment variables for ssh-agent.
Once your startup file has the right logic in it, launching a new xterm will look like Figure Two. The combination of ssh and keychain is faster, more flexible, and much more secure than telnet.
Have an idea for a project we should feature? Drop a note to email@example.com and let us know.
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62