Support for ed25519 ssh keys

[hojerst]

When trying to create a cluster with a ED25519 SSH key, the command fails with an error:

parse key failed:ssh: cannot decode encrypted private keysparse key failed:ssh: cannot decode encrypted private keysparse key failed:ssh: cannot decode encrypted private keys2018/03/06 00:54:28 parse key failed:ssh: cannot decode encrypted private keys

Is it possible to support non-rsa keys?

[martinseener]

Hi, today i tried it with my ed25519 key on macOS w. kube v0.0.3 using the following command:

hetzner-kube ssh-key add --name mykey-ed25519 --private-key-path "~/.ssh/id_ed25519" --public-key-path "~/.ssh/id_ed25519.pub"

and it worked with the following output

sshKeyAdd called
SSH key mykey-ed25519(48750) created

[martinseener]

Ahh but i see where the problem is. While adding such a key works, using it is the actual issue. When trying to build a cluster with an ED25519 key (instead of RSA), the following issue arises:

user@macos:~$ ./hetzner-kube-darwin-amd64 cluster create --name Gitlab-CI --ssh-key mseener-ed25519
2018/05/15 14:10:48 Creating new cluster

NAME:Gitlab-CI
MASTERS: 1
WORKERS: 1
ETCD NODES: 3
HA: false
ISOLATED ETCD: false
2018/05/15 14:10:52 creating server 'Gitlab-CI-master-01'...
2018/05/15 14:10:52 loading server 'Gitlab-CI-master-01'...
2018/05/15 14:10:52 Created node 'Gitlab-CI-master-01' with IP x.x.x.x
2018/05/15 14:10:52 creating server 'Gitlab-CI-worker-01'...
2018/05/15 14:10:52 loading server 'Gitlab-CI-worker-01'...
2018/05/15 14:10:52 Created node 'Gitlab-CI-worker-01' with IP x.x.x.x
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x128d4f0]

goroutine 27 [running]:
github.com/xetys/hetzner-kube/pkg/clustermanager.(*SSHCommunicator).RunCmd(0xc420174d20, 0xc42049cce0, 0x13, 0x1514622, 0x4, 0x0, 0xc4204928c0, 0xd, 0xc4204928f0, 0x9, ...)
	/home/david/go/src/github.com/xetys/hetzner-kube/pkg/clustermanager/ssh_communicator.go:44 +0xf0
github.com/xetys/hetzner-kube/pkg/clustermanager.(*NodeProvisioner).packagesAreInstalled(0xc42008dea8, 0xc42049cce0, 0x13, 0x1514622, 0x4, 0x0, 0xc4204928c0, 0xd, 0xc4204928f0, 0x9, ...)
	/home/david/go/src/github.com/xetys/hetzner-kube/pkg/clustermanager/provision_node.go:52 +0x91
github.com/xetys/hetzner-kube/pkg/clustermanager.(*NodeProvisioner).Provision(0xc4201b1ea8, 0xc42049cce0, 0x13, 0x1514622, 0x4, 0x0, 0xc4204928c0, 0xd, 0xc4204928f0, 0x9, ...)
	/home/david/go/src/github.com/xetys/hetzner-kube/pkg/clustermanager/provision_node.go:31 +0x97
github.com/xetys/hetzner-kube/pkg/clustermanager.(*Manager).ProvisionNodes.func1(0xc420346400, 0xc42018a7e0, 0xc42018a840, 0xc42049cce0, 0x13, 0x1514622, 0x4, 0x0, 0xc4204928c0, 0xd, ...)
	/home/david/go/src/github.com/xetys/hetzner-kube/pkg/clustermanager/cluster.go:76 +0x1b8
created by github.com/xetys/hetzner-kube/pkg/clustermanager.(*Manager).ProvisionNodes
	/home/david/go/src/github.com/xetys/hetzner-kube/pkg/clustermanager/cluster.go:84 +0x189

[xetys]

is that still an issue?

[martinseener]

Hi @xetys, yes it is. Nevertheless i haven't tried it again since and currently have to time to move forward on the hetzner+kubernetes front but it didn't work in May. But as i said, haven't tried again since. If there was no change to the code that might have fixed it, it's still an issue i guess.

[ginkel]

I tried last month when it didn't work and crashed with the backtrace above.