On a remote server, to deploy code with BitBucket, we use a secure connection and authentication using ssh keys. I connect to the server itself via putty (I’m sitting with win10), and each time I have to restart ssh-agent with the command eval $ (ssh-agent) and add the necessary keys. I looked at the running processes, all the previously running ssh-agents are in memory, but if you break the connection to the server and then open it again, the ssh-agent is again unavailable. Tell me what could be the problem?

devloop@s05657c43:~# ssh-agent SSH_AUTH_SOCK=/tmp/ssh-m8EJNB3MFimr/agent.13061; export SSH_AUTH_SOCK; SSH_AGENT_PID=13062; export SSH_AGENT_PID; echo Agent pid 13062; devloop@s05657c43:~$ ssh-add .ssh/devloop Could not open a connection to your authentication agent.
  • Thanks for the answers, the solution identityfile ~ / .ssh / devloop came up in a hurry. Read more in detail , thanks for the links - Konstantin Viikset

2 answers 2

the fact that the ssh-agent process is running on a remote machine already hints that you are probably not using it for its intended purpose.

quote from man ssh-agent :

PC, laptop, or terminal. Data passphrases never go over the network.

my free translation:

the idea is that ssh-agent runs on the local computer. so that no authentication data need to be stored on another machine, and no passwords are transmitted over the network.

judging by this fragment:

 $ ssh-add .ssh/devloop

You want to authenticate on some other remote machines from the first remote machine using the key stored on the remote machine (in the ~/.ssh/devloop ).

in this case, it makes no sense for you to run the ssh-agent process on this remote machine. in order to authenticate on other machines using this key, you can use any of the following options:

  • rename the ~/.ssh/devloop to ~/.ssh/id_rsa . This option will not work if such a file already exists and you need its contents for some other purpose.

  • Explicitly specify this file when connecting:

     $ ssh -i ~/.ssh/devloop другая-отдалённая-машина

  • Add the following line to the beginning of the ~/.ssh/config file:

     identityfile ~/.ssh/devloop

    then ssh will attempt to use this file during authentication.

    if this file needs to be used only for authentication on only a few specific machines, then it is better to add a section to the end of the ~/.ssh/config file instead of the specified line:

     host машина1 машина2 машина3 identityfile ~/.ssh/devloop

but if I guessed wrong, and you actually need the ssh-agent process, then it is better to run it as a “layer” (as it is actually used in modern distributions), i.e. immediately indicate when connecting a command like ssh-agent оболочка , like this:

 $ ssh -t отдалённая-машина ssh-agent bash

the -t option here is necessary for tty to be allotted (if you do not specify a command, i.e., to initiate the launch of the shell, then tty is automatically assigned).

and, perhaps, it would be better to use a terminal multiplexer ( screen , tmux , etc.), which, by the way, can also be run with an “interlayer” in the form of ssh-agent , like this:

 $ ssh -t отдалённая-машина ssh-agent screen

ps and, yes, the question does not carry any distributional specifics, but only concerns the openssh client.

    If you are working on a local machine under windows 10 and want to connect to another machine using putty, then the key must be running on your machine.

    For this, the pageant program (putty agent) is included with the putty, which will quietly roll up in the tray and stay there.

    The putty program is able to forward the key to a remote machine, so every time you connect to a remote machine, it will run ssh-agent and give it the key from the windows 10 machine.

    Check the Allow agent forwarding setting in putty on the Connection - SSH - Auth tab

    putty agent forwarding settings

    In general, all the correct programs under windows are able to forward the agent, for example winscp:

    winscp forward agent settings

    So, if you connect to some * nix-machine, then putty will forward keys to this machine (in / tmp throws the private key)

    There are more advanced schemes, when you connect from one machine to another and try to connect to a third one, while the second one does not even have a key (if there is a suspicion that the machine has been compromised).

    More details can be found at the end of this article: https://habrahabr.ru/post/122445/

    In general, with the correct setting of forwarding, there is no difference, whether you are sitting on a windows machine or on linux - everything will be approximately the same.

    Since it’s not entirely clear whether you need to go somewhere else from the linux machine, I’ll leave a mention just in case: if you want to forward the key to the linux machine from windows 10 and forward authorization from it further, read about the setting in ~/.ssh/config authentication pass through:

     Host * ForwardAgent yes