Managing multiple GitHub Accounts (ssh keys) for Composer require in DDEV under WSL2-CodePudding

i have added a second 2 ssh keys and added the needed config in ubuntu WSL2 ~/.ssh

      Host github-key2
        HostName github.com
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/key2

so in UBUNTU this works:

    git clone git@github-key2:vendor/repoxxx.git

But i need to geht this running in ddev with composer:

I added git@github-key2:vendor/repoxxx.git in the repositories section of composer in same Way i did it for other protected repos

    "vendor/repoxxx": {
        "type": "vcs",
        "url": "git@github-key2:vendor/repoxxx"
    }

ddev auth ssh (both keys where added)

but composer in DDEV just uses the normal "id_rsa" key but not the second "key2"

    ddev composer req vendor/repoxxx

CodePudding user response：

You'll need to put a .ssh/config file into the container. The normal way to do this is to put the .ssh/config that you need into homeadditions, either in the project or global homeadditions.

Docs on homeadditions are at https://ddev.readthedocs.io/en/latest/users/extend/in-container-configuration/

For some people, just symlinking or copying their host-side .ssh/config works, but for most situations you'll need a custom .ssh/config for use inside the container.

CodePudding user response：

You're installing or updating composer dependencies within an environment your SSH configuration is not available.

Instead of running composer within that environment, just deploy your project dependencies from the working environment into the execution environment. For Composer a recursive copy of the vendor-dir suffices, by default it is vendor.

E.g. if you're using virtual machines or Docker containers for development, you mount the vendor folder (should be a read-only mount) and you're typically done.

There is a caveat thought: The PHP platform on your development box may diverge from the target PHP platform of the project (e.g. a different PHP version, may also happen later when you update your development box).

If this is the case, make the target platform explicitly visible in your project configuration file (composer.json by default) so that you have this properly documented and composer gets the dependencies in the correct versions of the target platform and knows which PHP extensions and library versions are available there.

TLDR: Keep resolving the dependencies out of the process to host the application, since the earliest version. The runtime environment must not need to know anything about your composer usage or SSH configuration and shouldn't rely on it.

Takeaway:

Draw that line between the build and the execution environment early, as often it is not immediately visible for developers that focus on a certain technical issue only - albeit it is there since the very beginning. If it is kept hidden for a longer time, it can cause to learn about it only later, putting the burden to fix configuration and other application flaws in the project late. The flaws you learn late about cause the highest costs.