Correctly verify ssh w/ sudo

[zenspider]

Does 2 things:

• Forces pty if we're verifying w/ @sudo (but only during verify).
• Wraps up the sudo verify command closing stdin while using sudo -Sv.

Quite a bit of cleanup in the ssh files as well, you might want to review the last commit first.

[chef-expeditor]

Hello zenspider! Thanks for the pull request!

Here is what will happen next:

1. Your PR will be reviewed by the maintainers.
2. Possible Outcomes
   a. If everything looks good, one of them will approve it, and your PR will be merged.
   b. The maintainer may request follow-on work (e.g. code fix, linting, etc). We would encourage you to address this work in 2-3 business days to keep the conversation going and to get your contribution in sooner.
   c. Cases exist where a PR is neither aligned to Chef InSpec's product roadmap, or something the team can own or maintain long-term. In these cases, the maintainer will provide justification and close out the PR.

Thank you for contributing!

[clintoncwolfe]

This line might benefit from an explanatory code comment. Especially when working in non-Ruby languages...

[codeclimate]

Code Climate has analyzed commit 0e15bb9 and detected 7 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Bug Risk	1
Style	6

View more on Code Climate.

[multani]

Hello,

we tried to upgrade from train 3.2.0 to train 3.2.5 and now our Kitchen tests are failing due to a timeout issue.
It looks like this:

$ bundle exec kitchen  verify --log-level debug
-----> Starting Test Kitchen (v2.3.4)
-----> Verifying <inspec-ec2>...
D      Initialize InSpec
D      Options {"backend"=>"ssh", "logger"=>#<Kitchen::Logger:0x00005615c94d1d88 @log_overwrite=true, @loggers=[#<Kitchen::Logger::LogdevLogger:0x00005615c94d1a40 @level=0, @progname="inspec-ec2", @default_formatter=#<Logger::Formatter:0x00005615c94d19f0 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x00005615c94d19a0 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<File:/home/test/packer/post/.kitchen/logs/inspec-ec2.log>, @mon_owner=nil, @mon_count=0, @mon_mutex=#<Thread::Mutex:0x00005615c94d1950>>>, #<Kitchen::Logger::StdoutLogger:0x00005615c94d1900 @level=0, @progname="inspec-ec2", @default_formatter=#<Logger::Formatter:0x00005615c94d18b0 @datetime_format=nil>, @formatter=#<Proc:0x00005615c94d17c0@/home/test/.gems/ruby/2.5.0/gems/test-kitchen-2.3.4/lib/kitchen/logger.rb:296>, @logdev=#<Logger::LogDevice:0x00005615c94d1860 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<IO:<STDOUT>>, @mon_owner=nil, @mon_count=0, @mon_mutex=#<Thread::Mutex:0x00005615c94d1810>>>], @logdev=#<Kitchen::Logger::LogdevLogger:0x00005615c94d1a40 @level=0, @progname="inspec-ec2", @default_formatter=#<Logger::Formatter:0x00005615c94d19f0 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x00005615c94d19a0 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<File:/home/test/packer/post/.kitchen/logs/inspec-ec2.log>, @mon_owner=nil, @mon_count=0, @mon_mutex=#<Thread::Mutex:0x00005615c94d1950>>>>, "sudo"=>true, "sudo_command"=>"sudo", "sudo_options"=>nil, "host"=>"ec2-xxx.compute.amazonaws.com", "port"=>22, "user"=>"admin", "keepalive"=>true, "keepalive_interval"=>60, "connection_timeout"=>15, "connection_retries"=>5, "connection_retry_sleep"=>1, "max_wait_until_ready"=>600, "compression"=>false, "compression_level"=>0, "bastion_port"=>22, "key_files"=>["/home/test/packer/post/.kitchen/inspec-ec2.pem"], "color"=>true, :controls=>nil, :backend_cache=>false}
D      [SSH] opening connection to [email protected]
D      [SSH] using options {:user_known_hosts_file=>"/dev/null", :port=>22, :compression=>false, :compression_level=>0, :keepalive=>true, :keepalive_interval=>60, :timeout=>15, :auth_methods=>["none", "publickey"], :keys_only=>true, :keys=>["/home/test/packer/post/.kitchen/inspec-ec2.pem"], :password=>"<hidden>", :forward_agent=>nil, :non_interactive=>false, :verify_host_key=>:never}
D      [SSH] [email protected] cmd = cmd.exe /c ver
D      [SSH] [email protected] cmd = Get-WmiObject Win32_OperatingSystem | Select Caption,Version | ConvertTo-Json
D      [SSH] [email protected] cmd = uname -s
D      [SSH] [email protected] cmd = uname -m
D      [SSH] [email protected] cmd = test -f /etc/debian_version && cat /etc/debian_version
D      [SSH] [email protected] cmd = test -f /etc/lsb-release && cat /etc/lsb-release
D      [SSH] [email protected] cmd = test -f /usr/bin/lsb-release && cat /usr/bin/lsb-release
D      [SSH] [email protected] cmd = test -f /etc/os-release && cat /etc/os-release
D      [SSH] [email protected] cmd = test -f /usr/bin/raspi-config
D      [SSH] [email protected] cmd = bash -c '(sudo -v) < /dev/null'
^C

and it sits there as sudo -v is actually expecting a password:

$ bundle exec kitchen login
...
$ sudo whoami
root
$ sudo -v < /dev/null

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for admin: 
sudo: no password was provided
$ bash -c '(sudo -v) < /dev/null' 
# does the same

In Kitchen, we used to have:

suites:
- name: inspec
  verifier:
    sudo_command: sudo # <<<
    inspec_tests:
      - ../tests
    inputs: {}

Where we are overriding the default sudo command (to prevent passing -E which failed in some setup).
Setting this value back to the default one seems to be even worse (?) though:

...
D      [SSH] [email protected] cmd = test -f /usr/bin/raspi-config
D      [SSH] [email protected] cmd = bash -c '(sudo -E -v) < /dev/null'
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Failed to complete #verify action: [Sudo failed: usage: sudo -h | -K | -k | -V
usage: sudo -v [-AknS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-AknS] [-g group] [-h host] [-p prompt] [-U user] [-u user]
            [command]
usage: sudo [-AbEHknPS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p
            prompt] [-T timeout] [-u user] [VAR=value] [-i|-s] [<command>]
usage: sudo -e [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p
            prompt] [-T timeout] [-u user] file ...
 ] on inspec-ec2
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

D      ------Exception-------
D      Class: Kitchen::ActionFailed
D      Message: 1 actions failed.
>>>>>>     Failed to complete #verify action: [Sudo failed ...

[myii]

We've also been hit by the same issues as @multani across our org. It's not affecting all platforms, though. An example:

• https://travis-ci.com/saltstack-formulas/openvpn-formula/builds/141203737

So in that run, only ubuntu-1804 and centos-6 are still performing the kitchen verify successfully. Downgrading to 3.2.0 has worked for all platforms:

• https://travis-ci.org/myii/openvpn-formula/builds/625669307

[NAshwini]

Hello @zenspider,

Even I am facing the above issue with latest Chef while bootstrapping a Ubuntu Vm, It just hang on command cmd = bash -c '(sudo -v) < /dev/null'

STACKTRACE:

PS D:\git-repo\chef> bundle exec knife bootstrap <IPAddress> --connection-user "azure" --connection-password "<PASSWORD>" -c "D:\chef-repo\.chef\knife.rb" -N ashunbutu16 --sudo -VV
INFO: Using configuration from D:/chef-repo/.chef/knife.rb
DEBUG: Checking if we need to accept Chef license to bootstrap node
DEBUG: Reading products and relationships...
DEBUG: Successfully read products and relationships
DEBUG: License acceptance required for chef version: 15
DEBUG: Searching for the following licenses: ["infra-client", "inspec"]
DEBUG: Found license chef_infra_client at C:/Users/msys/.chef/accepted_licenses/chef_infra_client
DEBUG: Found license inspec at C:/Users/msys/.chef/accepted_licenses/inspec
DEBUG: Missing licenses remaining: []
DEBUG: All licenses present
Connecting to <IPAddress>
DEBUG: [SSH] opening connection to azure@<IPAddress>
DEBUG: [SSH] using options {:user_known_hosts_file=>"/dev/null", :port=>22, :compression=>false, :compression_level=>0, :keepalive=>true, :keepalive_interval=>60, :timeout=>60, :auth_methods=>["none", "password", "keyboard-interactive"], :keys_only=>nil, :keys=>[], :password=>"<hidden>", :forward_agent=>nil, :non_interactive=>true, :verify_host_key=>:always}
The authenticity of host '<IPAddress>()' can't be established.
fingerprint is SHA256:D2/8g9PMm0cK71eGegIuS2ltC19FiDxr1ri1NjX9xck.

Are you sure you want to continue connecting
? (Y/N) y
Connecting to <IPAddress>
DEBUG: [SSH] opening connection to azure@<IPAddress>
DEBUG: [SSH] using options {:user_known_hosts_file=>"/dev/null", :port=>22, :compression=>false, :compression_level=>0, :keepalive=>true, :keepalive_interval=>60, :timeout=>60, :auth_methods=>["none", "password", "keyboard-interactive"], :keys_only=>nil, :keys=>[], :password=>"<hidden>", :forward_agent=>nil, :non_interactive=>true, :verify_host_key=>:accept_new}
DEBUG: [SSH] azure@<IPAddress>cmd = cmd.exe /c ver
DEBUG: [SSH] azure@<IPAddress>cmd = Get-WmiObject Win32_OperatingSystem | Select Caption,Version | ConvertTo-Json
DEBUG: [SSH] azure@<IPAddress>cmd = uname -s
DEBUG: [SSH] azure@<IPAddress>cmd = uname -m
DEBUG: [SSH] azure@<IPAddress>cmd = test -f /etc/debian_version && cat /etc/debian_version
DEBUG: [SSH] azure@<IPAddress>cmd = test -f /etc/lsb-release && cat /etc/lsb-release
DEBUG: [SSH] azure@<IPAddress>cmd = bash -c '(sudo -v) < /dev/null'

[ahmadbabaeimoghadam]

I have same problem, is there any solution for that?

[myii]

@omidbabaeigithub As I've mentioned in #544 (comment) above:

... Downgrading to 3.2.0 has worked for all platforms

For example:

• Gemfile