SPOT  Spot's Perspective On Technology
Colorful talk in black and white shades of grey.

site map

SSH - a quick start guide

2004-06-07 17:34:25

What you will need for this bite-sized example


dyne:bolic can coax lots of power out of modest hardware. But if you exceed the power of a single machine, there are usually options to use additional networked machines as a power supplement. If you find yourself wanting to control more than one machine from a single keyboard and monitor, or just to control a remotely located box, you'll be pleased to know that d:b has the tools to make it possible. In this article, we'll explore the first of two ways to operate d:b by remote control, the secure shell.


OpenSSH is a freely available secure shell system. At the surface, it offers a remote command line terminal capability, but once you get to know it, it has a lot to offer.

Server (the remote machine)

Although d:b has ssh built in, the daemon (server component) is not started automatically for security reasons. You might not want to open up your computer to remote control from anywhere in the world, so you have to make the decision to turn it on. Even if you want to share things, you probably don't want malicious tampering. If your machine is connected to the internet, here are some of the security questions you might want to consider before you start the ssh server:

You also should be aware that d:b comes with a fixed set of machine keys. This is not a big problem on a private network, but it becomes more significant on the open internet. Part of the ssh protocol makes sure you are really connecting to the machine you think you are, and warns if it notices anything wrong. Although the fixed keys are convenient at times, you should consider generating unique keys. To replace the keys, use these commands to overwrite the keys stored in your nest.

ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N ""
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""  

Start the Server

If you are ready to proceed, launch the ssh daemon by bringing up an xterm, and enter this command:

sshd &

This will start the sshd process in the background. Now other machines can connect to this one. Not only does ssh allow you to connect machines, but the traffic between them is encrypted, making it harder to intercept.

To make the launch of sshd a normal part of the normal startup, you can add it to the /etc/rc.local file of a nested d:b system. You can create or edit this file, using nedit, for example. From a command prompt, issue the command:

nedit /etc/rc.local

Add the following line to the file:

sshd &

Save the file, reboot and sshd should launch automatically.

Client (the local machine)

You can connect to your remote ssh server from a local client machine. From another d:b system, connect with:

ssh remote_name

Change remote_name to the IP address or name of the remote server machine. The remote machine will present you with a password prompt. Enter the password, and you have full remote terminal control.

If you need to use something other than a d:b system to connect, you might need to specify some more information. For example, from a typical Linux box, use a command:

ssh root@remote_name

This will connect as the root user, instead of your current login. From a windows system, you can use PuTTY to connect in much the same way.

Going Further

SSH is far more than a remote terminal. Once you can connect, you have the conduit for the other capabilities.

scp, secure copy, allows you to copy files to and from remote machines just as simply as using cp to copy a file locally. Files are encrypted in the transfer to prevent revealing the contents to anyone 'sniffing' on the network. You can specify local or remote files for source or targets in the form username@hostname:filespec. You can omit username if the same username is used on both systems, and you can omit hostname if the file refered to is on the local machine. For example, to copy /etc/rc.local from a remote system to your current directory, you could use a command like:

scp root@ .

Password-less logins can make working with multiple machines much smoother. The first step is to create a public/private key pair on the local machine with the command:

ssh-keygen -t dsa

Then repeat this procedure starting from your local machine for each remote d:b you want to access:

scp .ssh/id_dsa.pub root@remote-ip-address:.ssh/temp.pub
ssh remote-ip-address
cd .ssh
cat temp.pub >> authorized_keys
rm temp.pub

Note that you will be prompted for a password for the scp and ssh commands.

Port forwarding/secure tunnels can be used to add ssh encryption to almost any protocol. To set up a tunnel you create an alias port available on the local system that is linked to the real port on the real remote system. As an example, imagine you are using a wireless card on your computer, but have a wired machine available running sshd. You can encrypt the wireless portion of your communication with a POP3 mail server by tunneling the connections using ssh. Here is the command, assuming pop.mailserver.com is the real POP3 mail server, and is the wired machine running sshd.

ssh -L 1100:pop.mailserver.com:110

Now configure the mail client to connect to 'localhost' on port 1100, instead of directly to pop.mailserver.com on port 110. Now the POP3 traffic is encrypted during the trip through the air, making it much harder to eavesdrop on the password and messages flowing through the wireless card.

If ssh is available on the POP3 server, the command could be changed as follows to encrypt the entire chain.

ssh -L 1100:pop.mailserver.com:110 pop.mailserver.com

SSH is a powerful tool, and hopefully, this overview can enhance your d:b experience.

Now you've got power. Go create something wonderful!

Article 20 was last updated 2005-01-12 08:28:52

Some times you can have more fun with two (or more) dyne:bolic systems. In this bite-sized example we'll see how to control your d:b cluster through a remote command shell.