Host ssh config file not used in containers, resulting in SSH Error: Too many authentication failures

[daggerhart]

v3.0.0-rc.23 on macOS Catalina

Very simple Lando file:

name: my-d8
recipe: drupal8

Simple Drush site alias:

prod:
  host: some-remote.com
  user: remote-user
  root: /app
  uri: https://some-remote.com

And a lot of SSH keys:

❯ ls -1 ~/.ssh
key1
key1.pub
key2
key2.pub
key3
key3.pub
key4
key4.pub
key5
key5.pub
key6
key6.pub
key7
key7.pub
key8
key8.pub
key9
key9.pub
key10
key10.pub
key11
key11.pub
# ... etc

---

In a scenario where the prod drush alias needs key13, the lando drush @prod status command will result in the Too many authentication failures error.

Normally this error can be mitigated by specifiying which key should be used for which server in your ssh config file:

❯ cat 
Host site1.com
  IdentityFile ~/.ssh/key1

Host site2.com
  IdentityFile ~/.ssh/key2

# ... etc

The Problem

The problem is that lando doesn't make the host's config the default ssh config within containers. Instead, it creates a new ssh_config file that adds each key as the identity file for all hosts -- https://github.com/lando/lando/blob/master/plugins/lando-core/scripts/load-keys.sh#L74

Mitigation

One way to mitigate this issue in a per-service way is to add a new build step:

services:
  appserver:
    build:
      - /bin/sh -c "[ -f /user/.ssh/config ] && ln -sf /user/.ssh/config /var/www/.ssh/config"

This approach of making a symlink explicitly from /user/.ssh to /var/www/.ssh is the same approach used for the known_hosts file -- https://github.com/lando/lando/blob/master/plugins/lando-core/scripts/user-perms.sh#L64

Potential Solution

A more reliable solution would be to create the symlink during the lando build process in /plugins/lando-core/scripts/user-perms.sh so that each service has the appropriate config.

Not sure what the impact of this change would be on existing lando users, but it seems that if the host machine has defined a config file, they may want that to be their config file within lando service containers.

---

Possibly related to #478

Very similar to #912 which was closed when the reporter accepted the suggestion to copy to config file into place.

I solve this by keeping a hosts file in my project folder and adding a run: step to the service:

services:
  appserver:
    run:
      - echo "Include /app/dev_assets/scripts/hosts" >> ~/.ssh/config

This allows me to use wp-cli scripts in-container with references the named hosts.

As an added benefit all members of the dev team are working off the same config of hosts and the file is in version control with the project.

[pirog]

I personally like the thinking on this and the related PR #1957.

My biggest concern with the proposed solution/pr is im guessing there are a lot of Lando users who may have set this file in the past, knowingly or unknowingly, forgotten about it and/or dont understand it and how it works. In these situations its likely Lando using their file instead of the one we generate will break other Lando things that we document working out of the box like injecting their SSH keys or things like automatic key setup like we do for the pantheon recipe. So in the risk/reward calculation my suspicion is we risk breaking things for a bunch of people to reward what appears to be an edge case eg people with a shload of keys.

That all said, it would be nice to support this in some capacity. The easiest and simplest way to do that would be creating a Lando Guide (https://docs.lando.dev/contrib/guides-intro.html) that documents how to do this.

@daggerhart beyond documentation do you have any ideas on how we could actually support this without potentially busting things for other users? Maybe there is a way to scope our config files better so both can exist? Maybe we could set a hard limit on the amount of keys we load, inform the user they may be missing keys and point them to some docs on remediation steps? Definitely open to suggestions.

[pirog]

See over here: #2031