FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 01-15-2011, 03:22 PM
bluethundr
 
Default keychain problem

hello centos.. I am having a very annoying problem on my network right
now. it looks like every time I try to add my ssh key to keychain I
have to issue a command just to get my ssh subsystem communicating
with the ssh-agent:

I have this line in my .bashrc file

$(keychain --eval --quick --quiet private_key1 private_key2 private_key3)

If I try to perform ssh-add I get the message:

[bluethundr@VIRTCENT01:~]#ssh-add
Could not open a connection to your authentication agent.

So then I try to execute ssh-agent:


bluethundr@amanda:~]#exec ssh-agent bash
* Warning: can't find private_key1; skipping
* Warning: can't find private_key2; skipping
* Warning: can't find private_key3; skipping
bash: SSH_AUTH_SOCK=/tmp/ssh-cdJlgq6077/agent.6077;: No such file or directory

Then I can add it.

[bluethundr@amanda:~]#ssh-add
Enter passphrase for /home/bluethundr/.ssh/id_rsa:
Identity added: /home/bluethundr/.ssh/id_rsa (/home/bluethundr/.ssh/id_rsa)

But if I ssh away from this box and then ssh back INTO it.. and then
sometime later have to ssh away again it asks me for my ssh key's
passphrase. See what I mean by 'annoying problem'?

Thanks in advance for your help!



--
GPG me!!

gpg --keyserver pgp.mit.edu --recv-keys F186197B
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-15-2011, 09:56 PM
Cameron Kerr
 
Default keychain problem

On 16/01/2011, at 5:22 AM, bluethundr wrote:

> hello centos.. I am having a very annoying problem on my network right
> now. it looks like every time I try to add my ssh key to keychain I
> have to issue a command just to get my ssh subsystem communicating
> with the ssh-agent:
>
> I have this line in my .bashrc file
>
> $(keychain --eval --quick --quiet private_key1 private_key2 private_key3)

Should not this go into your ~/.bash_profile?

(disclaimer: I've not used the 'keychain' program before)

> If I try to perform ssh-add I get the message:
>
> [bluethundr@VIRTCENT01:~]#ssh-add
> Could not open a connection to your authentication agent.
>
> So then I try to execute ssh-agent:
>
>
> bluethundr@amanda:~]#exec ssh-agent bash
> * Warning: can't find private_key1; skipping
> * Warning: can't find private_key2; skipping
> * Warning: can't find private_key3; skipping
> bash: SSH_AUTH_SOCK=/tmp/ssh-cdJlgq6077/agent.6077;: No such file or directory
>

if SSH_AUTH_SOCK is not present, or ssh-agent is not running, then you would need to figure out where it should be started. (In your case, if it is not running, try removing the --quiet option to keychain or adding verbosity to see if it is or isn't starting the agent for you.) Typically, you only want this enabled on your workstation, and use SSH Agent Forwarding to access other machines recursively.

The agent should typically be started for you on your workstation (you don't say if you're using a graphical environment on your workstation: most would start ssh-agent for you when you log in.)

(Note that you shouldn't start ssh-agent in your ~/.bashrc or similar, you can easily get infinitely recursive behaviour)

> Then I can add it.
>
> [bluethundr@amanda:~]#ssh-add
> Enter passphrase for /home/bluethundr/.ssh/id_rsa:
> Identity added: /home/bluethundr/.ssh/id_rsa (/home/bluethundr/.ssh/id_rsa)
>
> But if I ssh away from this box and then ssh back INTO it.. and then
> sometime later have to ssh away again it asks me for my ssh key's
> passphrase. See what I mean by 'annoying problem'?
>

You want to use the SSH Agent Forwarding feature (ssh -A ...).

If you don't, then you would have to 'exec ssh-agent bash' followed by 'ssh-add ...' prior to starting a recursive session.

Note that Agent Forwarding effectively means that you only need a keypair on your workstation, as if you log in from Workstation -> Server1 -> Server2, then Server2 will end up querying the key not from Server1, but from Workstation. For this to work, Agent Forwarding needs to be enabled on Server1 (which is, I think, the default behaviour, but I'm fairly new to Centos so you may like to check that).

> Thanks in advance for your help!
>
>
>
> --
> GPG me!!
>
> gpg --keyserver pgp.mit.edu --recv-keys F186197B
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-15-2011, 10:15 PM
Cameron Kerr
 
Default keychain problem

On 16/01/2011, at 11:56 AM, Cameron Kerr wrote:
On 16/01/2011, at 5:22 AM, bluethundr wrote:

I have this line in my .bashrc file

$(keychain --eval --quick --quiet private_key1 private_key2 private_key3)

Should not this go into your ~/.bash_profile?

(disclaimer: I've not used the 'keychain' program before)


According to the docs for keychain, it should look something more like the following:
eval `keychain --eval --agents ssh id_dsa`
The 'eval' at the start is probably more important than you think... I noted myself that the following are quite different in a bash script I was working on:
"$@"
eval "$@"
(only the latter works, the former ended up not doing anything in a #!/bin/bash script)
https://github.com/funtoo/keychain *and http://www.funtoo.org/en/security/keychain/intro/ *for more information regarding keychain. You might also like adding * *|| exit 1 * or similar to the 'eval' call, for debugging, as shown in the docs.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-16-2011, 12:12 AM
bluethundr
 
Default keychain problem

Hello and thanks for your reply!

Well I took your advice and removed that keychain scriptlet from
.bashrc and put it into .bash_profile. Not sure what the functional
difference between the two would be. Perhaps you would care to
elaborate? I know that rc stands for "resource configuration" but
other than that I don't know why this statement would be more
appropriate in the .bash_profile. However you do seem well versed in
this and I hope you don't mind answering this question.

So this is what I put into my .bash_profile

$(keychain --eval --agents ssh id_rsa)

and here is an ssh session from after when I did this:

[bluethundr@LCENT01:~]#bash
[bluethundr@LCENT01:~]#ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-cBwwRR5466/agent.5466; export SSH_AUTH_SOCK;
SSH_AGENT_PID=5467; export SSH_AGENT_PID;
echo Agent pid 5467;
[bluethundr@LCENT01:~]#ssh-add
Could not open a connection to your authentication agent.
[bluethundr@LCENT01:~]#exec ssh-agent bash
[bluethundr@LCENT01:~]#ssh-add
Enter passphrase for /home/bluethundr/.ssh/id_rsa:
Identity added: /home/bluethundr/.ssh/id_rsa (/home/bluethundr/.ssh/id_rsa)

So this behavior did not change. I still have to enter my passphrase
again after I put this into my .bash_profile


[bluethundr@LCENT01:~]#ssh virt1
Last login: Sat Jan 15 11:51:08 2011 from 192.168.1.42
################################################## #######
# SUMMITNJHOME.COM #
# TITLE: LB1 BOX #
# HOST: VIRTCENT01 #
# LOCATION: SUMMIT BASEMENT #
################################################## #######

* keychain 2.7.0 ~ http://www.funtoo.org
* Found existing ssh-agent: 27556
* Adding 1 ssh key(s): /home/bluethundr/.ssh/id_rsa
Enter passphrase for /home/bluethundr/.ssh/id_rsa:
Bad passphrase, try again for /home/bluethundr/.ssh/id_rsa:
* ssh-add: Identities added: /home/bluethundr/.ssh/id_rsa

This is new.. now I get prompted for the passphrase AGAIN once I reach
the server I am ssh'ing in to.

I should point out that I am operating from a shared NFS mounted home directory.


-bash: SSH_AUTH_SOCK=/tmp/ssh-Tqzln27555/agent.27555;: No such file or directory
[bluethundr@VIRTCENT01:~]#ssh virt2
ssh: connect to host virt2 port 22: No route to host
[bluethundr@VIRTCENT01:~]#ssh sum2
Enter passphrase for key '/home/bluethundr/.ssh/id_rsa':
Enter passphrase for key '/home/bluethundr/.ssh/id_rsa':
Last login: Sat Jan 15 10:54:51 2011 from 192.168.1.50
################################################## #######
# SUMMITNJHOME.COM #
# TITLE: SUM2 BOX #
# HOST: LCENT02 #
# LOCATION: SUMMIT BASEMENT #
################################################## #######

* keychain 2.7.0 ~ http://www.funtoo.org
* Starting ssh-agent...
* Adding 1 ssh key(s): /home/bluethundr/.ssh/id_rsa
Enter passphrase for /home/bluethundr/.ssh/id_rsa:
* ssh-add: Identities added: /home/bluethundr/.ssh/id_rsa

-bash: SSH_AUTH_SOCK=/tmp/ssh-JGlcJj6111/agent.6111;: No such file or directory

Well it seems that I am still trying to figure this situation out. If
you have any further insight into what may be going on here I would
certainly appreciate your input.


On Sat, Jan 15, 2011 at 6:15 PM, Cameron Kerr <cameron@humbledown.org> wrote:
>
> On 16/01/2011, at 11:56 AM, Cameron Kerr wrote:
>
> On 16/01/2011, at 5:22 AM, bluethundr wrote:
>
> I have this line in my .bashrc file
>
> $(keychain --eval --quick --quiet private_key1 private_key2 private_key3)
>
> Should not this go into your ~/.bash_profile?
>
> (disclaimer: I've not used the 'keychain' program before)
>
>
> According to the docs for keychain, it should look something more like the
> following:
> eval `keychain --eval --agents ssh id_dsa`
> The 'eval' at the start is probably more important than you think... I noted
> myself that the following are quite different in a bash script I was working
> on:
> "$@"
> eval "$@"
> (only the latter works, the former ended up not doing anything in a
> #!/bin/bash script)
> https://github.com/funtoo/keychain *and
> http://www.funtoo.org/en/security/keychain/intro/ *for more information
> regarding keychain. You might also like adding * *|| exit 1 * or similar to
> the 'eval' call, for debugging, as shown in the docs.
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
>



--
GPG me!!

gpg --keyserver pgp.mit.edu --recv-keys F186197B
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-16-2011, 04:22 AM
Cameron Kerr
 
Default keychain problem

On 16/01/2011, at 2:12 PM, bluethundr wrote:

> Hello and thanks for your reply!
>
> Well I took your advice and removed that keychain scriptlet from
> .bashrc and put it into .bash_profile. Not sure what the functional
> difference between the two would be. Perhaps you would care to
> elaborate? I know that rc stands for "resource configuration" but
> other than that I don't know why this statement would be more
> appropriate in the .bash_profile. However you do seem well versed in
> this and I hope you don't mind answering this question.
>

.bash_profile is executed for login shells (followed by .bashrc).

.bashrc is executed for non-login shells as well.

.bash_profile should therefore be used for session setup tasks.

> So this is what I put into my .bash_profile
>
> $(keychain --eval --agents ssh id_rsa)
>
> and here is an ssh session from after when I did this:
>
> [bluethundr@LCENT01:~]#bash
> [bluethundr@LCENT01:~]#ssh-agent
> SSH_AUTH_SOCK=/tmp/ssh-cBwwRR5466/agent.5466; export SSH_AUTH_SOCK;
> SSH_AGENT_PID=5467; export SSH_AGENT_PID;

Here you are not actually starting the ssh-agent in the background (which explains why it is outputting environment variables). You should give it a second parameter to tell it which program to launch.

ssh-agent bash

However, this will cause the parent shell to become redundant, so you want to instead replace it with the shell that ssh-agent starts (that shell has the environment variables set appropriately).

exec ssh-agent bash

Now when you use ssh-add, it should be able to see the agent.

> echo Agent pid 5467;
> [bluethundr@LCENT01:~]#ssh-add
> Could not open a connection to your authentication agent.
> [bluethundr@LCENT01:~]#exec ssh-agent bash
> [bluethundr@LCENT01:~]#ssh-add
> Enter passphrase for /home/bluethundr/.ssh/id_rsa:
> Identity added: /home/bluethundr/.ssh/id_rsa (/home/bluethundr/.ssh/id_rsa)
>
> So this behavior did not change. I still have to enter my passphrase
> again after I put this into my .bash_profile
>

Of course. The passphrase is important because it encrypts the private key. This, presumably, is why you are using the 'keychain' program, which is typically used to have a key unlocked manually by a system administrator (eg. after boot), so that cron jobs, etc, can access it.

>
> [bluethundr@LCENT01:~]#ssh virt1
> Last login: Sat Jan 15 11:51:08 2011 from 192.168.1.42
> ################################################## #######
> # SUMMITNJHOME.COM #
> # TITLE: LB1 BOX #
> # HOST: VIRTCENT01 #
> # LOCATION: SUMMIT BASEMENT #
> ################################################## #######
>
> * keychain 2.7.0 ~ http://www.funtoo.org
> * Found existing ssh-agent: 27556
> * Adding 1 ssh key(s): /home/bluethundr/.ssh/id_rsa
> Enter passphrase for /home/bluethundr/.ssh/id_rsa:
> Bad passphrase, try again for /home/bluethundr/.ssh/id_rsa:
> * ssh-add: Identities added: /home/bluethundr/.ssh/id_rsa
>
> This is new.. now I get prompted for the passphrase AGAIN once I reach
> the server I am ssh'ing in to.

This is why ssh-add (and presumably also 'keychain'), should NOT be included in your ~/.bash_profile or ~/.bashrc (or similar).
SSH Agent Forwarding is the correct way to approach this problem: it generally increases system security (keys become easier to manage) and reduces user support requirements.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 01-16-2011, 04:46 AM
bluethundr
 
Default keychain problem

That's a great clarification for which I cannot thank you enough. I
will look up SSH Agent Forwarding and start getting the hang of it.
The centos list is a tremendous help for situations like these!

On Sun, Jan 16, 2011 at 12:22 AM, Cameron Kerr <cameron@humbledown.org> wrote:
>
> On 16/01/2011, at 2:12 PM, bluethundr wrote:
>
>> Hello and thanks for your reply!
>>
>> Well I took your advice and removed that keychain scriptlet from
>> .bashrc and put it into .bash_profile. Not sure what the functional
>> difference between the two would be. Perhaps you would care to
>> elaborate? I know that rc stands for "resource configuration" but
>> other than that I don't know why this statement would be more
>> appropriate in the .bash_profile. However you do seem well versed in
>> this and I hope you don't mind answering this question.
>>
>
> .bash_profile is executed for login shells (followed by .bashrc).
>
> .bashrc is executed for non-login shells as well.
>
> .bash_profile should therefore be used for session setup tasks.
>
>> So this is what I put into my .bash_profile
>>
>> $(keychain --eval --agents ssh id_rsa)
>>
>> and here is an ssh session from after when I did this:
>>
>> [bluethundr@LCENT01:~]#bash
>> [bluethundr@LCENT01:~]#ssh-agent
>> SSH_AUTH_SOCK=/tmp/ssh-cBwwRR5466/agent.5466; export SSH_AUTH_SOCK;
>> SSH_AGENT_PID=5467; export SSH_AGENT_PID;
>
> Here you are not actually starting the ssh-agent in the background (which explains why it is outputting environment variables). You should give it a second parameter to tell it which program to launch.
>
> ssh-agent bash
>
> However, this will cause the parent shell to become redundant, so you want to instead replace it with the shell that ssh-agent starts (that shell has the environment variables set appropriately).
>
> exec ssh-agent bash
>
> Now when you use ssh-add, it should be able to see the agent.
>
>> echo Agent pid 5467;
>> [bluethundr@LCENT01:~]#ssh-add
>> Could not open a connection to your authentication agent.
>> [bluethundr@LCENT01:~]#exec ssh-agent bash
>> [bluethundr@LCENT01:~]#ssh-add
>> Enter passphrase for /home/bluethundr/.ssh/id_rsa:
>> Identity added: /home/bluethundr/.ssh/id_rsa (/home/bluethundr/.ssh/id_rsa)
>>
>> So this behavior did not change. I still have to enter my passphrase
>> again after I put this into my .bash_profile
>>
>
> Of course. The passphrase is important because it encrypts the private key. This, presumably, is why you are using the 'keychain' program, which is typically used to have a key unlocked manually by a system administrator (eg. after boot), so that cron jobs, etc, can access it.
>
>>
>> [bluethundr@LCENT01:~]#ssh virt1
>> Last login: Sat Jan 15 11:51:08 2011 from 192.168.1.42
>> ################################################## #######
>> # * * * * * * * SUMMITNJHOME.COM * * * * * * * * * * * *#
>> # * * * * * * * TITLE: * * * LB1 BOX * * * * * * * * * *#
>> # * * * * * * * HOST: * * * *VIRTCENT01 * * * * * * * * #
>> # * * * * * * * LOCATION: * *SUMMIT BASEMENT * * * * * *#
>> ################################################## #######
>>
>> * keychain 2.7.0 ~ http://www.funtoo.org
>> * Found existing ssh-agent: 27556
>> * Adding 1 ssh key(s): /home/bluethundr/.ssh/id_rsa
>> Enter passphrase for /home/bluethundr/.ssh/id_rsa:
>> Bad passphrase, try again for /home/bluethundr/.ssh/id_rsa:
>> * ssh-add: Identities added: /home/bluethundr/.ssh/id_rsa
>>
>> This is new.. now I get prompted for the passphrase AGAIN once I reach
>> the server I am ssh'ing in to.
>
> This is why ssh-add (and presumably also 'keychain'), should NOT be included in your ~/.bash_profile or ~/.bashrc (or similar).
> SSH Agent Forwarding is the correct way to approach this problem: it generally increases system security (keys become easier to manage) and reduces user support requirements.
>
> _______________________________________________
> CentOS mailing list
> CentOS@centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



--
GPG me!!

gpg --keyserver pgp.mit.edu --recv-keys F186197B
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org