[PLUG] ssh options

Tyler F. Creelan creelan at engr.orst.edu
Thu Aug 1 07:02:05 UTC 2002


> How do I generate a null key pair and will that always be used

To generate a key pair, use 'ssh-keygen'.

Attached is an ssh tutorial I wrote a while back on getting set up with
OpenSSH; it should be readable for a new user. PLUG admins: this can be
added to the PLUG Howto archive if it seems useful.

For remote ssh commands, disabling host key checking and x forwarding
might speed up execution, as might use of a smallar key. By default
ssh-keygen gives you 1024 bits; this will give you a smallar key:

ssh-keygen -b 512

In the way of an example, this shows what a user's up to on a host:

ssh -o StrictHostKeyChecking=no -1 -x eel.engr.orst.edu w -h creelan


Tyler


On Wed, 31 Jul 2002, Josh Orchard wrote:

> How do I generate a null key pair and will that always be used when I
> normally ssh into the remote box?
> I also found a way to do it by using expect.
>
> for those curious here is the script I found:
>
> #!/usr/bin/expect -f
> log_user 0
> spawn /usr/bin/rsync /etc -ar --delete --copy-unsafe-links -l -t -e ssh
> user at remote.site.com:./expect "password: "
> send "secret\n"
> log_user 1
> interact
>
>
> Just not sure I like the password in plain text in a file.
>
> > On Wed, 2002-07-31 at 22:48, Josh Orchard wrote:
> >> I would like to setup a script to ssh into a remote box and do some
> >> rsync'ing but I can't find an option in the ssh command line to pass
> >> in the password.  Is there such a thing?  If not, suggestions for the
> >> script to input the password after the prompt comes back?
> >> command I'm running is:
> >>
> >> rsync --archive --verbose -e ssh me at remotemachine:/stuff/to/backup
> >> /local/backup
> >> Thanks,
> >>
> >> Josh
> >>
> > You can pass a command line via ssh like this:
> > ssh -l user machine command
> > For some reason this does not work on commercial SSH on HP-UX.
> >
> > To avoid the prompt, you can generate a keypair with a null passphrase,
> > but be sure you keep your private key private,
> >
> > Doug
> >
> >
> > _______________________________________________
> > PLUG mailing list
> > PLUG at lists.pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
>
>
>
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
-------------- next part --------------
The Least you need to know about SSH (OpenSSH 3, protocols 1.5/2)
SSH Tutorial, Tyler Creelan, tyler.creelan at orst.edu
-----------

With telnet, rsh, ftp, and rlogin, network packets are sent in the
clear; your password is broadcast publicly to the network. An observer
may store your packets and obtain your password. Additionally, under
these protocols, the host you communicate with may not be the host you
think it is. A router between you and your destination may pose as the
host you are trying to reach.

The Secure SHell client 'ssh' provides:
1) Integrity (machine is actually who you think it is)
2) Authentication (more choices as to how you can be verified)
3) Confidentiality (information exchanged is kept private.)

-- Create public/private key pair(s) --

The first step in using 'ssh' is to create your public/private key pair:

ssh-keygen -t rsa -b 512

This will create a 512 bit ssh2 key of type rsa. You can also choose
'dsa' as your cipher; however dsa verification is slower and no more
secure; You could also use 1024 or 2048 as your key size, this will
make your public key harder to factor but slows you down while logging in.

Save the keys to the default location; hiding your keys in an obscure
directory won't make them more secure. You may decide to add a
passphrase to your key later; for now leave it blank. Copy your
fingerprint and save it in a file, store this file somewhere in your
.ssh directory for later.

Now, in '~/.ssh', you have two keys, 'id_rsa' and 'id_rsa.pub'. Don't
ever do anything with the 'id_rsa' private key; don't copy, move, or
view it; keep it private. You can do anything with the public key, but
you should avoid modifying its contents.

-- Authorizing keys --

The first basic application of your keys is to avoid typing a password
when hopping between machines on the same nfs server, for example,
stak. This is achieved by authenticating yourself:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

the new file 'authorized_keys' will store all public keys. Now
you should be able to hop from eel to flop without typing your
password; if you are still being prompted for your password, you may
need to change some configuration settings, described later.

On your home unix box, do the same thing; generate a key, store
it. Now you should have two key pairs, one for home and one for your
stak account. Ftp your stak id_rsa.pub over to your home box:

scp username at flop.engr.orst.edu:.ssh/id_rsa.pub id_rsa.pub.flop

Now add this to your authorized_keys file at home:

cat id_rsa.pub.flop >> ~/.ssh/authorized_keys

Note; you may want to make a shell function for this; ie:

addkey() { # Authorize a public key
        if ["$1"]; then
                cp -f --preserve ~/.ssh/authorized_keys ~/.ssh/authorized_keys.backup
                echo "Adding key "$1" to .ssh/authorized_keys"
                cat $1 >> ~/.ssh/authorized_keys
        else
                echo "Usage: addkey <publickey file>"
        fi
}

Now repeat these steps only for your stak account:

scp username at your.home.box:.ssh/id_rsa.pub id_rsa.pub.home
addkey id_rsa.pub.home 

Now you should be able to ssh from home to school, and back and forth
without typing any passwords. If this doesn't work, it could be
because of your ssh configuration, or because of an OpenSSH
incompatibilty problem, which is not uncommon but can usually be resolved.

Applications such as scp and sftp use the ssh client also; you should
also be able to scp files back and forth without providing a password
either.

-- Configuration and Options --

Default ssh configuration options are stored in the file: 

/etc/ssh/ssh_config.

Copy this to create your personal default configuration file:

cp /etc/ssh/ssh_config ~/.ssh/config

To learn what these options mean, use 'info ssh'. There's a wealth of
options not present in the default config file. Remember that you can
also specify these as command-line options, to both ssh and programs
like scp. This can also be useful in scripts when using ssh to execute
commands remotely, ie;

ssh -o StrictHostKeyChecking=no -1 -x eel.engr.orst.edu w -h creelan

will remotely query eel to see what user 'creelan' is up to, without
strictly verifying the host. In this circumstance, if the machine we
connected to was not eel, and we used public key authentication, then
the impostor would not gain any useful information from our
exchange. If passwords were being used, this exchange would be
detrimental, however.

-- Protocol 1 vs. 2 --

At some point you will probably also have to create an SSH v.1 key,
for backward compatibility with machines that don't support v.2. This
means that sometimes ssh will use your v.2 key and sometimes your
v.1 key, by default it will check for both; these options are: 

PreferredAuthentications publickey,hostbased,password,keyboard-interactive
Protocol 2,1    
RSAAuthentication yes

Sometimes this doesn't work properly; or you may need to stipulate the
version when running ssh, so I keep some hosts aliased:

# ---- SSH aliases ------
alias ssh="ssh -x "
alias ucs="ssh -2 creelant ucs.orst.edu"
alias eel="ssh -2 eel.engr.orst.edu"
alias trek="ssh -2 trek.cs.orst.edu"
alias kestrel="ssh -1 12.224.122.103"
alias goshawk="ssh -1 192.168.1.102"

-- X-forwarding --

ssh also can set up Xauthority data and X-forwarding, this can be convenient:

ssh -X eel.engr.orst.edu

will establish a link with X-forwarding; now ssh will set your
$DISPLAY to something like: localhost:12.0

Unfortunately, sometimes X applications (xemacs for example) are
compiled using the local libraries and this $DISPLAY doesn't work;
sometimes this can corrected by changing $DISPLAY to eel:12.0 instead
of localhost:12.0, for example.

Generally though setting up X forwarding is additional overhead;
disable it by default and invoke on the command line as needed.

-- More ssh notes -- 
Try using the verbose setting -v, -vv, or -vvv if something isn't
going right.

PuTTy - Some really good ssh utilities for Microsoft OSes:
http://www.chiark.greenend.org.uk/~sgtatham/putty/

-- Document notes --
A lot of information in here is probably incorrect or uncorroborated.
Covered by the FDL (GNU Free Documentation License)


More information about the PLUG mailing list