Add SSH agent support via "keys: agent"

[sk33lz]

What is your lando version and operating system?

• Lando v3.0.0-beta.22 on MacOS Sierra 10.12.6

Feature/Enhancement Request

I use a password protected SSH key, and I'm sure many others who use lando, or would like to do. I did some research and apparently having to enter a password on every remote command is not something that is lando's fault per se. It's apparently a known issue with Docker and MacOS due to the way the MacOS handles sockets. Luckily, there seems to be some work being done on workarounds for this issue by other teams. Below is one that I found that looks like it could be integrated into the lando backend to run docker commands with extra parameters to allow for a single entry of the password while running commands like lando drush sql-sync on a remote server using drush aliases.

https://github.com/uber-common/docker-ssh-agent-forward

Other implementations I found in my searches:

• https://github.com/AaronFeledy/lando-scripts
• https://github.com/nardeas/docker-ssh-agent

I have currently setup a workaround on the lando project level by adding a custom tooling command to our .lando.yaml file. This command forwards the agent before each remote drush command, but it would be great to see something like this implemented in the lando commands on backend so that it's easier to use password protected SSH keys out of the box.

Thanks for a great tool!

• Jason

[pirog]

@sk33lz so im definitely open to an implementation (read: PR) for this. that said while lando does allow users to inject passphrase-protected keys our "official" (but flexible and not-dogmatic) position is that users should use "non passphrase protected keys" with lando. There are a few reasons for this

1. It is likely there will be future GUI products built on Lando and a design goal there is to only ask the user for their password once (and that is during the actual install and its their system password)
2. I don't personally think that a passphrase protected key that you intend to only enter once is significantly more secure for the local dev case than just having your computer itself have a password.

I'm going to backlog this and again, im super open to a PR that would support this but i dont think its something we can prioritize internally (at least right now)

[dnotes]

This is not a particularly important issue for me, but I'm wondering why you don't think passphrase protected keys with ssh-agent is significantly more secure than just having the computer have a password? I mean, if I lose my computer and someone gets into it, I would very much appreciate some additional barrier between them and full access to all of my git repositories and servers. In an age when exploits for obtaining computer access can be as easy as using "root" with no password and clicking the "login" button twice (nice one Apple), I think protecting one's SSH keys is absolutely obligatory for any developer.

Anyhow this would be nice eventually but it's not a huge issue for me to type in keys on rebuild.

[pirog]

I don't think it's significantly more secure if you intend to only enter the passphrase once as described in this issue eg in a keychain or some other password management solution that someone who has broken into your computer likely has access to. In this scenario you more or less have a passphrase-less key anyway.

If you do intend to enter the passphrase every single time you use the key then yah obviously that is more secure. That said, im guessing the vast majority of people use the same password for their laptop as they do their passphrase protected key, so the most important thing you can do to protect yourself is having a good password for your machine.

It's also worth pointing out that you still definitely can use passphrase protected keys with lando, its just not the default functionality.

[sk33lz]

I work locally with Lando, so the idea was that entering it once was more of a usability enhancement rather than a security concern. Entering the password once was just an easier workflow to deal with for local development.

The tooling workaround I am using is working ok for now, but it would be great to see something out of the box down the line to support one of the fixes mentioned in my original feature request. I'll submit a PR if I come up with a good solution to contribute. I'd love to leave this open to see if anyone else in the Lando community comes up with a workable solution for this.

Thanks again!

[pirog]

@sk33lz yup. totally understand that. my point there was simply it seems like a lot of extra effort on the lando end to implement with not a ton of extra benefit (eg going from entering no password to entering it just once).

That said im not opposed to making a change that would allow this its just something Team Lando can't focus on in the foreseeable future, aka its likely this would have to be a community provided feature in the short-medium term.

[jaydansand]

SSH agent support is far more than just an extra one-time password - that's a dangerous oversimplification, so I'd like to pose a few points against that security assumption. Also, because I really like Lando and want SSH agent forwarding to work easily.

If you store unencrypted private keys on your machine, then they are vulnerable to exfiltration by virus/accident (and subsequent abuse), or via OS login bypass (as @sk33lz mentioned), and a host of other issues. Once the private key is out in the wild, it can be used against you until you go through all of your servers and revoke the key.

With an SSH agent (and encrypted keys), the keys are never directly presented to any process on the computer - the agent negotiates connections, and if the agent is well-written, the decrypted keys are stored in private, non-paged memory so it won't reside anywhere (swap file etc.) once the computer is turned off. That means exfiltrated key files are inert because they're still encrypted. Other processes can't harvest my keys because the agent doesn't leak them. If a virus is running on my computer (and it didn't keylog, or at least didn't correlate my key password), it can only abuse my keys for SSH connections while the key agent is running.

Another benefit of SSH agents is forwarding. I have servers from which I need to use git or rsync over SSH. I want to disable passphrase-based login on those boxes, but that means I'd have to put my private key on a bunch of servers so that I can leapfrog from one host to another. Enter SSH agents! I keep encrypted keys on my dev box, load them into my agent at the start of the work day, and forward my agent across SSH connections so that my keys are as safe as possible and SSH/git/rsync work transparently and without any password prompts from one server to another. No server ever needs to have a copy of my private key on disk.

@sk33lz I'd love to hear how you got Lando to forward your agent - I'm using git within Lando (because RHEL 7 still ships with git 1.x) and it's a pain to push/pull without ready access to my keys. Philosophically, I don't want a dev box that other people can root/sudo on to have a copy of my private key.

[ba66e77]

How is this different from what was requested and merged in #344 ?

[lslinnet]

@ba66e77 The difference is that by passing a key into the container like #344 is doing you will have to enter the password everytime your composer install, npm install or any other tool on the box needs to make a connection to one of the packages that is private or require a certain key to obtain.

Additionally as @jaydansand pointed out the forwarding of ssh-agent allows you to connect to one server and then from that server use your ssh key to connect to the next in turn. Common place this is used is a Jump-host (example being connecting to Jumphost to continue on to the non-public mysql/elasticsearch/memcache/solr server)

@sk33lz I would love some insights into how you have configured your lando setup to allow for this ssh-agent forwarding you mention (I am guessing using the pinata ssh forward approach, but can't quite figure out how).

[sk33lz]

@ba66e77 It looks like that might resolve this issue. I'll have to try it and I'll follow up here.

@jaydansand @lslinnet I basically added a script that gets called as part of a Lando tooling command that adds the agent prior to running the command and you only have to enter it once. It's not great, but it's better than having to enter it like 5 times when trying to run a single lando command. Here is one I have for sql-sync that is run with the command lando prod-sql-sync.

Add this code to your .lando.yml file.

tooling:
  prod-sql-sync:
    description: Sync db from prod to local with fewer ssh password prompts.
    service: appserver
    cmd: /app/scripts/prod-sql-sync.sh

Add this code to a scripts dir off the root of your repository. You could have this ignored in your .gitignore if you want.

#! /usr/bin/env bash

SSH_KEY_FILE='/user/.ssh/id_rsa'
eval `ssh-agent` > /dev/null
ssh-add $SSH_KEY_FILE

drush sql-sync @site.prod @site.local

[pirog]

Alright wanted to kickstart the discussion over here again to gauge interest.

Now that we are through some of the larger foundational work to get Lando ready for the official 3.0.0 we can start looking for a few additional features to try and get rolling before that glorious day of deliverance. I personally think some level of ssh-agent support would be a good idea here.

Does anyone here eg @sk33lz or @dnotes or @ba66e77 or @jaydansand or @dustinleblanc or @serundeputy have a proposal on how to do that that would require the least amount of changes and moving parts on the lando side of things?

Also note that as of Lando 3.0.0-rc.2 we are injecting ALL keys into each container, including passphrase protected ones.

[lslinnet]

@pirog I haven't tried out 3.0.0-rc.2 yet, but do you by injecting also mean that a ssh-agent gets started in the containers?

[pirog]

@lslinnet no, i just mean that passphrase protected keys are available in the containers now. The comment at #478 (comment) was basically an RFP for how to take all those injected keys and make sure they are loaded into an ssh-agent that is accessible in each apps containers

[geerlingguy]

Just asking, since I was kind of roped into an outside discussion about this issue: how are the keys made available inside the containers? One of the concerns raised earlier in the thread was about one of the security protection SSH Agent offers is the fact that it is much harder (or impossible) to exfiltrate SSH keys off a local workstation if password protection is used.

But even if not, I can use SSH Agent and my keys never hit disk / readable volumes on a remote server (or in this case docker container), so no applications running inside that server/container could conceivably access them unless they also have access to the SSH Agent itself.

Is the current implementation (as of rc2) copying SSH keys from ~/.ssh into the container? Or is it looking at SSH Agent, reading out the list of loaded keys, and copying those in? Or is it a volume mount?

If so that seems like a major security risk, as the Docker images used for various services are not all owned by lando on GitHub, so I would need to be monitoring all the upstream images for potential security vulns that could allow the exfiltration of my SSH keys through one of the containers. (E.g. MySQL uses bitnami/mysql by default, Apache uses bitnami/apache—it looks like PHP at least uses a Lando-supplied image devwithlando/php).

[dnotes]

I agree with Jeff; copying ssh keys into containers worries me. For another approach, check out how Docksal does this; they have an ssh-agent service container which shares ssh-agent proxy connections with all other containers. It may also be possible to just share the ssh-agent sockets directly with individual docker containers—one would be asked for passwords with each project restart, which seems ok or better—and you can find documentation for this approach if you search for ssh-agent docker container or something like that. Basically it's just a --volume share, but there are some intricacies that I don't know about. I'm not a devops or security expert, and I don't know the ramifications of this, but intuitively I feel that either one of these options would be better than copying ssh keys into containers.

…

On Tue, Feb 19, 2019 at 10:59 AM Jeff Geerling ***@***.***> wrote: Just asking, since I was kind of roped into a discussion about this issue: how are the keys made available inside the containers? One of the concerns raised earlier in the thread was about one of the security protection SSH Agent offers is the fact that it is much harder (or impossible) to exfiltrate SSH keys off a local workstation if password protection is used. But even if not, I can use SSH Agent and my keys never hit disk / readable volumes on a remote server (or in this case docker container), so no applications running inside that server/container could conceivably access them unless they also have access to the SSH Agent itself. Is the current implementation (as of rc2) copying SSH keys from ~/.ssh into the container? Or is it looking at SSH Agent, reading out the list of loaded keys, and copying those in? Or is it a volume mount? If so that seems like a major security risk, as the Docker images used for various services are not all owned by lando on GitHub, so I would need to be monitoring all the upstream images for potential security vulns that could allow the exfiltration of my SSH keys through one of the containers. (E.g. MySQL uses bitnami/mysql by default, Apache uses bitnami/apache—it looks like PHP at least uses a Lando-supplied image devwithlando/php). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdyEioOKSVqR0PlH8q7sUjvJsWQffoKks5vPEl0gaJpZM4QW6nn> .

[thursdaybw]

In sk33lz's opening comment he said:

I have currently setup a workaround on the lando project level by adding a custom tooling command to our .lando.yaml file. This command forwards the agent before each remote drush command
It took me a lot of googling and trial and error to work out what that actually meant.

In my case I call a script from a tooling command that clones another repo and then pulls in gitsubmodules and I was being asked for the passphrase on every submodule.. here is my workaround:

The tooling command

 'moodle-install':
    description: Clones moodle into the correct directory and writes config.php with correct parameters
    cmd:
       - appserver: bash /app/.lando/scripts/moodle-install.sh

SSH Agent setup at start of moodle-install.sh

eval `ssh-agent -s` # start the ssh agent
ssh-add /user/.ssh/id_rsa # add the key to the ssh-agent, we are asked for the passphrase at this point, and then not again for this session.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

[dnotes]

FYI, this is the main reason why I switched to Docksal. I actually like Lando better but this is a deal-breaker for me.

…

On Sun, Apr 21, 2019 at 11:42 AM stale[bot] ***@***.***> wrote: This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this <https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea> if you are wondering why we auto close issues. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADXEET4WT72U7BYCMX7GVDPRSYPZANCNFSM4EC3VHTQ> .

[pirog]

Then it sounds like you’ve made a principled choice! We hope you enjoy docksal!

…

On Thu, Apr 25, 2019 at 7:56 PM David Hunt ***@***.***> wrote: FYI, this is the main reason why I switched to Docksal. I actually like Lando better but this is a deal-breaker for me. On Sun, Apr 21, 2019 at 11:42 AM stale[bot] ***@***.***> wrote: > This issue has been automatically marked as stale because it has not had > recent activity. It will be closed if no further activity occurs. Thank you > for your contributions and please check out this > < https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea > > if you are wondering why we auto close issues. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#478 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AADXEET4WT72U7BYCMX7GVDPRSYPZANCNFSM4EC3VHTQ > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#478 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFOFUCUF6643YKB2JTENF3PSJAKRANCNFSM4EC3VHTQ> .

[jaydansand]

I'm still very interested in this. It looks like some people had success with pure Docker via mounting the SSH agent socket into the container and setting appropriate environment variable in it:
https://gist.github.com/d11wtq/8699521

I have no idea how hard that would be to achieve in Lando, or whether it should be an opt-in or just always assumed it should be forwarded if $SSH_AUTH_SOCK is defined. I really don't like the idea of copying keys from ~/.ssh and all of the security implications that has.

[calebdelnay]

I tested the following with the Drupal 8 recipe and it allowed me to use Composer (via lando composer) against some private git repositories by running ssh-agent on my host machine (Ubuntu 18.04) to which I've added my password protected private keys.

Note that if $SSH_AUTH_SOCK isn't set due to no ssh-agent running, building the config will not work, because $SSH_AUTH_SOCK will be treated as blank, and the volume mount syntax won't be valid. For me, this is a desired behavior, because I want to ensure I start ssh-agent before any Lando services.

I haven't tested this with functionality like drush sql-sync but it should work for any command that uses ssh under the hood.

services:
  appserver:
    overrides:
      volumes:
        - "$SSH_AUTH_SOCK:/ssh_auth_sock"
      environment:
        SSH_AUTH_SOCK: /ssh_auth_sock

[pirog]

this is $%^# awesome @marji. we would love to be able to have users do something like keys: agent in their landofile and have something like ^ work OOTB. this definitely helps a ton getting us to there.

@hardyoyo this might be useful to you, i recall you were trying to do something like this recently^

[hardyoyo]

Cool, I'll give it a whirl. Thanks!

[hardyoyo]

I'm sorry to report that I cannot duplicate your results, @marji. Here are the relevant parts of my .lando.yml file:

services:
  appserver:
    type: ruby:2.5
    overrides:
   # Pass SSH auth.
      volumes:
        - type: bind
          # MacOS specific paths, source value below needs to be chaned to "$SSH_AUTH_SOCK" for Linux:
          source: /run/host-services/ssh-auth.sock
          target: /run/host-services/ssh-auth.sock
      environment:
        SSH_AUTH_SOCK: "/run/host-services/ssh-auth.sock"
    build_as_root:
        - chown www-data:www-data /run/host-services/ssh-auth.sock
        - chmod g+w /run/host-services/ssh-auth.sock

The permissions/ownership of ssh-auth.sock look right in the container. I run this command as a test:

ssh -v -i /user/.ssh/id_rsa git@github.com

on the first connection, I am asked to enter my passphrase, which is promising, however, for every subsequent connection, I am also asked to enter my passphrase.

It might help if you can indicate what version of Docker Desktop you're running? At DockerCon a few weeks ago, I heard mention of an early beta that works slightly better with keys on MacOS, but I haven't yet tracked it down to try.

[marji]

@hardyoyo, it is not working for you because you haven't added your identity to the ssh-agent from the host like I did in my above steps (which is then available inside the container via the mounted socket).

If you want to provide the passphrase for the first time from within the container, you need to tell the ssh client to add it. Your steps didn't work for me either, but I just tried creating user level ~/.ssh/config inside the container (after lando ssh):

www-data@25292bb49e84:/app$ cat ~/.ssh/config 
Host *
  AddKeysToAgent yes

First execution of ssh, it asks me for my passphrase, second execution, it does not (the ssh agent has been used).
If this works for you as well, I guess the AddKeysToAgent yes line should actually go to the generated /etc/ssh/ssh_config.

My stack as you requested:

macOS: 10.15.5
docker desktop:
  - version: 2.3.0.3 (45519)
  - channel: stable
lando: v3.0.6

BTW: your build_as_root: step works nice, thanks! The only problem with this is that you need to lando rebuild each time you restart the docker service (and each time you reboot). So I'm thinking the two commands could actually get baked inside the container as a script which gets executed when the container gets started, if this is possible. I originally wanted to use the post-start event, but that one cannot execute the commands as root.

[hardyoyo]

Sorry, I neglected to mention that step, but please rest assured I did configure SSH as you suggested:

cat ~/.ssh/config
Host *
    IgnoreUnknown UseKeychain
    UseKeychain yes
    ForwardAgent yes
    IdentityFile /user/.ssh/id_rsa
    AddKeysToAgent yes

I also took the liberty of modifying the .lando.yml to match your suggestion:

    run_as_root:
        - chown www-data:www-data /run/host-services/ssh-auth.sock
        - chmod g+w /run/host-services/ssh-auth.sock

moving the build_as_root to a run_as_root section instead.

I still cannot duplicate your success, as much as I'd like to be able to do so.

ssh git@github.com
Enter passphrase for key '/user/.ssh/id_rsa':
PTY allocation request failed on channel 0
Hi hardyoyo! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
www-data@2a742c8436d8:/app$ ssh git@github.com
Enter passphrase for key '/user/.ssh/id_rsa':

[marji]

@hardyoyo Is the ~/.ssh/config you listed in the previous message from the host or from the container?
I assume (based on the IdentityFile path) that it is from within the container.
When I use your ~/.ssh/config inside my container, it sill works for me.
I'm thinking we might have different users / ids.
I use recipe: drupal8 and when I do lando ssh and execute id inside, I'm:

www-data@bae799868f80:/app$ id
uid=501(www-data) gid=20(dialout) groups=20(dialout),33(www-data)

www-data@bae799868f80:/app$ ls -l ~/.ssh/config 
-rw------- 1 www-data dialout 136 Jun 18 05:32 /var/www/.ssh/config

So I became user www-data, group www-data.
Are you the same user? I noticed you used ruby:2.5 recipe - I'm not sure whether you also get mapped to www-data:www-data. The id command executed inside should tell you.

Other output to compare - are you getting the same:

www-data@bae799868f80:/app$ env | grep SSH
SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock

www-data@bae799868f80:/app$ echo $SSH_AUTH_SOCK
/run/host-services/ssh-auth.sock

www-data@bae799868f80:/app$ ls -l $SSH_AUTH_SOCK
srwxrwxr-x 1 www-data www-data 0 Jun 18 01:32 /run/host-services/ssh-auth.sock

I myself added a post-start event to my .lando.yml which creates the user level config inside the container (if it doesn't exist already):

events:
  post-start:
    - appserver: test -e ~/.ssh/config || printf 'Host *\n  AddKeysToAgent yes\n' > ~/.ssh/config

And this is an independent command I use to verify the docker ssh auth socket has the right perms is, executed from the host:

marji@MacBook-Pro-2 ~ % docker run --rm -ti -v /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock ubuntu ls -l /run/host-services/ssh-auth.sock
srwxrwxr-x 1 501 www-data 0 Jun 18 01:32 /run/host-services/ssh-auth.sock

[marji]

I can confirm that 3 colleagues of mine on MacOS have had no trouble with their ssh passphrase being asked for more than once.
The socket permission gets fixed when lando rebuild is executed. If the docker service restarts after that (or the computer gets rebooted), it can be fixed by the executing the lando ssh-fix command. After that, the ssh passphrase is remembered.

name: my-drupal-project
recipe: drupal8

services:
  appserver:
    type: php:7.3
    overrides:
      # Pass SSH keys.
      volumes:
        - type: bind
          # Linux user: add 'export LANDO_SSH_AUTH_SOCK="${SSH_AUTH_SOCK}"' at the end of your ~/.bashrc:
          # Mac user: MacOS specific path is here as the variable default value, nothing to do.
          source: "${LANDO_SSH_AUTH_SOCK:-/run/host-services/ssh-auth.sock}"
          target: /run/host-services/ssh-auth.sock
      environment:
        SSH_AUTH_SOCK: /run/host-services/ssh-auth.sock
    run_as_root:
      - chown www-data:www-data /run/host-services/ssh-auth.sock
      - chmod g+w /run/host-services/ssh-auth.sock

events:
  post-start:
    - appserver: test -e ~/.ssh/config || printf 'Host *\n  AddKeysToAgent yes\n' > ~/.ssh/config

tooling:
  ssh-fix:
    service: appserver
    description: Fix ssh auth sock permission for MacOS users. Lando rebuild fixes the problem as well.
    cmd: "/bin/chgrp www-data /run/host-services/ssh-auth.sock && /bin/chmod g+w /run/host-services/ssh-auth.sock"
    user: root

My next step will be to have the command defined under the ssh-fix above executed on each container start - by baking it into the docker/service image in a script, e.g. under /scripts/ssh-fix.sh.

@hardyoyo Have you had any chance to get this working? If not, I would like to nail down why the above approach does not work for you.

Edit 2020/08/20 - Added a missing " in the commented export LANDO_SSH_AUTH_SOCK=... example for Linux users above.

[pirog]

Very nice @marji! I'll have to try this out when i get a few free minutes. Would love to get keys: agent support into Lando so users have a better option even if its POSIX only for now.

[rwohleb]

I can confirm that the Lando config from @marji works under Linux. I have a Linux server that's hosting a VM running Linux. Inside the VM I have Docker and Lando running. I have ForwardAgent enabled on both my local machine as well as the Linux install inside of the VM. I have keys successfully being passed through the entire chain.

[hardyoyo]

Sorry for the delayed response, I have confirmed the same results as everyone above. Ideally there would be a way tell Docker to mount the ssh-auth.sock with the correct permissions without any additional chmod/chgrp work required. However, this does work as described. Thanks!

[hanoii]

From a comment by @calebdelnay in #478 (comment)

services:
  appserver:
    overrides:
      volumes:
        - "$SSH_AUTH_SOCK:/ssh_auth_sock"
      environment:
        SSH_AUTH_SOCK: /ssh_auth_sock

I did this on a virtual box VM (host: OSX) running linux where I forward my keys from OSX to the VM and this makes them work on the containers as well.

I didn't have issues with permissions.

I added to a .lando.local.yml file.

[michaelkotlyar]

@marji, this is great! I was still having problems with my setup, so I chucked in some more settings into my ~/.shh/config. Just in case anyone else would find this helpful...

...
events:
  post-start:
    - appserver: test -e ~/.ssh/config || printf 'Host *\n  AddKeysToAgent yes\n  ForwardAgent yes\n  ForwardX11 no\n  ForwardX11Trusted yes\n  UseKeychain yes' > ~/.ssh/config
...

[Xilonz]

@marji, that works really nice. It seems to work with unmounting the home dir so we'll get a nice performance boost as well as working ssh-keys 💯

[swarad07]

Came here from this #2635, I can also confirm that change by @marji works. 💯

If we unmount the home directory, ssh keys are not accessible. After that, I made the changes as suggested by @marji and it works, without sacrificing the fix in #2635

Thank you. 👍

[vladdancer]

Thank you @marji , you've saved my day!

[colans]

@pirog To save folks the trouble of reading this entire thread (like I did), would you kindly rename this issue something like Add SSH agent support via "keys: agent"? Thanks!

[reynoldsalec]

Updated issue name and added a 4.x label...it sounds like we could add core support to guide people down this path, but for now the workaround in #478 (comment) should be a good guide.

[pirog]

FWIW this issue was really more of a catch all discussion on how SSH keys can be improved and less about a specific implementation. That said, during the course of this discussion It does seem like we are all agreed that an agent based implementation is a good idea and should be part of Lando 4.

Personally i think it would make more sense to open a separate feature request for that and keep this issue open as a general discussion around ssh key improvements.

[colans]

In that case, I should mention #3357, which I just opened. It should be easy to fix that with a new configuration option.

[poindexterous]

I tested the following with the Drupal 8 recipe and it allowed me to use Composer (via lando composer) against some private git repositories by running ssh-agent on my host machine (Ubuntu 18.04) to which I've added my password protected private keys.

Note that if $SSH_AUTH_SOCK isn't set due to no ssh-agent running, building the config will not work, because $SSH_AUTH_SOCK will be treated as blank, and the volume mount syntax won't be valid. For me, this is a desired behavior, because I want to ensure I start ssh-agent before any Lando services.

I haven't tested this with functionality like drush sql-sync but it should work for any command that uses ssh under the hood.

services:
  appserver:
    overrides:
      volumes:
        - "$SSH_AUTH_SOCK:/ssh_auth_sock"
      environment:
        SSH_AUTH_SOCK: /ssh_auth_sock

Thank you! this solved my problem on Mac OS very recently. I'm able to sync now.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

[dustinleblanc]

Just wanted to report back on this, @poindexterous this works awesome with 1password ssh-agent support. I had tried to work ages ago on a more Lando-native method for doing this via a plugin, but I always had trouble in practice getting it to work, maybe because at the time I wasn't using 1password, so maybe I didn't have the agent thing working super well, but man, with 1password running, this is super convenient to have portable and secured keys, and lando just asks for my fingerprint via 1password every time I need to do an SSH action. Very cool.

[pirog]

Ahh nice thanks @dustinleblanc for getting my eyes back on this long standing issue so i can provide an update:

We are currently using an ssh-agent implementing for ssh keys in our forthcoming generic Lando 4 Service, which will be the underlying service for all future services. Works decently for me and in our GHA tests but we need to make it a bit more robust and configurable and make sure it works with all the older Lando 3 services before we roll it out. Not sure exactly when that will be because there is a lot of other stuff going on but did want to say we've made tangible progress towards this goal!