5

We have set up a CentOS 6.4 box with passwordless SSH to multiple other systems. This works fine when using a terminal as the correct user directly on the CentOS computer. However, if I log into the CentOS box as one of those same users from another system, I get prompted for the RSA key passphrase. Why is this necessary when I am logged on as the correct user?

So, if we have three machines (A, B and C). A has been set up so it can passwordlessly connect to machine B over SSH. That works fine. However, if we SSH into A from machine C, and then from that remote SSH terminal attempt to SSH into B, this requires a password.

Machine A has scripts on it that access several other machines (passwordlessly). We need to be able to remotely log into machine A from Machine C, and then kick off the scripts which access machine B.

1
  • Did you enter a passphrase when you generated the key? Sep 27, 2013 at 20:48

4 Answers 4

3

Your question is somewhat unclear. It appears that you are using a SSH key, but the SSH key is protected by a passphrase. But then it should actually ask you for that passphrase also when you are logged in directly.

What I would do:

  1. Create a special user (lets call it 'runscripts') on machine A which is used to run the scripts.
  2. For this user create a SSH key which is not encrypted by a passphrase.
  3. Configure sudo to allow "normal" users on machine A to execute these scripts with the user privileges of user 'runscripts' and without having to enter a password.

Here is a complete example how to set this up:

Create a new user which can not be logged into (on my system this will also create a new group with the same name which I will use in the following):

# adduser --disabled-password runscripts

Become this user and create a ssh key. Don't set a passphrase on the key, just press enter on the passphrase prompt.

# su runscripts
$ ssh-keygen

Add the public key (in ~/.ssh/id_rsa.pub) to the authorized_keys on the target machine (machine B in your example), then shortly try the login by SSH key (which will also add the remote public key to the known_hosts, so that it will not prompt again later).

$ ssh [email protected]

Back on machine A: Add the normal useraccount(s) to the group:

# adduser kju runscripts

Create some script which will use the SSH key and do something on B:

# cat > /usr/local/bin/script1
#!/bin/sh
echo -n "Running as "
whoami
ssh remoteuser@machineB whoami
^D
# chmod +x /usr/local/bin/script1

Finally allow the users in group runscripts to execute this script as user runscript without a password. This is the line from /etc/sudoers:

%runscripts  ALL=(runscripts) NOPASSWD:/usr/local/bin/script1

Now as one of the users in group runscripts try to run the script:

$ sudo -u runscripts /user/local/bin/script1
Running as user runscripts
remoteuser
$

As you can see from this output, the script was excuted as user runscripts. It then logged into Machine B as user 'remoteuser' and executed the 'whoami' command (which then of course returned 'remoteuser').

Doing it like this has the benefit that nobody shall be able to steal the (unprotected) SSH key because it is only accessible as user runscripts but people can only run the predetermined scripts with this users privileges.

0

You need to generate the key without a passphrase and use public key authentication if you want to avoid this. Do something like:

a@A:~> ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/a/.ssh/id_rsa): 
Created directory '/home/a/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/a/.ssh/id_rsa.
Your public key has been saved in /home/a/.ssh/id_rsa.pub.
The key fingerprint is:
3e:4f:05:79:3a:9f:96:7c:3b:ad:e9:58:37:bc:37:e4 a@A

In other words, just hit enter when it prompts you with Enter passphrase (empty for no passphrase):

https://hkn.eecs.berkeley.edu/~dhsu/ssh_public_key_howto.html

0

You said,

as one of those same users

so I take it we're talking about more than one user.

If I'm correct, what it seems to me could be happening is this:

  • you log on to A as user foo
  • user bar on machine B has in B:/home/bar/.ssh/authorized_keys the public key of foo, whose identity is in A:/home/foo/.ssh/identity.rsa.
  • so of course foo from A can issue ssh bar@B and have it work passwordlessly.

Now if user bar from machine C logs onto machine A as himself ("one of those same users"), i.e. as bar, he becomes bar@A; not foo@A. And when he tries to log as bar@B, the identity key that is retrieved by ssh to perform the login is bar's; it is not A:/home/foo/.ssh/identity.rsa, but A:/home/bar/.ssh/identity.rsa . And maybe that file is locked by a passphrase.

So: check your users and what identities they are using.

0

Either generate the key without a passphrase or create a special script which would read the passphrase from the current terminal by using SSH_ASKPASS variable. This is particularly useful when calling ssh-add from a related script. For example:

install -vm700 <(echo "echo 'my_passphrase'") $HOME/.ps
cat /path/id_rsa | ssh-add DISPLAY= SSH_ASKPASS=$HOME/.ps -

Notes:

  • Creating .ps script is just one-time work, the rest can be added into your rc files.
  • It won't work if ssh have a terminal associated with or DISPLAY is set.
  • In case your ssh-agent is not running, if not - run: eval "$(ssh-agent -s)"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .