Re: SSH publickey auth

From: Alexander Dalloz (
Date: 07/08/05

  • Next message: Alexandre Oliva: "Re: (FC4 PPC) Mac Mini Firewire install"
    To: For users of Fedora Core releases <>
    Date: Fri, 08 Jul 2005 23:29:34 +0200

    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 :)

    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
    > 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

    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.

    Ready to install & use RPM:

    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
            echo "there is a problem with keychain"

    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/

    [ 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:

    I use it in reverse order, means backup running on client host
    connecting the server which holds the data to save.

    > Michael Yep


    Alexander Dalloz | Enger, Germany | GPG 0xB366A773
    legal statement:
    Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp 
    Serendipity 23:27:35 up 13 days, 6:19, load average: 0.25, 0.16, 0.17 


    fedora-list mailing list
    To unsubscribe:

  • Next message: Alexandre Oliva: "Re: (FC4 PPC) Mac Mini Firewire install"

    Relevant Pages

    • Re: Question about public key authentication
      ... bt> accepted when I try to ssh from a to c, and I have to do password ... bt> authentication? ... I doubt that your "passphrase is not accepted," since the passphrase is ... used to decrypt your private key, which is the same in both cases. ...
    • Re: sshd wont start with passphrase protected private key
      ... James Strickland wrote: ... authentication fine as long as there is no passphrase on the private key. ...
    • sshd wont start with passphrase protected private key
      ... authentication fine as long as there is no passphrase on the private key. ... sshd fails to load with the new private key. ...
    • SecureID in place of passphrase
      ... Do you know whether it's possible to use SecureID to ... authentication to the server can be by SecureID ... instead of via private key (and that would be a more ... authentication rather than a passphrase to access the ...
    • Re: Feature request
      ... >>case why can that not be send across on request in the handshake phase? ... > change his private key in any way, he could no longer be authenticated ... the passphrase is ... but the passphrase belongs to the private keyfile. ...