Some built-in vagrant commands don't work under `config.ssh.pty = true`

[apinstein]

gh-1601 added support for tty in the ssh config so that you can use vagrant with a sudoers setup that uses Defaults requiretty which is the CentOS default and is commented as being more secure.

I just tried upgrading my base box to use Defaults requiretty in sudoers (the CentOS default, for security purposes) and then opt-in to the new config.ssh.pty = true and now vagrant hangs every time I run reload.

Using a high debug level with vagrant reload I was able to narrow this down to to "rm" throwing up an interactive confirmation prompt, which hung the entire vagrant run:

DEBUG ssh: Exit status: 0

INFO ssh: Setting SSH_AUTH_SOCK remotely: logout

DEBUG ssh: stdout: export SSH_AUTH_SOCK=logout

[root@dev vagrant]# rm /tmp/vagrant-ifcfg-eth1


DEBUG ssh: stdout: rm: remove regular empty file `/tmp/vagrant-ifcfg-eth1'?

And I was able to verify that the rm process was hung using ps on the guest.

I believe that all of vagrant's core commands need to be audited to ensure that they work when using pty=true.

[mitchellh]

Yes, unfortunately pty has this sad effect. I pushed back on pty support for many years because it makes situations like this very difficult, but ultimately caved in because some people REALLY wanted it. The result is that there are still a lot of cases that are hard to make work well with a pty.

I've fixed the specific case you ran into: cae4a1c554af0091c6ed917c257f6a6c68fb93c2

Please do let me know if you find anymore. Thanks!

[apinstein]

Cool, thanks! Based on that advice I will probably get over trying to get it to work…

Do you by chance know the security reasoning behind requiretty? From what I could tell it was simply to prevent people from passing in passwords on the CLI which hardly seems like a big enough problem for me to worry about for devops scenarios…

On Mar 5, 2014, at 7:24 PM, Mitchell Hashimoto notifications@github.com wrote:

Yes, unfortunately pty has this sad effect. I pushed back on pty support for many years because it makes situations like this very difficult, but ultimately caved in because some people REALLY wanted it. The result is that there are still a lot of cases that are hard to make work well with a pty.

I've fixed the specific case you ran into: cae4a1c

Please do let me know if you find anymore. Thanks!

— Reply to this email directly or view it on GitHub.

[rrkulkarnise]

I have config.ssh.pty = true. I am getting following error during rsync. Command: rsync --verbose --archive --delete -z --copy-links --no-owner --no-group --rsync-path sudo rsync -e ssh -p 22 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i '/home/rk1001/keys/ca.key' --exclude .vagrant/ /vagrant/ rk1010@rk1010.cloudapp.net:/vagrant Error: Warning: Permanently added 'rk1010.cloudapp.net,137.117.66.94' (RSA) to the list of known hosts. sudo: sorry, you must have a tty to run sudo rsync: connection unexpectedly closed (0 bytes received so far) [sender]

I am using vagrant 1.6.2. The guest os is centos. Any workarounds?

[seanmcl]

I'm getting rrkulkarnise's error as well.

[tknerr]

@rrkulkarnise looks like the config.ssh.pty = true option has no effect on the rsync commandline

Can you try adding -t to the ssh portion of the rsync command line? E.g.

rsync --verbose --archive --delete -z --copy-links --no-owner --no-group --rsync-path sudo rsync -e ssh -t -p 22 ...

[fletchowns]

I'm still not able to get this to work after making the change to add -t as outlined here. Any other ideas? I was hoping to be able to avoid creating my own AMI that has the requiretty setting altered.

==> default: Rsyncing folder: /c/chef-repo/cookbooks/my-cookbook/ => /vagrant
There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.

Host path: /c/chef-repo/cookbooks/my-cookbook/
Guest path: /vagrant
Command: rsync --verbose --archive --delete -z --copy-links --chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -t -p 22 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i 'c:/Users/fletchowns/.ssh/mykey.pem' --exclude .vagrant/ /c/chef-repo/cookbooks/my-cookbook/ ec2-user@123.123.123.123:/vagrant
Error: Pseudo-terminal will not be allocated because stdin is not a terminal.
Warning: Permanently added '123.123.123.123' (RSA) to the list of known hosts.
sudo: sorry, you must have a tty to run sudo
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]

I'm using Vagrant 1.6.5

[tknerr]

Hi Greg,

do you have the chance to upgrade to a basebox / ami which does not requiretty in /etc/sudoers? https://linuxreference.wordpress.com/2010/11/22/disable-requiretty-in-etcsudoers/

HTH, Torben

On Fri, Jan 16, 2015 at 11:55 PM, Greg Barker notifications@github.com wrote:

I'm still not able to get this to work after making the change to add -t as outlined here https://github.com/audiolize/vagrant-softlayer/issues/11#issuecomment-57954978. Any other ideas? I was hoping to be able to avoid creating my own AMI that has the requiretty setting altered.

==> default: Rsyncing folder: /c/chef-repo/cookbooks/my-cookbook/ => /vagrant There was an error when attempting to rsync a synced folder. Please inspect the error message below for more info.

Host path: /c/chef-repo/cookbooks/my-cookbook/ Guest path: /vagrant Command: rsync --verbose --archive --delete -z --copy-links --chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -t -p 22 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i 'c:/Users/fletchowns/.ssh/mykey.pem' --exclude .vagrant/ /c/chef-repo/cookbooks/my-cookbook/ ec2-user@123.123.123.123:/vagrant Error: Pseudo-terminal will not be allocated because stdin is not a terminal. Warning: Permanently added '123.123.123.123' (RSA) to the list of known hosts. sudo: sorry, you must have a tty to run sudo rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(226) [sender=3.1.0]

— Reply to this email directly or view it on GitHub https://github.com/mitchellh/vagrant/issues/3063#issuecomment-70336091.

[fletchowns]

@tknerr that's what I ended up doing, using the following packer definition. Seems to be working well now. Thanks!

{
    "builders": [
        {
            "type": "amazon-ebs",
            "region": "us-west-1",
            "source_ami": "ami-fe393ebb",
            "instance_type": "t1.micro",
            "ssh_username": "ec2-user",
            "ami_name": "redhat-6.5-x86_64-vagrant {{timestamp}}"
        }
    ],
    "provisioners": [
        {
            "type": "shell",
            "inline": [
                "sudo sed -i \"s/^.*requiretty/#Defaults requiretty/\" /etc/sudoers"
            ]
        }
    ]   
}

[jakeczyz]

Any updates on this? The config.ssh.pty=true setting seemed to be working fine between November and about two weeks ago, but when provisioning a new VM (CentOS 7, which worked before; identical Vagrantfile except for hostname) the rsync phase fails again complaining: ... sudo: sorry, you must have a tty to run sudo rsync: connection unexpectedly closed ....

Did something on the AWS side or in vagrant itself change (I probably did a vagrant plugins update in the interim)?

I also tried adding an '-e ssh -t' option to my rsync__args, but then I get prompted for a password for the centos user (so, it must be overriding the internal -e ssh that specifies the key location.

This is really frustrating. Any help would be greatly appreciated. Thanks!