New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't execute sudo commands on machine that requires tty to run sudo #1482

Closed
jonathanq opened this Issue Mar 22, 2013 · 35 comments

Comments

Projects
None yet
@jonathanq

jonathanq commented Mar 22, 2013

I ran in to an issue with vagrant-aws that was documented at mitchellh/vagrant-aws#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

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Mar 22, 2013

Member

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).

Member

mitchellh commented Mar 22, 2013

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).

@mitchellh mitchellh closed this Mar 22, 2013

@jonathanq

This comment has been minimized.

Show comment
Hide comment
@jonathanq

jonathanq Mar 22, 2013

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.

jonathanq commented Mar 22, 2013

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

This comment has been minimized.

Show comment
Hide comment
@blalor

blalor May 5, 2013

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 commented May 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@blalor

blalor May 5, 2013

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:

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

blalor commented May 5, 2013

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:

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

@geof2001

This comment has been minimized.

Show comment
Hide comment
@geof2001

geof2001 May 10, 2013

have you tried doing

ssh -t host sudo command

geof2001 commented May 10, 2013

have you tried doing

ssh -t host sudo command

@briandoconnor

This comment has been minimized.

Show comment
Hide comment
@briandoconnor

briandoconnor May 14, 2013

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

briandoconnor commented May 14, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rajivr

rajivr May 27, 2013

@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!

rajivr commented May 27, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@gondo

gondo Jun 2, 2013

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

gondo commented Jun 2, 2013

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

@kevinwood75

This comment has been minimized.

Show comment
Hide comment
@kevinwood75

kevinwood75 Jul 11, 2013

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

kevinwood75 commented Jul 11, 2013

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

@emyl

This comment has been minimized.

Show comment
Hide comment
@emyl

emyl Jul 25, 2013

Contributor

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

Contributor

emyl commented Jul 25, 2013

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

@nictrix

This comment has been minimized.

Show comment
Hide comment
@nictrix

nictrix Aug 7, 2013

+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 commented Aug 7, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@nictrix

nictrix Aug 7, 2013

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

nictrix commented Aug 7, 2013

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

@davent

This comment has been minimized.

Show comment
Hide comment
@davent

davent Aug 9, 2013

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 :)

davent commented Aug 9, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mikelococo

mikelococo Sep 13, 2013

+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.

mikelococo commented Sep 13, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@dougireton

dougireton Sep 19, 2013

+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

dougireton commented Sep 19, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@DavidWittman

DavidWittman Sep 29, 2013

Contributor

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

Contributor

DavidWittman commented Sep 29, 2013

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

@pdeschen

This comment has been minimized.

Show comment
Hide comment
@pdeschen

pdeschen Oct 15, 2013

+1 to reopen

pdeschen commented Oct 15, 2013

+1 to reopen

@wasmum

This comment has been minimized.

Show comment
Hide comment
@wasmum

wasmum Oct 21, 2013

+1 CentOS, primary images.

wasmum commented Oct 21, 2013

+1 CentOS, primary images.

@revmischa

This comment has been minimized.

Show comment
Hide comment
@revmischa

revmischa Nov 22, 2013

+1 for standard Amazon Linux AMI support

revmischa commented Nov 22, 2013

+1 for standard Amazon Linux AMI support

@ampedandwired

This comment has been minimized.

Show comment
Hide comment
@ampedandwired

ampedandwired Dec 8, 2013

Contributor

+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).

Contributor

ampedandwired commented Dec 8, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@mitchellh

mitchellh Dec 9, 2013

Member

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

Member

mitchellh commented Dec 9, 2013

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

@nictrix

This comment has been minimized.

Show comment
Hide comment
@nictrix

nictrix Dec 9, 2013

Awesome, appreciate it!

nictrix commented Dec 9, 2013

Awesome, appreciate it!

@ampedandwired

This comment has been minimized.

Show comment
Hide comment
@ampedandwired

ampedandwired Dec 9, 2013

Contributor

That's fantastic news, thanks!

Contributor

ampedandwired commented Dec 9, 2013

That's fantastic news, thanks!

@cooniur

This comment has been minimized.

Show comment
Hide comment
@cooniur

cooniur Sep 24, 2014

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

cooniur commented Sep 24, 2014

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

@atulatri

This comment has been minimized.

Show comment
Hide comment
@atulatri

atulatri Sep 26, 2014

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.

atulatri commented Sep 26, 2014

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.

ytsarev pushed a commit to gooddata/kitchen-vagrant that referenced this issue Oct 17, 2014

Yury Tsarev
config.ssh.pty support
Main reason for introducing control over this configuration option
is a 'Defaults requiretty' in /etc/sudoers of RHEL/Centos/ScientificLinux.

See
hashicorp/vagrant#1482 (comment)
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 4, 2015

@atulatri That would ne nice.

@mitchellh Can you explain why PTYs are so nasty?

ghost commented Feb 4, 2015

@atulatri That would ne nice.

@mitchellh Can you explain why PTYs are so nasty?

@ddarbyson

This comment has been minimized.

Show comment
Hide comment
@ddarbyson

ddarbyson Feb 5, 2015

Seems like config.ssh.pty option isn't working with vagrant-aws plugin
mitchellh/vagrant-aws#340

ddarbyson commented Feb 5, 2015

Seems like config.ssh.pty option isn't working with vagrant-aws plugin
mitchellh/vagrant-aws#340

@ozbillwang

This comment has been minimized.

Show comment
Hide comment
@ozbillwang

ozbillwang Mar 5, 2015

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

ozbillwang commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@revmischa

revmischa Mar 5, 2015

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

revmischa commented Mar 5, 2015

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 5, 2015

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?

ghost commented Mar 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ozbillwang

ozbillwang Mar 5, 2015

It is bug and fixed by redhat at March 2014.

* Mon Mar 10 2014 Daniel Kopecek <dkopecek@redhat.com> - 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.

ozbillwang commented Mar 5, 2015

It is bug and fixed by redhat at March 2014.

* Mon Mar 10 2014 Daniel Kopecek <dkopecek@redhat.com> - 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

This comment has been minimized.

Show comment
Hide comment
@revmischa

revmischa Mar 5, 2015

Yeah. I have a realllly old vagrantfile lol.

revmischa commented Mar 5, 2015

Yeah. I have a realllly old vagrantfile lol.

@oculushut

This comment has been minimized.

Show comment
Hide comment
@oculushut

oculushut Mar 31, 2015

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...

oculushut commented Mar 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ursachec

ursachec Jun 19, 2015

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

ursachec commented Jun 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Jakobud

Jakobud Jun 21, 2015

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

Jakobud commented Jun 21, 2015

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

RubyTuesdayDONO added a commit to RubyTuesdayDONO/workspace that referenced this issue Nov 12, 2016

Force Vagrant SSH to request PTY
Farced Vagrant and RSpec to request
a pseudoterminal for boxen that require
a TTY for remote access (should probably
patch the machine image, but this works).

hashicorp/vagrant#1482
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment