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 [email protected]@192.168.1.73
failed for user [email protected]@192.168.1.73
There is a double @
in it. I totally have no idea how to fix it.
knife is a command-line tool that provides an interface between a local chef-repo and the Chef Infra Server. knife helps users to manage: Nodes. Cookbooks and recipes. Roles, Environments, and Data Bags.
The knife bootstrap command is a common way to install the chef-client on a node. The default for this approach assumes that node can access the Chef website so that it may download the chef-client package from that location. The bootstrapping process involves setting up a Chef client on a node.
When running Microsoft Windows, the config. rb file is located at %HOMEDRIVE%:%HOMEPATH%\. chef (e.g. c:\Users\<username>\. chef ).
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 [email protected]@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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With