Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

From host B I can SSH various other hosts (C, D) without using any password as I put the public key in the correspondent authorized_keys files (in hosts C and D).

From host A I can SSH host B (via password authentication). However, once I am logged into host B I need to authenticate my key each time when I connect to C and D (even if in principle this should not be the case).

To summarize, if I connect directly to host B (e.g office) I do not need to type any password to connect to C or D. If I connect to A (e.g. home) and then from A I connect to B, once I am in B I need passwords to connect to D or C. I can partially solve the problem by adding the password to an ssh-agent (using ssh-add), but every time I open a new shell in B I need to do this again.

Update

Thanks to the useful comments, it turned out that the problem is the following. When I connect directly to B there is a keyring program running (in my specific case this is seahorse). Therefore the passwords of all encrypted private keys can be used automatically. When I connect to B from A this does not happen. For a mysterious reason even if I start a remote session (vnc / remmina) from A to B the program seahorse is not active in B and hence I have to manually insert the passwords over and over.

I installed keychain and the problem has been solved.

However, I am not sure if it is worth to encrypt a private key which is only used for SSH connection to a specific server. Is there any concrete security risk by not encrypting the private keys? In principle if one is able to access the private key he/she is also able to use the passwords stored in the keychain...so it seems that there might not be a big advantage in encrypting the private keys.

share|improve this question
2  
I suspect when you login to the GUI on B, you're starting up an SSH agent that holds your authentication keys. But when you SSH to B, you're not starting up this agent. –  Barmar Jun 25 at 20:59
    
yes, could be. A has Fedora 16 and I just ssh B, B has Fedora 19, could this explain something? However, keep in mind that when I log from A I never authenticated any key since I just provide the password of the user (which is not necessarily the same as the passphrase of the private key) –  Mannaggia Jun 25 at 21:12
1  
I don't think it has to do with the distro, it's how you login to B. Logging into the GUI runs your .xinitrc, which probably starts the SSH agent, and this automatically supplies your SSH keys; see the SSH_AUTH_SOCK environment variable. –  Barmar Jun 25 at 21:23
2  
Fedora is running Gnome Shell, right? I am pretty sure it also uses Gnome Keyring. Gnome Keyring will hold your SSH key passphrases and unlock automatically when you log in. You should look into ssh agent forwarding (ssh -A). This allows a chain of ssh connections to forward key challenges back to the original agent, removing the need for passwords or private keys on any intermediate machines. –  arnefm Jun 25 at 21:45
1  
@dg99: The problem, as pointed out, is that there is no ssh agent (or something similar running), when I directly connect to B there is a GUI environment with seahorse, when I connect to B (from A) via vnc seahorse somehow does not work, when I just ssh to B no ssh-agent is running. Since the private keys are password-protected I have to retype the pass over and over.... Is it worth to remove the pass from the private key? Is there any major security risk? –  Mannaggia Jun 27 at 8:47
show 2 more comments

1 Answer 1

up vote 1 down vote accepted

You solved part of your issue with the use of keychain to act as storage for your passphrases for your SSH keys. As to your other question:

However, I am not sure if it is worth to encrypt a private key which is only used for ssh connection to a specific server. Is there any concrete security risk by not encrypting the private keys? In principle if one is able to access the private key he/she is also able to use the passwords stored in the keychain...so it seems that there might not be a big advantage in encrypting the private keys

It's not that your private keys are left unencrypted, it's that they're not protected with a passphrase. Therefore anyone that can gain access to your home directory's .ssh directory can get control of your SSH keys without issue.

If you're comfortable with leaving these keys on a system that you have full control over then I see no issue with leaving them as passphrase-less. I would also recommend generating a different set of keys that you can leave on secondary systems such as this, or even a unique set just for this server, so that you can completely abandon it without much issue if you ever discover its been compromised.

As to using keychain to manage your keys, I see not much to be gained with having passphrases on SSH keys if you're using keychain to manage them, except that keychain will only store them when you use them. If you don't use the keys often, and are diligent about cleaning up keychain when you're finished, then a passphrase would be an advantage, but IMO, it's a small one.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.