k3sup
k3sup copied to clipboard
Error when using ed25519 key
k3sup install tries to load my SSH key at ~/.ssh/id_rsa but I do not have an RSA key (I only use ed25519 these days):
$ k3sup --ip 192.168.100.10 --user chk install docker
Public IP: 192.168.100.10
ssh -i /home/chk/.ssh/id_rsa [email protected]
Error: unable to load the ssh key with path "/home/chk/.ssh/id_rsa": open /home/chk/.ssh/id_rsa: no such file or directory
Expected Behaviour
k3sup should not specify the SSH key file path unless explicitly requested to do so on the command line. The ssh command will default to using an ssh-agent if it is configured, and will default to using any default keys in ~/.ssh if they are available.
Current Behaviour
See summary above; k3sup defaults to trying to use a key file that does not exist.
Possible Solution
Steps to Reproduce (for bugs)
Context
Your Environment
-
What OS or type or VM are you using? Where is it hosted?
-
Operating System and version (e.g. Linux, Windows, MacOS):
I have a similar problem: my ssh private key exists solely on my Yubikey so there is no id file I can use... I rely on the ssh-agent.
Thanks for your interest in the project.
What possible solution would you both like to see?
I believe the correct fix is to remove the -i $HOME/.ssh/id_rsa
argument from the ssh command when k3sup runs it, unless the user explicitly sets an SSH keyfile with the --ssh-key
option.
Looking at your ssh library, I think this is what should be the default https://godoc.org/golang.org/x/crypto/ssh/agent
Sent with GitHawk
@haraldkoch what if we did the opposite? The minority (sorry :-)) of users who don't use RSA can provide a flag?
There are other scenarios where specifying a key file will fail; for example, when your ssh keys are stored on your laptop, but you're logged into a remote server using SSH agent forwarding and running k3sup from there.
I guess I didn't express this clearly before, but: the SSH client program will, by default, look for and try ssh keys with standard names in your $HOME/.ssh folder; the default, according to the man page, is ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and ~/.ssh/id_rsa
. k3sup does not need to specify them explicitly on the command line to get the functionality you want here.
Unless this is something weird about the golang SSH library in use - I'm not familiar with that?
I also have this need. I have the keys on my local machine and am trying to run k3sup on a bastion host that will be operating on a machine in a private subnet (I don't have direct access from my local machine). The SSH agent is forwarded, so can log into the machine. But, the inclusion of -i ~/.ssh/id_rsa
is mixing it up.
I'd be happy with either dropping the inclusion of the -i flag
by default (the SSH agent should pick up the default key anyways) or add another flag to specify usage of the agent. Either way. If you're not passing through the environment when executing the ssh command, the ssh command may not pick it up, since the socket for the forward is defined as SSH_AUTH_SOCK
. I'm not a go programmer, but can take a look if you want another pair of eyes on it.
This made for a negative first run experience for me.
I'm not sure why the the -i $HOME/.ssh/id_rsa
is even being added in the first place, as @haraldkoch points out ssh will do this by itself for that exact path (and other similar ones) and behave correctly for me (that is by letting SSH work out where the key is) as well.
Is there some reason k3s will fail later for this that necessitates having this fail early in this way?
Same here. I'm following the instructions and I get to this step Install Kubernetes with k3sup and k3s and I get the error above and though I can ssh into each Raspberry Pi 4, k3sup doesn't work. What is the correct workaround?
I am also hitting the same challenge, has anyone managed to find the correct way around?
Same problem here. I don't think it's that unusual to use smartcards/yubikeys etc nowadays.
This would have been such a joy but for this one slip-up. I can find no work-around for this. :(
From reading the code, any SSH agent given is used, when set in the env-var SSH_AUTH_SOCK
https://github.com/alexellis/k3sup/blob/master/cmd/install.go#L279
Folks please give that a shot and report back with steps on how to reproduce your individual error.
/set title: Error when using ed25519 key
/add label: support,help wanted,good first issue
@alexellis this title change is incorrect. The issue is not with ed25519 keys (well, maybe there is, but this issue is not about that). The issue is that k3sup fails to do agent based auth in a 'jump host' scenario
f.e. i have 3 VM's in a isolated/private network with source NAT and 1 public IP. I forward port 22 from my pub IP to one of them and call this the master. The other two VM's will be my worker nodes, but they will not be reachable from the outside directly.
Configuring the master from my workstation goes fine, since my keys are in ~/.ssh
. Then i SSH into my master (with agent forwarding). I end up with the following (where XX.XXX.XX.XXX is my pub ip):
root@hra-k3s-master:~# env|grep SSH
SSH_CONNECTION=XX.XXX.XX.XXX 46562 10.1.3.11 22
SSH_AUTH_SOCK=/tmp/ssh-xVDpsmt4Jc/agent.32682
SSH_CLIENT=XX.XXX.XX.XXX 46562 22
SSH_TTY=/dev/pts/0
root@hra-k3s-master:~# ssh-add -l
4048 SHA256:PehEC1xwH9NbMIEfsRImbjeOCY3SYa0C6pSi++YhQDk /Users/hans/.ssh/id_rsa (RSA)
root@hra-k3s-master:~# ls -al ~/.ssh/
total 24
drwx------ 2 root root 4096 May 18 21:20 .
drwx------ 6 root root 4096 May 19 18:55 ..
-rw------- 1 root root 1462 May 18 21:20 authorized_keys
-rw-r--r-- 1 root root 666 Aug 17 09:44 known_hosts
- Auth sock is available, agent has my pubkey.
- There is no priv/pub key on the master in
~/.ssh
- The workers already have my pubkey (same as on the master)
- I am able to SSH into them from the master using agent based auth.
Now on the master, i install k3sup again to be able to configure my workers, that are only reachable from the master. Next i try to join the worker(10.1.3.6) to the master(10.1.3.11):
root@hra-k3s-master:~# k3sup join --ip 10.1.3.6 --server-ip 10.1.3.11 --user root
Running: k3sup join
Server IP: 10.1.3.11
ssh -i /root/.ssh/id_rsa -p 22 [email protected]
ssh: sudo cat /var/lib/rancher/k3s/server/node-token
K10b0645ee47ee59f732fcf3c5b1e5cebf66d56651a9180aae796f1acfa4b629838::server:a09ad45f0b5e315e879f92f715b92a90
Error: unable to connect to 10.1.3.6:22 over ssh: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
My workaround so far has been to just generate a new SSH keypair on the master, ssh-copy-id that to the workers, and join the workers, but it would be great if this scenario works.
This is what you wrote in your report
k3sup install tries to load my SSH key at ~/.ssh/id_rsa but I do not have an RSA key (I only use ed25519 these days)
Thank you for taking the time to explain the issue with more context.
So it seems like there may be two issues:
-
It seems that the ed25519 key isn't being loaded. Can you try to reproduce this in a basic scenario where the host is reachable and raise a separate issue if so? The output message showing
-I
is also confusing people, so I have completely removed it from k3sup. -
There seems to be a story about using a jump host to shell into other hosts on another network. This seems like a separate and very specific use-case. I would like full instructions for repo, ideally with something anyone can run easily at no cost, maybe docker containers could provide that?
Your input and help debugging / experimenting is also appreciated.
Alex
I think I have both of those issues; and can help unroll this problem.
I can confirm I am not doing any weird stuff with ssh agents upfront, and I just have a (preferred ed25519) ssh key on my workstation filesystem, alongside some others. I prefer to use ed25519, at least until I roll up on software that has some problem with ed25519, at which point I would usually quickly give up and switch to RSA, moving on. But I landed at this thread trying to figure out what I had done wrong, and instead, just got even more confused by the thread (before ultimately figuring it out.)
The ssh client ("ssh" itself) discovered my key properly without any agent configuration, and target host was allowing keyed login without a password, using the id_ed25519 by default, but k3sup was not picking this up.
$ k3sup install --ip $IP --user yebyen
Running: k3sup install
Public IP: 10.17.12.106
Error: unable to connect to 10.17.12.106:22 over ssh: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
Then tried running:
eval `ssh-agent`; ssh-add ~/.ssh/id_ed25519
and repeating the same k3sup incantation resulted in the same ssh error, no change from before. I was trying to narrow down for k3sup what key I wanted to use, by attaching an SSH agent to my TTY and loading the preferred key into it, assuming a lot here I guess as I have no reason to believe other than intuition that I can interface with k3sup this way. At this point after seeing it didn't work, I looked at --help
and found the --ssh-key
option, ...
...which can in fact accept an ed25519 key. I ran:
$ k3sup install --ip $IP --user yebyen --ssh-key ~/.ssh/id_ed25519
Running: k3sup install
Public IP: 10.17.12.106
[INFO] Finding release for channel v1.18
... 👍🥳🎉✅💰
It worked!
I guess there are two things here, one is a UX bug that might just be a mismatch of my expectations, since the canonical openssh client scans through keys on disk in a certain way, trying multiple key in a path until exhausted, and k3sup apparently just picks the first likely key, this is up to you seems like reasonable behavior to me. I could forgive k3sup for picking one key by default and letting me supply another if it was wrong, I think that key scanning behavior is surprisingly convenient but as a surprise also questionable.
In any case there does not appear to be a problem with ed25519 keys, k3sup can apparently accept an ed25519 key in the --ssh-key
parameter just fine.
But I guess there is no support for ssh agents, or forwarded SSH credentials through ssh auth sock.
@alexellis the issue is simple : why are you micro-managing ssh when you should not ? You are making wrong assumptions on supposedly default ssh config resulting in problems that should not even be relevant to k3sup.
For me, I do not have ssh key files: my ssh key resides on my Yubikey.
╔ ☕️ strings:~/Downloads/tmp/k3
╚ᐅ ls ~/.ssh
config known_hosts
My .zshrc
contains this:
# Start GPG agent
export GPG_TTY=$(tty)
if [[ `uname` == 'Linux' ]]; then
export SSH_AUTH_SOCK="/run/user/$UID/gnupg/S.gpg-agent.ssh"
else
# Add GPG Suite binaries to the path:
export PATH=/usr/local/MacGPG2/bin:$PATH
export SSH_AUTH_SOCK=~/.gnupg/S.gpg-agent.ssh
fi
gpg-connect-agent updatestartuptty /bye >/dev/null
The above bit can be seen in my current shell like so:
╔ ☕️ strings:~/Downloads/tmp/k3
╚ᐅ env|grep SSH
SSH_AUTH_SOCK=/Users/gene/.gnupg/S.gpg-agent.ssh
This setup worked fine with ssh-copy-id [email protected]
and I can ssh to it now without being prompted yet the following occurs when trying to use k3sup
:
╔ ☕️ strings:~/Downloads/tmp/k3
╚ᐅ ping -c1 doublequad.local
PING doublequad.local (192.168.15.223): 56 data bytes
64 bytes from 192.168.15.223: icmp_seq=0 ttl=64 time=3.360 ms
--- doublequad.local ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.360/3.360/3.360/0.000 ms
╔ ☕️ strings:~/Downloads/tmp/k3
╚ᐅ k3sup install --ip 192.168.15.223 --user pi --no-extras
Running: k3sup install
Public IP: 192.168.15.223
Error: unable to load the ssh key with path "/Users/gene/.ssh/id_rsa": unable to read file: /Users/gene/.ssh/id_rsa, open /Users/gene/.ssh/id_rsa: no such file or directory
For additional context, here are the other files that play into this setup?
╔ ☕️ strings:~
╚ᐅ cat .gnupg/gpg-agent.conf
default-cache-ttl 28800
max-cache-ttl 28800
default-cache-ttl-ssh 28800
max-cache-ttl-ssh 28800
enable-ssh-support
pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac
╔ ☕️ strings:~
╚ᐅ cat .gnupg/gpg.conf
auto-key-retrieve
keyid-format 0xlong
with-fingerprint
list-options show-uid-validity
verify-options show-uid-validity
use-agent
personal-cipher-preferences AES256 AES192 AES CAST5
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
no-emit-version
2. There seems to be a story about using a jump host to shell into other hosts on another network. This seems like a separate and very specific use-case. I would like full instructions for repo, ideally with something anyone can run easily at no cost, maybe docker containers could provide that?
Your input and help debugging / experimenting is also appreciated.
Alex
Hi @alexellis,
not sure if you've already done some testing wrt this issue or not, but here's a very simple docker compose file and an SSH config, which should hopefully demonstrate the issue a bit. I'm happy to improve it if something is missing or unclear!
For me the issue is that I have several settings in my SSH config (jump hosts, keys + signed keys), which are ignored by this application.
Thanks!
i using ssh config file as below, and dint use standart id_rsa.
When i start k3sup i has error
Error: unable to load the ssh key with path "/home/ne/.ssh/id_rsa": unable to read file: /home/ne/.ssh/id_rsa, open /home/ne/.ssh/id_rsa: no such file or directory
then i copied my keys to id_rsa, and i has
over ssh: ssh: handshake failed: ssh: unable to authenticate, attempted methods [publickey none], no supported methods remain
no way from user, from root and changes on server ssd_config doesnt matter.
i have no idea, what next.
cat config
#HostName 192.168.0.*
# IdentitiesOnly yes
# User ne
# IdentityFile /home/ne/.ssh/fh.keys/fh
Host chromia
HostName chromia
#IdentitiesOnly yes
User ne
IdentityFile ~/.ssh/fh
connect via ssh chromia, ssh root@chromia - is succesfull. Problem is only k3sup
Hi,
@johnmccabe added instructions and support for Yubikeys and SSH agents.
Perhaps you could use that?
We also need people to raise their own issues so we get all the context required to help.
Alex
There are various requests here which are all mixed together.
K3sup supports SSH agents, so should cover these use-cases. Feel free to raise your own issues if you are Sponsors.
/lock: stale