0

I have access to a shared remote machine to execute code and store data, accessible through SSH from my local machine, but I do not have root privileges there. The remote is shared among many users. I usually store code in my personal GitHub account, so I would like to set up GitHub repositories in this remote machine.

What is the most secure way of setting up GitHub authentication in this remote machine for accessing (push, pull, fetch, clone) a specific (and potentially private) GitHub repository?

I have already thought about and tried some possibilities:

  • In the remote server, access the repo using login and a personal access token. This is not good, because the token could be intercepted and it would give access to all of my repos.
  • In the remote server, access the repo using a deploy key added to remote machine's ssh-agent. I'm not sure the safety about ssh-agent. Could other users, non-root users also, use my ssh-agent as if they were me?
  • In the remote server, access the repo using a deploy key, but without adding it to the ssh-agent, i.e., typing passphrase every time.
  • Set up SSH key (GitHub authentication or deploy key) in my local machine and connect to remote through SSH using ssh-agent forwarding. This seems to be bad, because it allows one to impersonate me using my entire set of private SSH keys when I am connected. Also, I could not make standard ssh-agent forwarding ask for any confirmation when accessing ssh-agent. This was a question I asked in Unix & Linux.

Just in case, both local and remote machines run Ubuntu, 21.04 and 20.04, respectively.

1

It depends on the use case.

Deployment from public repository:

In this case, the best option is to use HTTPS, because no credentials are needed.

Deployment from a private repository:

When you need to deploy from a private repo, you must configure deployment keys. Those keys should only be allowed to read the repository (no write permission)

Development on a remote server (read/write access):

In the default configuration, ssh agent forwarding is still a security issue.

PuTTY and OpenSSH have added a lot of features regarding agent forwarding and depending on the client, the configuration and the operating system, agent forwarding is more secure, than using a password protected private key on the remote server.

Important! This combination only works on linux machines! (see notes about windows, macos not tested).

If agent forwarding is used, the private keys must be protected with ssh-askpass or a fido2 token.

The recommended method is using PuTTY in combination with the OpenSSH agent. PuTTY is able to detect and mitigate spoofing attacks in recent versions.

When using PuTTY>=0.76, you should use Disable "trivial" authentication (SSH-2 only). This option can be found under "Connection -> SSH -> Auth". In older versions (>0.71) you can use the trust sigils to detect spoofing attacks.

Pageant (PuTTY's agent) should not be used, because it does not support fido2 tokens or ssh-askpass. This is where the OpenSSH agent comes in.

You only have to start the ssh agent (if it is not already started). When PuTTY is started, it can use the OpenSSH agent without further configuration.

With this setup, you have to confirm each usage of the private key and abusing or spoofing a forwarded agent is not possible.

Note on Windows:

Since Windows 10 it's possible to install the OpenSSH client as an extra, but this version is not compatible with PuTTY. The reason ist, that the windows version uses named pipes and PuTTY only supports sockets.

2
  • Thank you for the detailed answer. Do you happen to know an alternative of PuTTY which does not rely on specific terminal, but which has this feature of confirming each private key usage when SSH agent forwarding?
    – lucasresck
    Nov 14 '21 at 17:01
  • If you want a command line tool, you can use plink. plink is part of the putty package. It can be used with command line arguments or stored sessions from the gui version. At the moment, PuTTY and Dropbear are the only clients which can disable trivial authentications. Nov 14 '21 at 20:01
0

A little more research made me conclude, for now, that setting up a GitHub repository deploy key and add the passphrase to the ssh-agent is a good option.

Deploy key is convenient because it isolates a single repository, and ssh-agent is convenient because it stores the SSH key passphrase in memory until ssh-agent is killed. It is possible to configure the ssh-agent to be killed after logout with a simple script.

Of course, what I am calling "convenient" is based on my judgement considering the trade off between security and convenience. This is a good answer about this trade off. Although the author does not consider GitHub authentication specifically, they go deep into the options of SSH. They do not consider ssh-agent forwarding, but I have already discarded it because its intrinsic risk.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.