Keys never loaded

[almunnings]

cli/plugins/lando-core/scripts/load-keys.sh

Line 93 in 53eaddc

if grep -L "PRIVATE KEY" "$SSH_CANDIDATE" &> /dev/null; then

Should this be a lowercase L?

https://linux.die.net/man/1/grep
-L, --files-without-match
-l, --files-with-matches

Uppercase L means it never adds the files from the candidates?

Locally changing to a -l fixes and loads up keys.
Without it, nothing.

Without ssh keys, cant use a lot of the junk.

[almunnings]

Possibly related to https://github.com/lando/lando/issues/3091

$ lando ssh -s cli -c "ls -al /lando/keys"

...
-rw-------  1 user dialout 1811 Sep  9 06:44 lagoon-32ee3a15-b507-4591-902e-e848c300b924

$ lando ssh -s cli -c "cat /etc/ssh/ssh_config"

Host *
  User "al"
  StrictHostKeyChecking no
  UserKnownHostsFile=/dev/null
  LogLevel=FATAL

$ lando logs -s cli

cli_1        | loadkeys 11:16:12.69 INFO  ==> Scanning /lando/keys for keys...
cli_1        | loadkeys 11:16:12.70 INFO  ==> Scanning /var/www/.ssh for keys...
cli_1        | loadkeys 11:16:12.71 INFO  ==> Scanning /user/.ssh for keys...
cli_1        | loadkeys 11:16:12.72 INFO  ==> Found keys /lando/keys/lagoon-32ee3a15-b507-4591-902e-e848c300b924
cli_1        | loadkeys 11:16:12.72 DEBUG ==> Ensuring permissions and ownership of /lando/keys/lagoon-32ee3a15-b507-4591-902e-e848c300b924...
cli_1        | loadkeys 11:16:12.75 DEBUG ==> Checking whether /lando/keys/lagoon-32ee3a15-b507-4591-902e-e848c300b924 is a private key...
cli_1        | loadkeys 11:16:12.76 INFO  ==> Using the following keys: 

$ lando ssh -s cli -c "cat /lando/keys/lagoon-32ee3a15-b507-4591-902e-e848c300b924"

-----BEGIN OPENSSH PRIVATE KEY-----
...
...
...
...
...
-----END OPENSSH PRIVATE KEY-----

So it never gets past the -L to actually add the key.

Am I on the wrong hunt here? The logic looks wrong. -l would make sense. But again, I'm unsure of the reasoning behind the entire block of code.

[almunnings]

So big goose hunt on with @pirog over slack. We may have found an underlying cause for the inconsistencies. This looks like its due to a BusyBox flavour of grep.

grep -L "PRIVATE KEY" /lando/keys/a-random-key returns nothing. No status code 0.

Docker image uselagoon/php-7.3-cli-drupal if you go up the chain of FROM's is based off of FROM alpine:3.14

To upgrade grep to a gnu install, and make it work, in your Dockerfile you could add:

RUN apk add --no-cache --upgrade grep

It would appear there is some inconsistencies between the greps out there.
But thats not really a fix to a problem. Alpine will continue to use busybox grep, this continues to pop-up as a problem.

I wonder if something like busybox detection might be the answer here? Minimal impact.

if grep --help 2>&1 | grep -q -i "busybox"; then
  ... this greps crazy shit, set a diff condition
fi

https://bugs.busybox.net/show_bug.cgi?id=13151

https://lists.gnu.org/archive/html/bug-grep/2017-08/msg00010.html

[pirog]

@sonuku to add more fun to this we get status code 0 on alpine:3.13 so i'm guessing this started showing up when Lagoon bumped up to alpine:3.14.

All said and now that we understand the issue here i think we should just switch over to the -l from -L as you initially recommended. That seems like the option we want anyway and THEORETICALLY it should produce the same behavior in our none alpine:3.14 images.

[almunnings]

Yeah seems depending on your grep version (even gnu) -L is a bit fucky. Pasted in the bug reports in above comment.

[tobybellwood]

hihi - circling the square here - wherever possible we try to avoid overwriting the busybox packages, just to avoid potential complications. Thanks for digging into this @sonuku!