running knife gives me double @ at the address part

Question

I don't know what is wrong with my settting:

siegfried@ubuntu:~/chef-repo$ knife ssh -a ipaddress 'name:chefnode' 'uptime'        

WARNING: Failed to connect to  -- Net::SSH::AuthenticationFailed: Authentication       failed for user siegfried@192.168.1.73@192.168.1.73

failed for user siegfried@192.168.1.73@192.168.1.73

There is a double @ in it. I totally have no idea how to fix it.

Would probably be good to send a bug report / PR to Chef Lol ... 2 years on this is still sending people into rabbit holes (eg. Me) ... — Just Lucky Really, Nov 05 '16 at 21:11

score 6 · Answer 1 · edited May 23 '17 at 10:31

Not yet 100% sure what is going on but I believe the double "@" is just a print message (it is not actually trying to connect to that host). The double comes from:

# net-ssh-multi-1.2.0/lib/net/ssh/multi/server.rb
#
192       rescue Net::SSH::AuthenticationFailed => error
193         raise Net::SSH::AuthenticationFailed.new("#{error.message}@dude#{host}")
194       end

I have so cleverly added the word "dude" here which we can see in my output:

user@ubuntu:~/chef-repo$ knife ssh 'name:ep1' uptime
WARNING: Failed to connect to ep1.site.com -- Net::SSH::AuthenticationFailed: Authentication failed for user user@ep1.site.com@dudeep1.site.com

Seems like some type of a bug but not our problem. I'm going to keep debugging but probably something along the lines of @Carolyn's suggestion https://stackoverflow.com/a/22439127/851145.

Update

Indeed the double "@" was a complete red herring. For me the solution was to simply specify the password with --ssh-password (I have not installed keys on the remote endpoint).

knife ssh 'name:ep1' uptime --ssh-password password

So probably an issue with key or password. -VV is your friend.

thanks that really solved this issue, but if you a way not writing the password in clear text, please share — Roger Rabbit, Jul 02 '14 at 11:17
Had the same issue.. I was using a -i with key... but the file didn't exist and that was giving same error. Before trying this... will it be possible to try a normal ssh -i key user@host? if that fails it is solved — sujaisd, Apr 13 '15 at 15:05
Had this strange output sending me into a rabbit hole today Lol ... Turned out I had a typo in the `knife[:identity_file]` value — Just Lucky Really, Nov 05 '16 at 21:09

score 2 · Answer 2 · answered Nov 19 '14 at 08:48

In order to resolve this issue, first check the client node and check whether root access is provided. Check the file /etc/ssh/sshd_config file and change the permitrootaccess to Yes. Stop ssh and the again start

or else use --sudo along with any username and password in the command

score 1 · Answer 3 · answered Sep 16 '14 at 18:50

I had this very same error; what I did to resolve it was simply add -P as part of the knife ssh command that I was running. knife ssh by default tries to use key-auth if it's not explicitly told to use password auth.

Sample of bad running command: knife ssh "role:*" "uptime" -x <user>

Sample of fixed running command: knife ssh "role:*" "uptime" -x <user> -P

score 1 · Answer 4 · answered Jul 06 '15 at 23:36

1

This problem is usually caused by not having the right private key PEM file added to your local ssh agent. Doing something like:

$ ssh-add

answered Jul 06 '15 at 23:36

sjn

171
1
1
7

This was sort of the answer for me. Typing ssh-add wasn't enough. I had to specify all the keys of all the machines being SSH'd into. Once they were all loaded in to the keychain, the double user@foo@foo thing disappeared. – Eric Lubow Mar 08 '17 at 02:39

score 1 · Answer 5 · edited May 27 '16 at 02:24

1

Try with this command:

knife ssh 'name:node1.example.com' -P "redhat" chef-client

Here node1.example.com is the target machine. -P the password of root user.

edited May 27 '16 at 02:24

buczek

2,011
7
29
40

answered May 27 '16 at 01:05

user6388671

11
1

Great answer; the password must still be entered, but at least it is not preserved in history (instead in the Enter you password: command). Still not sure why this issue exists as I can easily ssh into all boxes and set up chef-server correctly (or so I thought). Thanks! – tigeruppercut Mar 31 '17 at 03:36

score 0 · Answer 6 · answered Mar 04 '14 at 22:24

0

You have an extra search in your command. What you want is:

knife ssh 'name:chefnode' 'uptime'

answered Mar 04 '14 at 22:24

Michael Goetz

410
2
5

no..if i dont state -a ipaddress.. it will use fqdn which i dont have any dns applied on. and you will still get something like: "for user siegfried@ubuntu.gateway.2wire.net@ubuntu.gateway.2wire.net" – user2124498 Mar 04 '14 at 22:57
what is shown if you run 'knife show node chefnode -a ipaddress'? – Michael Goetz Mar 05 '14 at 21:41
siegfried@ubuntu:~/chef-repo$ knife node show chefnode -a ipaddress chefnode: ipaddress: 192.168.1.73 – user2124498 Mar 06 '14 at 06:28
I'm not sure why you are getting two ip addresses then. Do you have some sort of ssh alias config on your system that might be adding the extra information? – Michael Goetz Mar 06 '14 at 22:28

score 0 · Answer 7 · answered Mar 16 '14 at 15:55

I just ran into the same problem. After re-running my knife command with the option -VV, I could see in the debug output that it was unable to load my ssh key.

could not load public key file `c:/Users/Carolyn/.ssh/id_rsa': Net::SSH::Exception (public key at c:/Users/Carolyn/.ssh/id_rsa.pub is not valid)

Turns out my private key was created by PuTTY and wasn't in the right format. The key header looked like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,DA9126F8AA3ED553

After I replaced my private and public key with keys generated using ssh-keygen, knife worked without problems. Now my private key header looks like this:

-----BEGIN RSA PRIVATE KEY-----

score 0 · Answer 8 · answered Dec 11 '14 at 17:17

0

Delete ALL NODES IN YOUR CHEF, THAT DONT REALLY EXISTS (not active, chef cannot reach them etc.) and it would solve your problem. Really.

answered Dec 11 '14 at 17:17

d.ansimov

2,131
2
31
54

score 0 · Answer 9 · answered Jan 12 '15 at 08:12

0

Add your workstation's public key to target node's root .ssh/authorized_keys

answered Jan 12 '15 at 08:12

user200778

164
2
5

score 0 · Answer 10 · answered Apr 06 '17 at 17:41

For me the solution was to ensure that my local ssh-agent had both keys to the bastion host AND the target node. Once that was the case, a command like this worked. In other words:

Given I am using a bastion host

And I have 2 distinct ssh key pairs; 1 to get from workstation to the bastion host and another to get from the bastion host into the target nodes

And the output of ssh-agent -l from my workstation is

2048 SHA256:yyyyy /Users/me/.ssh/id_rsa (RSA) 2048 SHA256:zzzzz /Users/me/.ssh/internal-vpc-private-rsa-key (RSA)

When I run a command like:

knife ssh "$CHEF_SEARCH_QUERY" interactive \ --config knife.rb \ --ssh-gateway $JUMPBOX_IP \ --ssh-user $SSH_USER \ --attribute 'cloud.public_ipv4'

Then N interactive ssh sessions are established with the target hosts

score 0 · Answer 11 · answered Jul 21 '17 at 07:38

0

Just get the right login credential for your client node. i fixed by adding knife ssh -i "name:*" ""

answered Jul 21 '17 at 07:38

Turs Jacky

1

score 0 · Answer 12 · answered Aug 10 '22 at 14:50

0

My issue ended up being the type of key I was using. I was using ed25519 but the version of Chef that I was using does not support ed25519. @krsyoung is absolutely correct that -VV is your friend.

answered Aug 10 '22 at 14:50

Chris Christensen

192
1
2
18

running knife gives me double @ at the address part

12 Answers12