Re: SSH publickey auth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux