different SSH/keychain behavior on Fedora Core 4?

From: Cameron Mura (cmura_at_ucsd.edu)
Date: 09/07/05

  • Next message: shaggyshags_at_gmail.com: "Re: NEW INTEREST"
    Date: Tue, 06 Sep 2005 18:31:42 -0700
    To: fedora-list@redhat.com
    
    

    Hi,

    I'm wondering if anyone's seen different SSH and keychain behavior on
    Fedora Core 4 versus its predecessors (FC3, in particular) ? ("keychain"
    is the Gentoo ssh-agent wrapper... allows a user to make a single
    passphrase entry per machine reboot, not per login.)

    The reason I'm asking is that I used to be able to set-up keychain and
    have it run smoothly (i.e., password-less and passphrase-less logins)
    from my FC3 machine at home to various boxes at work (running CentOS,
    FC3, RH9, etc.)... To streamline things, I have buttons configured on
    the KDE console bar of my home desktop such that they're mapped to
    commands like "ssh -Y -l me where.ever.com <http://where.ever.com>"
    ("Run in terminal" option checked, of course)... so I would basically
    have 1-click solutions to drop me into shells on various work machines.
    But since upgrading the home machine to FC4 this trick no longer works
    and the terminal which is opened up on the remote machine still asks me
    for the passphrase for the local RSA private key... interestingly, I'm
    not prompted for a passphrase if I manually "ssh -Y -l me where.ever.com
    <http://where.ever.com>" from a terminal on my home machine to the
    remote work machine...

    I realize that this may be more of an SSH question than an actual Fedora
    issue, but still I'm wondering if anyone's seen any similar behavior,
    are aware of any changes in default SSH behavior/configuration between
    FC3 and FC4, or otherwise have any clue about this behavior?

    Thanks for any advice!,
    Cameron

    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: shaggyshags_at_gmail.com: "Re: NEW INTEREST"

    Relevant Pages

    • RE: Controlling ssh from an external program
      ... passphrase could be discovered and the private key would fall into dangerous ... NB the SSH environment strings need to be included in this mixture! ... character as the final character could signify accept from a file. ... Controlling ssh from an external program ...
      (SSH)
    • Re: More on learning "Public Key Authentication"
      ... > computers in my local network are configured that way. ... > A long passphrase is a good idea but for other reasons. ... I _think_ a passphrase is used merely to verify that a public SSH ... _public_ keys between computers, so I do not even use a public SSH ...
      (comp.sys.mac.system)
    • Re: Defering passphrase entry with ssh-add
      ... I'm not aware of any technical reason why ssh-add couldn't defer requesting a password until its required. ... Yes which is why you only check/run it when ssh is used. ... until it determined it needed your passphrase. ... Again, ssh-agent works for me across all terminals as well as just in X, it's ssh-add you are talking about here which is ...
      (SSH)
    • Re: Giving shutdown rights to somebody
      ... > Succinct is good. ... > account, but the ssh subsequently asks for the pass*phrase*, ... > between boxes, and other blank-passphrase keys for automated purposes ... > session aware of the passphrase so subsequent ssh sessions to other ...
      (comp.os.linux.security)
    • Re: Passphraseless SSH login and cron
      ... order to do SSH logins without having to type a passphrase. ... henceforth in this session I can do passphraseless SSH logins. ... so that the script to be run by cron can execute ... agent, ...
      (comp.security.ssh)