4. Running Secure Shell

4.1. How do I run SSH1?

4.1.1 ssh1

To use ssh1 to login to a computer with the same username:

$ ssh remote.example.org

To use ssh1 to login to a computer with a different username:

$ ssh -l username remote.example.org

To use ssh1 to securely send a command to a remote system:

$ ssh remote.example.org command

You can also define the cipher, turn on compression, define configuration file location, forwarding, and many other things. For more information, check out the ssh1 man page.

4.1.2 scp1

To use scp1 to copy a file to a remote system:

$ scp localdir/to/filelocation user@host:/dir/for/file

To use scp1 to copy a remote file to the local system:

$ scp user@host:/dir/for/file localdir/to/filelocation

To keep the file attributes of the source file from the source host, use -p:

$ scp -p user@host:/dir/for/file localdir/to/filelocation

For more information, check out the scp1 man page.

4.1.3 sshd1

To run the sshd1, just type it on the command line (usually as root, unless you're not running an ssh daemon as root).

# sshd

You can also define the host key files, the configuration files, the port, and the number of bits in the server key. See the man page for more details.

Note: To make sure the ssh daemon starts up whenever the system is rebooted, be sure to add it to your startup scripts. Do not try to start sshd from init.

4.1.4 ssh-agent1

To put public keys in memory, use ssh-agent. To run it by itself, it will run in the background and load your public key into memory:

$ ssh-agent

If you want to run it with an x-window (like xterm or dtterm), you can run it like so:

$ ssh-agent xterm &

Here's the man page.

4.1.5 ssh-add1

You can add other identities to ssh-agent using ssh-add. You can also list and delete identities with ssh-add (which should have been named ssh-identity manager :-).

To add an identity:

$ ssh-add identityfile

If used without any file defined, it will automatically add the default identification file. See the man page for more details.

4.2. How do I run SSH2?

4.2.1 ssh2

In ssh2, it uses similar syntax that ssh1 uses. To use ssh2 to login to a computer with the same username:

$ ssh2 remote.example.org

To use ssh2 to login to a computer with a different username:

$ ssh2 -l username remote.example.org

To use ssh2 to securely send a command to a remote system:

$ ssh2 remote.example.org command

You can play with more functionality on ssh2 than ssh1 like toggling the forwarding for the authentication agent and X traffic. Note that the options are different from ssh1. For more information, check out the ssh2 man page.

4.2.2 scp2

To use scp2 to copy a file to a remote system:

$ scp2 localdir/to/filelocation user@host:/dir/for/file

To use scp2 to copy a remote file to the local system:

$ scp2 user@host:/dir/for/file localdir/to/filelocation

To keep the file attributes of the source file from the source host, use -p:

$ scp2 -p user@host:/dir/for/file localdir/to/filelocation

Also note that scp2 has other functionality such as simulating a smv (secure move) command with the -u option. For more information, check out the scp2 man page.

4.2.3 sshd2

To run the sshd2, just type it on the command line (usually as root, unless you're not running an ssh daemon as root).

# sshd2

You can also define the host key files, the configuration files, the port, and other options (there is no server key in sshd2). See the man page for more details.

Note: To make sure the ssh daemon starts up whenever the system is rebooted, be sure to add it to your startup scripts. Do not try to start sshd from init.

4.2.4 ssh-agent2

To put public keys in memory for SSH2, use ssh-agent2. To run it by itself, it will run in the background and load your public key into memory:

$ ssh-agent2

If you want to run it with an x-window (like xterm or dtterm), you can run it like so:

$ ssh-agent2 xterm &

Here's the man page.

4.2.5 ssh-add2

You can add other identities to ssh-agent2 using ssh-add2. You can also list and delete identities with ssh-add2 (which should have been named ssh-identity2 manager :-).

To add an identity:

$ ssh-add2 identityfile

If used without any file defined, it will automatically add the default identification file. See the man page for more details.

4.2.6 sftp2

To transfer data using Secure Shell, use the sftp2 client. The syntax is:

$ sftp2 remoteserver user

The remote server should be running sshd2. See the man page for details.

4.3. How do I administer Secure Shell after I have the daemon running?

The central problem of administering ssh is the management of host keys. To allow a client to connect to a remote host with public key host authentication, the server needs to know the client's public key.

For SSH1, you can collect these automatically each night using either make-ssh-known-hosts.pl (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from ftp://ftp.ssh.com/pub/ssh/contrib/.

With these utilities, you can write scripts to verify public keys on a regular basis. When new machines are running ssh or people have changed public keys, you may want to contact the people in question directly, to make sure there were no man in the middle attacks (to which these utilities are vulnerable).

There will be more information later for managing host keys with SSH2.

4.4. How do I get hostbased authentication to work with SSH2?

For SSH2 release earlier than 2.2, please upgrade. It's so much easier to get hostbased authentication working with 2.2 than the earlier releases.

Most of this is from the FAQ that comes with the 2.2 distribution; however, I've made some more additions to this to make it easier.

Megatron is the Secure Shell server into which you're trying to connect. MegatronUser is the username on the Server into which you'd like to login. Optimus is the machine running a Secure Shell client. OptimusUser is the username on the Client that you'd like to allow to login to the megatron as the Server User.

Step 1.

Of course, install Secure Shell on the Megatron and Optimus machines. Do not forget to install the hostkey. If your installation did this, or you already have a copy of your /etc/ssh2/hostkey and /etc/ssh2/hostkey.pub, you do not need to do this:

# ssh-keygen2 -P /etc/ssh2/hostkey

Step 2 - SSH2

Copy the Optimus's /etc/ssh2/hostkey.pub file over to Megatron and name it to /etc/ssh2/knownhosts/optimus.ssh.com.ssh-dss.pub.

You'll want to use the long hostname (the fully qualified hostname). At least Linux can be a real pain if the system doesn't recognize the hostname as megatron.ssh.com and recognizes it as megatron. You can find this out while running sshd2 in verbose mode when trying to make connections.

To make sure that Secure Shell finds your complete domain name, not just the hostname, you can make sure you change the following line in the configuration file /etc/ssh2/ssh2_config:

DefaultDomain your.domain.here

This gives Megatron Optimus's public key so Megatron can verify Optimus's identity based on a public key signature. By contrast, rsh only uses the IP address for authentication.

Step 3.

On Megatron, create a file in the megatronUser's home directory named .shosts. The contents of this file should be the Optimus hostname, some tabs or spaces, and the optimusUser username.

Contents of ~/.shosts:

optimus.ssh.com optimusUser

Be sure to chown and chmod the .shosts file. The .shosts file must be owned by the remote user and should be mode 0400.

Step 4 - SSH2.

Check the file /etc/ssh2/sshd2_config and make sure that AllowedAuthentications contains the word hostbased For example, it may read:

AllowedAuthentications hostbased,passwd

It doesn't matter what's in there, just make sure that the hostbased variable is in the list somewhere. :)

If you had to modify the sshd2_config file, you'll have to HUP the sshd to make the change take effect.

# kill -HUP `cat /var/run/sshd2_22.pid`

Step 5.

On Optimus, you need to make sure that you have the AllowedAuthentications field in /etc/ssh2/ssh2_config set to included hostbased. If hostbased is not in there, this will not work. Step 6.

You should be all set.

On Optimus, log in as the ClientUser and try this:

$ ssh megatronUser@Server uptime

You should get back the results of uptime run on the remote server.

Note: The first time you run ssh to that particular server, you'll have to answer "yes" when asked if you want to connect to the server. This is because the local ssh doesn't yet have the remote server's Secure Shell public key. This will only happen the first time.

Troubleshooting

With SSH2, did you name the hostkey file appropriately? It should be /etc/ssh2/knownhosts/HOSTNAME.ssh-dss.pub and HOSTNAME may need to be the short hostname or the long hostname. If you're not using DNS, you'll need to make sure you're /etc/hosts file has the long host name (FQDN) listed:

myhost.example.com myhost

• Did you copy the hostkey properly?
• Did it get mangled when you copied it over?
• Check your spelling in the .shosts file.
• Make sure the .shosts file is owned by the megatronUser?
• Run the server with the -v flag (for ssh2). This is a great way to see if a hostkey file is missing, or if something is misconfigured.

4.5. How do I get user public key authentication to work with SSH2?

From the FAQ in the 2.2 distribution (I'll add more to this later):

In remote_host (this is the host where you want to connect to): Add the following line to file ~/.ssh2/authorization:

key id_dsa_1024_a.pub #or whatever is your pub keys name

In local_host (this is the host you want to connect from): Add the following line to ~/.ssh2/identification:

idkey id_dsa_1024_a #or whatever is your private keys name

You have to create your keypair in local_host, and transfer the .pub-part to remote_host to your $HOME/.ssh2/ there. Generate the keys using ssh-keygen (see 'man ssh-keygen' for details).

4.6. Can I run Secure Shell from inetd?

Yes, you can. No, you generally shouldn't. And boy, do I hate this question :)

When the Secure Shell daemon is started, it processes its configuration file and generates a cryptographic key. This can take several seconds, especially on a slow or busy server, and the startup time can be unacceptably long.

However, as Mike Friedman writes: "What many people (including me) do is run a 'backup' sshd at a non-standard port out of inetd, for use just when the standalone sshd has failed. This gives you a way to login to restart the regular sshd (or to investigate why it won't start!), but the latter would still be what most users normally connect to (at the standard port 22)."

If you decide to run Secure Shell via inetd:

To reduce the startup time for SSH1, you can reduce the size of the key that is generated with the -b flag (e.g. "-b 512"). The default keysize is 768 bits, and a keysize of 512 bits should be small enough to reduce the startup time. This is not recommended, however, as a 512-bit key is significantly easier to break than a larger key. The key size cannot be altered at runtime with SSH2; a new server key must be generated with ssh-keygen2.

When starting sshd from inetd, be sure to pass it the -i flag so it behaves properly.