Vagrant: Can't execute sudo commands on machine that requires tty to run sudo

[jonathanq]

I ran in to an issue with vagrant-aws that was documented at https://github.com/mitchellh/vagrant-aws/issues/10

However as I dug into it and found the root of the issue, it appears to be with vagrant itself. The short version is that Vagrant's SSH code doesn't allow calling sudo commands against a remote machine that requires a tty to execute sudo commands. The error message returned is sorry, you must have a tty to run sudo. I assume this security feature is only enabled on CentOS, Amazon Linux (and probably other RHEL based AMIs) but not Ubuntu. But I haven't tested against an Ubuntu instance to verify. I expect I haven't hit this before with vagrant 1.0.x because all of the .box files I used allowed sudo commands to be run without requiring a tty. While the AMIs I am using now with the vagrant-aws plugin do have this setup.

I tried to change https://github.com/mitchellh/vagrant/blob/master/plugins/communicators/ssh/communicator.rb to use Net::SSH request_pty method (http://net-ssh.rubyforge.org/ssh/v2/api/index.html). But I wasn't able to get it to work. However I suspect that is mostly to do with my limited experience with Ruby.

[mitchellh]

Ptys are really really really nasty. It is easiest to just use images that don't require tty with sudo. Vagrant itself assumes that sudo requires no password (it is one of the requirements of the Vagrant user on the remote machine).

[jonathanq]

I was able to get around the issue by commenting out the requiretty in the /etc/sudoers file (based on http://unix.stackexchange.com/questions/49077/why-does-cron-silently-fail-to-run-sudo-stuff-in-my-script).

Doing that will allow vagrant to run on an Amazon Linux AMI. Given that I need to create my own AMI with Chef already installed for testing anyway, I will just make sure this change is also included on that AMI and it will work.

[blalor]

I think this should be reopened; the error doesn't give the user any information about what actually failed. And while it may be easier for you to require that the target host's sudo configuration compiles with what Vagrant expects, it limits the usefulness of Vagrant. Yes, I just ran into this problem with a 3rd-party Fedora 18 AMI. :-)

[blalor]

Work-around, assuming your AMI supports cloud-init: use the following for aws.user_data:

#cloud-config
write_files:
-   path: /etc/sudoers.d/999-vagrant-cloud-init-requiretty
    permissions: 440
    content: |
        Defaults:ec2-user !requiretty

cloud-init is responsible for creating the ec2-user account, and its sudo rights are set (at least for the Fedora 18 AMI I'm experimenting with) via /etc/sudoers.d/90-cloud-init-users. I didn't see a way set !requiretty via the users section of the yaml data, but this workaround seems to work fine.

References:

• https://cloudinit.readthedocs.org/en/latest/topics/examples.html#writing-out-arbitrary-files
• http://www.zimbra.com/forums/installation/10553-solved-sudo-sorry-you-must-have-tty-run-sudo.html
• http://linuxreference.wordpress.com/2010/11/22/disable-requiretty-in-etcsudoers/

I still think Vagrant should do its best to honor the principle of least surprise.

[geof2001]

have you tried doing

ssh -t host sudo command

[briandoconnor]

I agree with @blalor, this took me a couple hours to debug (until I found this page, thanks to you guys for a workaround!). A better error message would have gone a long way to reducing that. And just saying use a distro that allows this isn't great because there are a lot of folks that want to use the Amazon distro. So not supporting that will make an excellent project look broken from a users perspective (at least from the AWS side).

Also, for the latest Amazon AMI (Amazon Linux AMI 2013.03.1) I could not get the "write_files" cloudinit to work. Not sure why. So in my Vagrantfile I have this:

aws.user_data = File.read("user_data.txt")

And that files looks like:

#cloud-config
runcmd:
  - echo 'Defaults:ec2-user !requiretty' > /etc/sudoers.d/888-vagrant-cloud-init-requiretty

[rajivr]

@briandoconnor Amazon Linux AMI doesn't support "write_files" in its version of cloud-init. You can see the list of supported cloud-init actions here http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonLinuxAMIBasics.html#CloudInit

I also had to force vagrant to close its initial connection for this to work on Amazon Linux!

[gondo]

+1 for reopen. Amazon Linux AMI is too popular to be ignored/not supported out of the box

[kevinwood75]

ssh -t 'sudo service ntpd restart;exit' //this works

[emyl]

+1 for reopen. Maybe you can consider adding a configuration variable, like config.ssh.use_pty

[nictrix]

+1 for reopen. Looks like you can add request_pty to the line 280: https://github.com/mitchellh/vagrant/blob/master/plugins/communicators/ssh/communicator.rb

So it would end up looking like: channel = connection.open_channel.request_pty

However, when adding it to my local install it appears vagrant has problems with other steps used with SSH.
Errors out here: vagrant-1.2.7/lib/vagrant/batch_action.rb:63

[default] Rsyncing folder: /opt/cookbooks/apache/ => /vagrant
[default] Terminating the instance...

I'm assuming there's something going on with threading or how stdout is grabbed when using the sudo command on line 277 sudo -H #{shell}

[nictrix]

Actually instead of adding request_pty to open_channel, add a new line below that: ch.request_pty and it should work.

[davent]

nictrix: I came up with the same solution. However, to get around the fact that the request_pty breaks everything else I created a new ssh option and enabled the new functionality in the Vagrantfile:

config.vm.provider :aws do |aws, override|
...
override.ssh.request_pty = true
...
end

I have forked the MASTER branch and commit my changes here: https://github.com/davent/vagrant

changed files are:

plugins/communicators/ssh/communicator.rb
config/default.rb
plugins/kernel_v2/config/ssh.rb

NOTE:

I am not saying this is perfect :) and I am new to vagrant so I am sure this is not technically the correct way to do this, but it worked for me :)

[mikelococo]

+1 to reopen. There are now forks and fix proposals that haven't been reviewed. Another approach is to not use sudo at all when the root user / key is supplied to vagrant.

[dougireton]

+1 to reopen. We are hitting this issue with the default CentOS cloud image

On the AWS ec2 instance, commenting out this line in /etc/sudoers allows vagrant provision to succeed:

Defaults requiretty

[DavidWittman]

:+1: I'd like to see this reopened due to issues with the CentOS images on Rackspace Cloud as well.

[pdeschen]

+1 to reopen

[wasmum]

+1 CentOS, primary images.

[revmischa]

+1 for standard Amazon Linux AMI support

[ampedandwired]

+1 also for making this work in Vagrant core. AWS provider is effectively broken out of the box for the standard Amazon Linux images without it. @briandoconnor workaround sort of works, but I'm finding there's a race during the first "vagrant up" that means the provision will usually fail first time around (but works after that).

[mitchellh]

You can now do config.ssh.pty as of Vagrant 1.4 to get a tty. BOOM!

[nictrix]

Awesome, appreciate it!

[ampedandwired]

That's fantastic news, thanks!

[cooniur]

config.ssh.pty = true does the trick for me! Cool!

[atulatri]

config.ssh.pty is just a workaround to problem.

Can't we hint vagrant to not use sudo in remote commands by introduction some config like
config.ssh.user.privileged = true

This can come handy when using root (or any other privileged user to) configure/provision the guest machine.

[ghost]

@atulatri That would ne nice.

@mitchellh Can you explain why PTYs are so nasty?

[ddarbyson]

Seems like config.ssh.pty option isn't working with vagrant-aws plugin
https://github.com/mitchellh/vagrant-aws/issues/340

[ozbillwang]

config.ssh.pty option is really a bad way which generates un-forecast issues and no debug information you can see any more.

I fixed it by comment the line of Defaults requiretty in /etc/sudoers

Here is the detail explanation for this option

# Disable "ssh hostname sudo <cmd>", because it will show the password in clear.
#         You have to run "ssh -t hostname sudo <cmd>".
#
# Defaults    requiretty

[revmischa]

I suppose you think I used that option out of pure spite for all vagrant developers?
Thanks for that fix btw. lol.

[ghost]

The whole _requiretty_ thing was ment as a security feature after all, wasn't it?

As far as I know there's a difference between a pty and a tty. _requiretty_ means to me, that it's required to have a tty (= e.g. physically attached) instead of a pseudo-device (= e.g. via SSH).

Can someone clarify this to me?

[ozbillwang]

It is bug and fixed by redhat at March 2014.

* Mon Mar 10 2014 Daniel Kopecek <[email protected]> - 1.8.8-3
- remove bundled copy of zlib before compilation
- drop the requiretty Defaults setting from sudoers

default requiretty is problematic and breaks valid usage, confirmed by Redhat.

[revmischa]

Yeah. I have a realllly old vagrantfile lol.

[oculushut]

Looks like the sudo version on my CentOS 7 box is older than the one where bug was fixed:

[git@gitclient janus-server]$ sudo -V
Sudo version 1.8.6p7
Sudoers policy plugin version 1.8.6p7
Sudoers file grammar version 42
Sudoers I/O plugin version 1.8.6p7

This is my box: https://atlas.hashicorp.com/oculushut/boxes/vagrant-centOS64-oculushut

Looks like I may need to add that !requiretty line back in then...

[ursachec]

Thanks to you @blalor , a two hour debugging session on a Friday night ended with an actual result.
Disabling requiretty solves the issue like a charm

[Jakobud]

For anyone coming across this issue on CentOS 7, you can fix it by doing # sudo visudo and then commenting out the line

Defaults    requiretty