Keychain: why ssh, scp and others keep asking for the passphrase?

[NikosAlexandris]

I have set up keychain to use an id_rsa key. After latest world updates, I am asked for a passphrase repeatedly.  I got the following files/entries:

 

~/.ssh:
  authorized_keys
  config
  id_rsa

  id_rsa.pub
  known_hosts

  ..

 

/etc/ssh/sshd_config (perhaps irrelevant here, however, it is the same setup used in other system into which I ssh from the current one)

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UsePAM no
AllowTcpForwarding yes
X11Forwarding yes
AcceptEnv LANG LC_*

~/.gnupg:

  gpg-agent.conf

no-grab
default-cache-ttl 28800z
default-cache-ttl-ssh 28800z
max-cache-ttl 28800z
max-cache-ttl-ssh 28800z

  gpg.conf

# GnuPG config file created by KGpg
use-agent
default-key  9053534B693C4FB3
encrypt-to 9053534B693C4FB3

  private-keys-v1.d (directory)
  pubring.gpg
  random_seed
  secring.gpg
  trustdb.gpg

  ..

 

~/.keychain/
  ..

  tpx1c2g-sh
  tpx1c2g-sh-gpg

 

 

~/bash_profile

# GPG
#export GPG_TTY=`tty`
export GNUPGHOME=~/.gnupg
export GPGKEY=693C4FB3
eval `keychain --noask --eval --timeout 180 id_rsa`
source ~/.keychain/$HOSTNAME-sh
source ~/.keychain/$HOSTNAME-sh-gpg

I have added the Key, again, via ssh-add to be sure it is used.  I am still not sure why it stopped working, nor why it is not working now, even after checking that ssh-agent is (already) running.  What else should I check?

[NikosAlexandris]

For some reason, Kgpg, after the updates, did not keep to play nice along with keychain. Me thinks, at least.  The gpg-agent was not running actually. I don't know how this relates to ssh-add not being executed with the keychain call.  Anyhow, I unmerged Kgpg, and added

• the use-agent instruction in ~/.gnupg/gpg.conf
• the --agents ssh,gpg instruction to the keychain call in ~/.bash_profile in order to ensure both agents are launched. It seems that this fixed my problem.

Any best practice hints to work with both, keychain and kgpg? Or don't mix-em up?

[sputnik]

I can only suggest things to check, I don't know the answer.

I suggest changing

eval `keychain --noask --eval --timeout 180 id_rsa`

to

eval `/usr/bin/keychain --noask --eval --timeout 180 <path to your key>id_rsa.pub`

Mine works, I only use it for my github key:

eval `/usr/bin/keychain --eval $HOME/.ssh/github-ssh-key`

Also, more than once I have been bitten by file permissions.  These work here:

-rw-r--r-- 1 sputnik sputnik  2381 May 25 17:32 authorized_keys
-rw-r--r-- 1 sputnik sputnik  1720 Aug  3 15:07 config
-rw------- 1 sputnik sputnik  1679 Mar  7  2013 github-ssh-key
-rw-r--r-- 1 sputnik sputnik   399 Mar  7  2013 github-ssh-key.pub
-rw------- 1 sputnik sputnik  1679 Aug 21  2011 id_rsa
-rw-r--r-- 1 sputnik sputnik   395 Aug 21  2011 id_rsa.pub
-rw-r--r-- 1 sputnik sputnik 15278 Aug  3 20:06 known_hosts

I am NEVER asked for passphrase.  But when setting up new systems I often get that until I get the permissions right.

Good luck

[NikosAlexandris]

Thanks.  After trial and error, I think the problem, at least for ssh and scp, is that ssh-add is not persistent between reboots.  It was not the case one week ago, prior my latest world updates.

 

More info on the directory's permissions

700 drwx------   2 nik     9 Jul 26 15:52 .ssh

and of some of its content

700 drwx------  2 nik    9 Jul 26 15:52 .
755 drwxr-xr-x 56 nik  213 Aug  9 12:30 ..
600 -rw-------  1 nik  739 May 22 15:24 authorized_keys
644 -rw-r--r--  1 nik  122 Jul 11 18:33 config
600 -rw-------  1 nik 1.8K May 22 15:03 id_rsa
644 -rw-r--r--  1 nik  404 May 22 15:03 id_rsa.pub
644 -rw-r--r--  1 nik 1.4K Aug  4 20:59 known_hosts

I read here that the config file's permissions, should be set to 600. Which I have not.  And, likewise, the ones of authorized_keys. The directory's should be 700. Do we have any reference for ssh related file permissions?

[666threesixes666]

do you use gdm, kdm, lightdm, slim, or xdm??  when i have slim or lightdm load my session up .bash_profile is never sourced....  try putting those entries at the bottom of .bashrc if you're running those.