Alexander Dalloz wrote:
Am Fr, den 08.07.2005 schrieb Michael Yep um 22:56:
Ok I'm not sure what Top Posting means, but I guess I'll try down here.
Right :)
http://en.wikipedia.org/wiki/Top-posting
http://www.fedoraproject.org/wiki/MailingListRules
It helps to better follow a discussion as it allows to comment inline,
just like you would do if you have a paper in hands and do annotations.
You wouldn't note them at the end of the article to later have the
difficulty to remember at which part of the article you refer to.
taken from this website
http://www.penguinsecurity.net/pensec/modules.php?name=News&file=article&sid=256
The goal of using Identity/Pubkey authentication is to remove the need
for static passwords. Instead of providing a password, which could be
captured by a keystroke logger or witnessed as you type it, you have a
key pair on your disk that you use to authenticate. Your account on the
SSH server has a list of Identities/Pubkeys that it trusts, and if you
can prove you have the public and private key then you are granted
access without supplying a password.
That is correct.
Some of the nice features of this form of authentication are:
* No one can shoulder-surf your password and log in to your accounts
- they'd need both your Identity passphrase and the private key
from your machine.
You see here the mention of the "passphrase"? Sure you do.
* The server administrator could disable password authentication
entirely, to prevent password guessing attacks.
That improves security.
* You can use the |ssh-agent| and SSH agent forwarding to have your
authentication credentials 'follow' you.
That's what I said: use ssh-agent.
* You can place restrictions on Identities/Pubkeys, for example
forbidding port forwards, forcing predetermined commands,
regardless of what the user wanted to run, and more.
Another option to improve security.
In this week's article we'll show how you create keys and configure your
account to allow them to log in. In later articles we'll go into some of
the other capabilities of SSH identities.
Am I misunderstanding this article? I would like to run rsync jobs via
cron, and not require a password
I think you are understanding the article. I just want to point out:
password != passphrase. While a password is typically something like
"Zv86&rq_f$v", a passphrase means typically a senseless sentence. The
passphrase protects the pubkey, so that if someone gets the public key
into his hands he can not simply use it without knowing the nifty
sentence.
Now about your rsync cronjob "problem". As cron has a very limited
environment it will not make use of ssh-agent. To avoid the situation to
use a passphrase-less pubkey auth you should use (that is my
recommendation) keychain. It is a great tool, a wrapper script above
ssh-agent and makes it possible to run cronjobs with ssh pubkey
authentication using passphrase protected keys.
http://www.gentoo.org/proj/en/keychain/index.xml
Ready to install & use RPM:
http://dev.gentoo.org/~agriffis/keychain/
I myself have following code in the ~/.bashrc of my backup user (and of
users where I make use of it too):
# start keychain and point it to the private keys
# that we'd like it to cache
KEY="`ls ${HOME}/.ssh/*dsa`"
/usr/bin/keychain ${KEY}
if [ -f ${HOME}/.keychain/${HOSTNAME}-sh ]; then
. ${HOME}/.keychain/${HOSTNAME}-sh > /dev/null
else
echo "there is a problem with keychain"
fi
You just have to login as the keychain using user to make the credential
available for cron tasks.
A user crontab looks like this:
15 4,12,20 * * * source /home/backup/.keychain/serendipity.dogma.lan-sh
/dev/null && /home/backup/rdiff-script.blacky.pl
[ that is a single line ]
I am not using rsync for backup purposes, but rdiff-backup which is
available through Fedora Extras. Gavin Henry once wrote a nice article
about using it:
http://fedoranews.org/ghenry/rdiff/
I use it in reverse order, means backup running on client host
connecting the server which holds the data to save.
Michael Yep
Alexander
Ok, just to make sure I understand, basically PublicKey auth still uses
a password,
but it is better because you need 2 things, what you have (the
certificate), and what you know (the password)
--
Michael Yep
Development / Technical Operations
RemoteLink, Inc.
(630) 983-0072 x164
