Connecting to the remote on Fedora 33 fails with publickey error about remote-kubernetes HOT 11 CLOSED

@rberrelleza Sure, I will try it tomorrow on my work machine and I'll add my feedback here.

from remote-kubernetes.

thanks for checking, I'll update the extension as soon as possible

from remote-kubernetes.

Thanks for the thorough analysis @RedRoserade ! so, do you think if we generate ed25519 keys, that should fix the issue for everyone? (have to check if windows supports that, but my guess is that it should).

from remote-kubernetes.

I think it should, though I cannot be sure, only testing would tell. According to the Arch Wiki, ed25519 keys have been supported since OpenSSH 6.5, which dates back to 2014: https://wiki.archlinux.org/index.php/SSH_keys#Ed25519

The same algorithm is documented in Windows Server documentation, so there's a good chance it works there too: https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement

And, since these keys are used only for connecting to remote Okteto instances, it should be fine.

from remote-kubernetes.

Sounds like ed25519 is a good candidate for them. The root cause of the issue is on okteto/okteto, once okteto/okteto#1351 is merged and released, we'll update it on the plugin.

from remote-kubernetes.

We had some issues with compatibility with ed25519, so we'll start by adding the PubkeyAcceptedKeyTypes key first, while we work on supporting ed25519.

from remote-kubernetes.

I see, I was concerned that could happen. I'd say that the workaround will be good enough for now, too.

from remote-kubernetes.

@RedRoserade could you try the build from master to make sure if solves the issue? The extension has a setting to pass a binary instead of using the expected version. You can build it yourself, or use https://downloads.okteto.com/cli/master/okteto-Linux-x86_64

from remote-kubernetes.

@rberrelleza It works; after compiling locally, deleting previous ssh keys, and changing the paths, this is what I get on my ssh config:

# entry generated by okteto
Host cps-api.okteto
  ForwardAgent yes
  PubkeyAcceptedKeyTypes +ssh-rsa
  HostName localhost
  Port 36043
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  IdentityFile "/home/$USER/.okteto/id_rsa_okteto"

And most importantly, VSCode connects.

Thank you!

from remote-kubernetes.

version 0.2.1 has the fix, if you want to try it out @RedRoserade

from remote-kubernetes.

Already have, it works well. Thanks!

from remote-kubernetes.