Automate the copy of ~/.ssh/config and ~/.ssh/*.pub from the host to the container

[rubensa]

This should solve the problem that the ssh client inside the container is not providing the right ssh credentials (when multiple credentials are added to the host ssh-agent). See: #5026

• This process should be done as currently is been done for ~/.ssh/known_hosts.
• Ideally there should be a setting for the container and user pair (see: Overlay .devcontainer #3279 about overlaying devcontainer.json).
• As, for now, this is not possible, the config setting should be allowed both as a user (for all containers for this user) and devcontainer.json (for all users of this container) setting. You should be able to choose with one to use.

[max06]

Sorry to jump in here: Imho the ssh-agent is doing the right thing here. It's testing all available keys until there's a matching one. It's not user aware since users usually only have one account, or are using different user+key-combinations.

Especially here on GH this doesn't make much sense, since you can simply add all the projects to a single account and access them by using a single key file. But I'm interested about your use case.

If this becomes a feature, please make it optional. I don't want my ssh config and keys to be available inside my containers (they are managing their own config) or even have them shared with the host (or written back).

[rubensa]

@max06 The idea is that the feature is optional and enabled/disabled by a user or devcontainer.json setting.

To see the problem in detail, please follow #5026 but basically:

I've got two different GitHub users. One user for own projects and the other for work projects both having write access to different repos. Each user has it's own public and privake keys and both keys are added to the ssh-agent. In the host machine, the credentials provided by ssh-agent are ok. They are choosen based on .ssh/config Host settings (like github.com-user1 and github.com-user2) but in the Docker container the ssh-agent tries sequentially all the private keys with a HostName match (despite not matching de Host the HostName is the same for both, github.com) and the first that can login on GitHub is used so the wrong private key (and then, the wrong user) is used for accessing some repos.

Currently VSCode automaticallly (without any configuration preference, as far as I know) copies the file ~/.ssh/known_hosts to the container when it first creates de container. The idea is to use the same mechanism (but based on a setting for doing so) to copy not only that file but the ~/.ssh/config config file (so the Host match can be resolved) and the ~/.ssh/*.pub public keys (so the right private key can be provided by ssh-agent based on it's public pair).

The private keys should not be copied to avoid potential security risks.

[lorenzomar]

Any news or workaround on this?
I'm having same issue with ~/.ssh/config file containing different configuration with different host:

Host github-work
    HostName github.com
    IdentityFile ~/.ssh/id_work_ed25519
    AddKeysToAgent yes
    UseKeychain yes

Host github-personal
    HostName github.com
    IdentityFile ~/.ssh/id_personal_ed25519
    AddKeysToAgent yes
    UseKeychain yes

When I try to clone repository in a container volume using a url like this git@github-personal:[username]/[repository] it fails since it not able to resolve github-personal

[rubensa]

As far as I know there have been no work on this.
For now, I'm mounting the full .ssh folder from host so it is available in the container.

[max06]

Alternative: Install the necessary files from an encrypted git repository, like as dotfiles. VSCode handles them automatically.

It's not nice or clean, or something I would consider as save, but it would work for your issue.

[rubensa]

@max06 You mean "git-crypt"? It might be possible to use this if the git repository is only yours (as it would contain only your credentials) but for a shared repository, how would you handle everyone's credentials?

[max06]

Have a look at "dotfiles". These are personal, vscode applies them into your created container at the end.

Example:

[max06]

Now back on a keyboard, I can give you some more information.

A dotfile repository usually contains your personal settings for your shell environment. By specifying such a repository (which is just a regular git repo with a script as entrypoint) you allow vscode to personalize your devcontainers to your likings.

A solution to your issue: Set up gpg on your host system, create a keypair and encrypt your private ssh keys with that keypair. You can then commit the encrypted files to your dotfile repo and add the decryption step in the install-script. VScode forwards your gpg-agent into the container, similar to the ssh agent.

On container creation vscode clones your dotfiles, runs the install script and decrypts your private keys using your keypair in the gpg-agent. The devcontainer definition stays generic, and you and your users have separate dotfile repositories.

I personally wouldn't upload any kind of private credentials to a git repository, no matter if encrypted or not. It might be safe now, but if a vulnerability is found in the encryption algorythm, you're more or less screwed. Just my opinion.

---

Another solution: Add a named volume (like ssh-config) to the devcontainer mounts-section. You'd have to copy your private keys once manually, but it would survive rebuilds.

[rubensa]

Thanks @max06 for the info.
But what's the point on creating a dedicated volume, manually copying your keys and then mounting that volume in the container vs simply mounting your .ssh folder? At the end the container has access to your private keys anyway (so, a malicious extension could steal them).
To me, the best solution should be the proposed enhancement (that avoids to share your keys in a git repository and you do not have to manually add the keys -and your private keys are not shared to the container, is the host ssh-agent whose access them, only the public keys are shared-).

[GH0st3rs]

I'm agree the issue more not to forward the keys, but forward the ssh config options. If you have a host with specific SSH options, or specific name, or something else and you're developing inside container, time to time you need to push or upload something to that server. The same options like copy ~/.gitconfig it need to be for ~/.ssh/config