SSH publickey auth

[Rick Stevens]

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.

You can also simply tunnel rsync through ssh, provided you've copied
the public key of the user running rsync on the local end into the
remote machine's "~/.ssh/authorized_keys" file.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-    Working with Linux is like wrestling with a worthy opponent.    -
-   Working with Windows is like picking on an annoyed child with a  -
-                            loaded handgun.                         -
----------------------------------------------------------------------