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.

How can I run a script to log into a remote server and execute a remote ssh command without entering in my passphrase?

For example:

When I log onto a remote server and execute the git pull command I see ssh prompt me for my passphrase:

$ git pull origin master
Enter passphrase for /home/v3ed2/.ssh/id_rsa:

Once I enter my passphrase I continue with the command.

I want to run a script that will log into the remote server and run the command for me. I already tried this script:

ssh ve "cd clients/ ; git pull"

However, when the script runs, it does not prompt me for my passphrase. The script just hangs while it waits for my passphrase, but when I try to enter a passphrase, I get the error:

bash: line 1: [REDACTED]: command not found    
share|improve this question
    
Good first question. –  slm Dec 22 '12 at 5:24
    
Though, you probably want to stop using that password. –  bahamat Dec 22 '12 at 9:42
    
That was a fake pass, so no worries. Thanks for the edit. –  luk3thomas Jan 9 '13 at 19:31

3 Answers 3

up vote 5 down vote accepted

When you run ssh with no command, it sets up a pseudo-terminal on the server side and runs an interactive shell in that terminal. When you pass a command, the command is executed with its input and output directly connected to the SSH channel, there is no remote terminal. If you pass the -t option, then a terminal is created on the remote side, and you will get a password prompt where you can type your password.

ssh -t ve "cd clients/ ; git pull"

However, this is not a convenient way to do it. The convenient way is to run an SSH agent on your local machine, and forward that agent's connection.

First, you need to use public key authentication, not password authentication, on the second connection (to the git server). You're already doing this so I won't go into more detail.

Copy the private key for the second server (/home/v3ed2/.ssh/id_rsa on the intermediate machine) to your local machine. Alternatively, on the git server, authorize a public key for which you have the private key on your local machine. Alternatively, first run ssh -t ve ssh-add .ssh/id_rsa to register the intermediate machine's key with your local agent.

Some distributions and desktop environments already set up an SSH agent. Check if you have one running with ssh-add -l. If this tells you you have no agent running, you'll need to start one with your session. Either run ssh-agent your-session-manager instead of calling your-session-manager directly, or run eval $(ssh-agent) in your session startup script, or tick the “run SSH agent” checkbox in your GUI configuration. You need to do two things: start the ssh-agent program, and get the SSH_AUTH_SOCK variable that it sets or prints into your session's environment. The details of how to do this are very specific to your distribution and desktop environment.

Once you have the SSH agent running locally, make sure that it is forwarded. It may or may not be forwarded by default. Run ssh ev ssh-add -l to check whether the agent is forwarded. If it isn't, add the line ForwardAgent yes to your local ~/.ssh/config.

If you're running Windows with PuTTY locally, it comes with a key agent too, Pageant. See the PuTTY manual for instructions.

When you have a working SSH agent setup, register your key(s) with the agent once per session, with the command ssh-add ~/.ssh/id_rsa (or whatever the path to the private key is). After this, you can use the key with no prompting for the remainder of the session.

share|improve this answer
    
Adding the -t switch worked for me. Thanks! –  luk3thomas Jan 9 '13 at 19:32

The question is too broad so there are multiple variants to fix this.

The first one is to use a key without passphrase. Technically, a passphrase is a key for some symmetric crypting algorithm which crypts local private key. Empty passphrase means the key isn't crypted and can be used by any who has access to read it. You can instruct ssh-keygen to use empty passphrase with -N '' when generating it, or later change it using -p (all options here are for OpenSSH flavor). This is the most popular method to provide signed automated access to a remote system. Often it's combined with server-side restrictions to the key (limiting by IP, forced command, restricted shell, etc.)

You can protect uncrypted private keys on a crypted disk, if needed.

Next, you can use ssh-agent. It requires a user to be logged on the system, and caches passphrases in its memory while running, so you can enter the passphrase only once during a X terminal session (or analog) and then automatically log on to remote server without repeating the passphrase.

Next, you can use Kerberos which provide its own session-time tickets for remote login, if both client and server hosts belong to the same realm.

Next, you can use expect or a similar tool to automate interaction with a terminal where the command is run. Its script should listen for a passphrase prompt and enter it. But this is much more complex and cumbersome than all other approaches described here, and should be treated as the last resort when others fail.

This list can be continued with more exotic approaches:)

share|improve this answer

I think what you're looking for is the use of SSH keys. You'll need to generate a set of keys (one is private, the other is public) and add the public key to your account on the remote system. Once you have keys situated you'll be able to login remotely to the other system without having to be prompted for a password.

Check out these howtos for more details:

share|improve this answer
    
The requestor already uses keys. –  Netch Dec 22 '12 at 6:07
    
In that there are 2 options, regenerate the keys w/o a passphrase or make use of ssh-agent & ssh-add. These details are also in the links I provided and also here: mah.everybody.org/docs/ssh –  slm Dec 22 '12 at 6:13

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.