>Can I connect to a machine using ssh without supplying a password (ie
>fully automated)? Just want to perform
>backup from cron.
Yes. Of course, you don't say what sshd/ssh server/clients you would or are
using. The setup varies, but I'll answer the best I can.
There are several possible options that would need to be in the servers config
file for this to work, depending on how you want to accomplish this. You can
either use PubKeyAuthentication (RSA/DSA) or .rhosts/.shosts. I don't
recommend the later since you only want it for backups and it would open the
entire account up. Therefore, I will describe the former here.
For PubkeyAuthentication you will need to make sure it is enabled in the
server's config file. The options are:
RSAAuthentication (O,S1)
DSAAuthentication (O,S2) **
O - OpenSSH 2.x.x sshd_config file
S1 - ssh.com sshd1_config file
S2 - ssh.com sshd2_config file
** - Also called PubKeyAuthentication in S2
For the client, you will need to decide whether you want to use a version 1 or
version 2 protocol. This will decide for you whether RSA or DSA is used for the
public key authentication. Since patent issues are not a problem for RSA
anymore in the US, it will probably come down to what client version is running
on the backup server, since it will start the connection. I recommend ssh2 or
protocol 2 for openssh if you have a choice. It is also best to try and use
related client and servers. If openssh is the backup clients sshd server, then
use openssh as the ssh client from the backup server. The same goes if the sshd
server is from ssh.com. If the server is ssh.com's sshd1, then use ssh1 on the
client. If it is sshd2, then use ssh2.
Once this is decided, you will need to create the public key that will be used.
The command to do this is ssh-keygen. It may be called ssh-keygen1 or
ssh-keygen2 if you are using the ssh.com programs. For the following I will use
ssh-keygen from the OpenSSH package since that is what I mainly use. I'll try
to point out differences with ssh.com below.
For the info, I will assume the following:
1) Using protocol version 2
2) Backup server machine is mach_BS
3) Machine to backup is mach_BC
4) mach_BS is the client ssh machine
5) mach_BC is the ssh server machine running sshd
Now go to mach_BS and run ssh-keygen as follows:
ssh-keygen -d -f ~/.ssh/id_dsa_backups -N "" (OpenSSH)
ssh-keygen2 -f ~/.ssh2/id_dsa_backups -N "" (ssh.com's ssh2)
This will generate the DSA key. It will create in the ssh dir id_dsa_backups
and id_dsa_backups.pub, which are the private and public portions of the key
respectfully. The keys will NOT have a passphrase. This just means anyone who
can get a copy of the private key will be able to authenticate with them. Don't
worry too much since we will only allow the key to run the backup commands. For
general logins it is good to use a passphrase and the associated ssh-agent
commands to protect yourself from this. (Using a passphrase would allow you to
protect your keys on a public system, so even root on that system couldn't use
them without the passphrase.)
Now for OpenSSH, take the contents of id_dsa_backups.pub and put them in the
authorized_keys2 file in the backup user's account (whether root or operator) on
mach_BC. It would be in the user's .ssh subdir. If there is already an
authorized_keys2 file, just add it as a new line. I usually use an existing ssh
connection to transfer the pub key, but it is not mandatory. You could also use
ftp since there is nothing sacred about the public portion of the key. Say you
save it in the .ssh subdir and called it id_dsa_backups.pub. You can add it to
authorized_keys2 by: cat id_dsa_backups.pub >> authorized_keys2. (You should
make sure the file has perms 400 or 600 for the owner.)
Now that you key has been added, the user with the private key id_dsa_backups
can now login as the backup user (whether root or operator) on mach_BC. Since
this may be too much, especially if the backup user is root on mach_BC, you
should confine what it can do. To do this, you will need to edit the
authorized_keys2 file. Once you have it opened in an editor, you should add the
following before the ssh-dss on the line you just added (which should be the
last one in the file).
from="mach_BS",command="/command/to/run/backups with args",
environment="MYVAR=\"special var\"",no-X11-forwarding,
no-agent-forwarding,no-port-forwarding
NOTE: This is one line with NO SPACES. The only spaces allowed are in double
quotes. If you need double quotes then escape as I did in the environment line.
Thus the first space should be just before the ssh-dss on the line you are
editting.
Now you can have a script on mach_BS start up backups on mach_BC w/o needing a
password. Now the only thing anyone can do if they get the private key is start
the backups and only if they connect from mach_BS. If they can do that, you
have more problems to worry about since you've been compromised... Of course
this assumes you have limitted access to the backup server machine (mach_BS).
You aren't running backups from a general time share machine are you? 8-)
For ssh.com's ssh2 you will need to leave the copied file, id_dsa_backups.pub
alone, but it should be put in the backup users .ssh2 dir and not .ssh. You
will then make an entry in .ssh2/authorization (or whatever your admin set the
file name to in sshd2_config), like this:
mach_BS:
Host FQDN_or_ip_Address
ForwardAgent no
ForwardX11 no
Key id_dsa_backups.pub
Command "/command/to/run/backups with args"
Not sure how to turn off port forwarding. Also, any environment variables can
be put in ~/.ssh2/environment which sshd2 will include in the environment of the
started command. The only downfall is all ssh logins get these environment
variables. You can also give a command when calling mach_BC from mach_BS.
While OpenSSH will just ignore this command, ssh2 will put the command in the
environment variable: SSH2_ORIGINAL_COMMAND which the running program can use
to set options, etc.
Finally, if you can't keep client/servers the same, when using DSA you will need
to convert ssh.com's DSA keys to ones OpenSSH can deal with. Sometimes you need
to do the opposite. On the machine that has OpenSSH you can use ssh-keygen to
convert one to the other. In short:
OpenSSH private key to SSH2 publc key:
ssh-keygen -x ~/.ssh/id_dsa_backups > ~/.ssh/id_dsa_backups.ssh2.pub
Now transfer this new file to the SSH2 machine and install in
authorization., etc.
SSH2 public DSA key to OpenSSH public key:
ssh-keygen -X ~/.ssh/id_dsa_backups.ssh2.pub > ~/.ssh/id_dsa_backups.pub
This would go in an OpenSSH authorized_keys2 file.
Well, this has been long, sorry about that. Any errors are mine, which I
appologize in advance for. As the only ssh.com sshd2 machine I have access to
is severely dated (v2.0.11), I can't guarentee all I have said about sshd2, but
what I did say should get you started with the version you have.
--Dave
PS. You should also verify that all files only have permissions for the owner
since most good sshd installations won't work with loose permissions on files
under .ssh or .ssh2.
--
David Knight French
Rotational Dynamics Company (RDC)
Voice: (858)279-4862
Email: [EMAIL PROTECTED]
URL: http://www.rotationaldynamics.com
