We have a remote server which we use to build a certain part of our software. Part of that build process needs access to a private bitbucket repository.

Normally in my local machine I have set the .gitconfig such that git uses ssh to connect to bitbucket and by starting the ssh agent with eval $(ssh-agent) and using ssh-add to add the necessary key this works ok.

I cannot get this to work in the remote server.
The way I am trying to do this is to connect to the remote server and run a script like this

     eval $(ssh-agent)
     ssh-add ~/route/to/key
     ... rest of build script ...

When trying that I get the output that the agent has started with the agent pid but the ssh-add fails with the error : Error connecting to agent: No such file or directory. Which suggests that it cannot access the agent socket (If I understand it correctly)

What is going wrong here? I am new to setting up these kind of things so don't hesitate to explain even the basics.

  • The usual way to give a build server access to a private code repo is to create a "service" user (sometimes called a "robot" user) in the repository and give that user auth files (ssh key or api token) in the repo and on the build server. This has the advantage that the build server enjoys read-only access to the repo instead of the read/write access of a software engineer.
    – Sotto Voce
    Commented Sep 6, 2023 at 15:07
  • Does the remote server have a copy of your private key at ~/route/to/key? Did you forget to forward the authentication agent connection (ssh -A)? To do what you are trying to do, I would think one of those scenarios would have to be true. If you use the authentication agent forward, you should not need to use a script to set up ssh-agent. Commented Sep 6, 2023 at 16:25
  • @GracefulRestart I did try the ssh -A way. And added an ssh-add -l command to the script to see if it works. Even though the output showed my identity added to the ssh-agent access to bitbucket was still refused
    – Corcus
    Commented Sep 7, 2023 at 12:58
  • @SottoVoce I think this is a good idea to give the build server read access to bitbucket regardless of the build script. And it is more secure. I will look into doing it that way
    – Corcus
    Commented Sep 7, 2023 at 13:00

1 Answer 1


Short answer: Either you have the keys on remote and you just forgot the ticks 'EOF' OR you have the keys on locale and vainly hope this is way to transfer the key over to the remote. In the second case ,transfer your key to remote by some other secure way (like scp -p) or upload your remote public identity key (assuming you generated one already) to bitbucket.

Long answer:

Just type ssh-agent see to what is happening here.


cat  << EOF
     echo Would do remotely   eval $(ssh-agent)
     echo Would do remotely   ssh-add ~/route/to/key
     echo -------------


     echo WOULD DO   eval $(ssh-agent)
     echo WOULD DO   ssh-add ~/route/to/key

in the case you feel I am suggesting unrelated nonsense.)

The output contains something like


which is Unix domain socket address of your ssh-agent on the local machine. This is local to your machine and does not exist (hopefully!) on the remote machine.

Such socket file does not exist on both of the machines. May be you wanted to write

#  Note  ' ' on the following line -----------------here-------------\--\
     eval $(ssh-agent)
     ssh-add ~/route/to/key
     ... rest of build script ...

if ~/route/to/key is valid on the remote machine.

Remark. If you know what you are doing, you could try also something like ssh-agent bash -c 'ssh-add ~/route/to/key; ssh -A -i"${BUILDHOSTKEY}" "${BUILDHOSTUSERNAME}"@"${BUILDHOSTNAME}"'

Update: The comments indicate the cat <<EOF versus cat <<'EOF' partly hits the problem. One can obtain more control by creating a temporary file

echo 'echo This will expanded on remote: $VAR $(hostname; ls file) ' > file.$$
echo "echo This will be expanded locally: $VAR $(hostname; ls -l file) ' >> file.SS
echo "ls -l /dir/file # This list the remote file anyway " >> file.$$
ssh ....  < file.$$

or we can use backslash escapes:

ssh ....  <<EOF
echo This will expanded on remote: \$VAR \$(hostname; ls file)
echo This will be expanded locally: $VAR $(hostname; ls file)
ls -l /dir/file # This list the remote file anyway

(not tested)

  • Thank you for your answer. Let me give some extra info. I did try the ssh -A option, and had the script in the EOF scope do ssh-add -l to see if the agent from my local machine had been propagated to the remote. Even though the output seemed correct and I could see my identity added. access to bitbucket was still refused
    – Corcus
    Commented Sep 7, 2023 at 12:45
  • Thank you for bringing 'EOF' vs EOF to my attention, I didn't know the difference. However, in the build script there are some variables that need to be expanded. So I can't use 'EOF'. Does not using single quotes mean that the local ~/route/to/key path will be used and not the remote??
    – Corcus
    Commented Sep 7, 2023 at 12:48
  • the quotes do not work with file, they work with the text. cat << 'EOF' gets the text as it is, as it was in a file. cat << "EOF" and cat <<EOF get the string expanded (I do not remember how much expanded. One can experiment with cat or study the docs .
    – minorChaos
    Commented Sep 7, 2023 at 14:13
  • You can also use backslash to escape dollars that follow cat << EOF. They carried over to the other side (without the backslash),
    – minorChaos
    Commented Sep 7, 2023 at 14:21
  • @Corcus First login normally by ssh to the remote, manually do what the script should do. When this works correct, show us copy of your remote actions and we can create the script which.
    – minorChaos
    Commented Sep 7, 2023 at 14:23

You must log in to answer this question.

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