Many Chef users encounter this frustrating scenario: knife search node name:* successfully returns nodes, but knife ssh with the same query comes up empty. Let's dive deep into why this happens and how to fix it.

The fundamental difference lies in how these commands process queries:

# Working search example
knife search node "name:web_01 OR name:admin"

# Failing SSH attempt
knife ssh "name:web_01 OR name:admin" "uptime" -VV

Even though both commands use the Chef Server API, knife ssh has additional requirements for node discovery.

• Incorrect SSH configuration in knife.rb
• Missing connection attributes in node data
• Query syntax differences between search and SSH
• Permission issues with the API user

Start by verifying your node data contains proper connection attributes:

# Check a node's attributes
knife node show web_01 -a ipaddress -a fqdn -a cloud.public_ipv4

If attributes are missing, try these fixes:

Solution 1: Explicitly Specify Connection Method

knife ssh "name:web_*" "uptime" --ssh-user ubuntu --attribute ipaddress

Solution 2: Modify Your Knife Configuration

# In knife.rb
knife[:ssh_attribute] = "ipaddress"
knife[:ssh_user] = "ubuntu"
knife[:use_sudo] = true

Solution 3: Use Manual Node Lists

When debugging, bypass the search entirely:

knife ssh "web_01,admin" "hostname" -x ubuntu -a ipaddress

Enable maximum verbosity to see API calls:

knife ssh "*:*" "date" -VVV

Check if your Chef Server is returning complete node data:

curl -H "Accept: application/json" \
-H "X-Chef-Version: 12.0.0" \
-X GET "https://chef-server/organizations/org/nodes" \
-k -u user:password

For EC2 instances, ensure cloud attributes are populated:

# Example node with proper AWS attributes
{
  "ec2": {
    "public_ipv4": "54.123.45.67",
    "local_ipv4": "10.0.1.45"
  },
  "fqdn": "web-01.example.com"
}

Then connect using:

knife ssh "chef_environment:production" "sudo chef-client" \
--ssh-user ec2-user \
--attribute ec2.public_ipv4 \
--ssh-port 22 \
--identity-file ~/.ssh/aws_key.pem

---

When working with Chef, it's frustrating when knife ssh fails to locate nodes that are clearly visible through knife search. Let's examine the exact scenario:

# Successful node search
knife search node name:*
2 items found

Node Name:   web_01
...

Node Name:   admin
...

But then attempting SSH fails:

# Failed SSH attempt
knife ssh "node:*" "uptime" -VV
DEBUG: Using configuration from /root/.chef/knife.rb
DEBUG: Signing the request as dev
DEBUG: Sending HTTP Request via GET to ec2-xx-xx-xx-xx.compute-1.amazonaws.com:4000/search/node
FATAL: No nodes returned from search!

This typically occurs due to one of several configuration issues:

• Incorrect SSH configuration in knife.rb
• Missing or incomplete node attributes
• Authentication problems with the Chef server
• Network connectivity issues

First, check your SSH settings in knife.rb:

# Sample working configuration
knife[:ssh_user] = 'your_ssh_user'
knife[:ssh_port] = 22
knife[:ssh_attribute] = 'fqdn'  # or 'ipaddress' depending on your setup
knife[:identity_file] = '/path/to/your/private/key'

The most common issue is missing SSH connection attributes. Verify your nodes have the required attributes:

# Check node attributes
knife node show web_01 -a fqdn -a ipaddress -a cloud.public_hostname

If these attributes are missing, you'll need to:

1. Ensure ohai is running properly on your nodes
2. Manually set the SSH connection attribute in knife.rb

When automatic discovery fails, you can explicitly map the connection attribute:

# Force knife to use specific attribute
knife ssh "name:web_01 OR name:admin" "uptime" --attribute cloud.public_ipv4

If the above doesn't work, verify network connectivity:

# Test direct SSH connection
ssh -i /path/to/key your_user@node_fqdn

Also check Chef server connectivity:

# Verify Chef server API access
knife client list

For persistent issues, increase debugging verbosity:

knife ssh "*:*" "hostname" -VVV

This will reveal the exact search query being sent to the Chef server and the response.