Issues with shell when SSH-ing into Vagrant

[mark1282]

Running Vagrant 2.0.1

Windows 7 (fully updated)

Using homestead so Ubuntu 16

I'll update the ticket with my vagrant file once I'm infront of my machine.

Debug output

Provide a link to a GitHub Gist containing the complete debug output:
https://www.vagrantup.com/docs/other/debugging.html. The debug output should
be very long. Do NOT paste the debug output in the issue, just paste the
link to the Gist.

Expected behavior

Vagrant up appeared to run fine. However when SSH-ing into the Homestead box I got an issue.

Actual behavior

The default shell didn't load correctly. Left with a blank terminal screen

Steps to reproduce

1. Vagrant up
2. vagrant ssh

• ...

[AntiTiming]

Similar behavior for me with:
Vagrant 2.0.1
Windows 10
cygwin (cygwin terminal)

I'm using the box 'ubuntu/xenial64'.

After the box is up and running, calling 'vagrant ssh' logs into the machine, shows all the information which is shown by ubuntu when logging in, but not the shell prompt. Worked with vagrant 2.0.0 without problems.
Even without the prompt I can enter commands after logging into the box, but things like auto-completion, searching history etc. do not work.

[FlipperPA]

Same behavior here. I'm running:

Windows 10 - fully patched
Vagrant 2.0.1
Virtualbox 5.2
bento/centos7.2

While vagrant ssh hangs, it does seem to be executing /etc/bashrc, as you can see virtualenvwrapper installing itself on the first time login for the user:

...
RUNNING HANDLER [vagrant_configure : restart network] **************************
changed: [default]

PLAY RECAP *********************************************************************
default                    : ok=56   changed=52   unreachable=0    failed=0


AEONFLUX@DESKTOP-3D4EIEA MINGW64 ~/Desktop/python-vagrant-centos7 (virtualbox-5.2)
$ vagrant ssh
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/premkproject
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/postmkproject
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/initialize
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/premkvirtualenv
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/postmkvirtualenv
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/prermvirtualenv
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/postrmvirtualenv
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/predeactivate
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/postdeactivate
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/preactivate
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/postactivate
virtualenvwrapper.user_scripts creating /home/vagrant/.virtualenvs/get_env_details
[after getting no bash prompt for 10 minutes, I hit Control+C here]

AEONFLUX@DESKTOP-3D4EIEA MINGW64 ~/Desktop/python-vagrant-centos7 (virtualbox-5.2)
$ vagrant ssh
[nothing, it just hangs here]

I will note, however, that if I SSH to the VM's hostname from PuTTy, I can get in and get a bash prompt. I'll test from work on my Mac as well. Here's the Vagrant file I'm using:

https://github.com/wharton/python-vagrant-centos7/blob/virtualbox-5.2/Vagrantfile

Thanks, as always, for your efforts!

[voytass]

I confirm: Win7 x64, Git 2.15.0.windows.1, Vagrant 2.0.1 - no shell prompt after vagrant ssh login.
Login via PuTTY works fine.

[FlipperPA]

I've confirmed it works fine on my Mac. I'm wondering if it might be a terminal issue? I'm going to try setting git-bash to use xterm-256color like my Mac; will report back and try vagrant ssh -vvv.

[FlipperPA]

It seems to be a terminal issue. I'm able to vagrant ssh with my git-bash terminal set to xterm-256color but not when it is set to xterm.

For those looking for a workaround, click the icon in the git-bash terminal upper left, Options, Terminal and select xterm-256color in the Type dropdown.

[AntiTiming]

@FlipperPA Thank you, the workaround works for me as well!

I had my cygwin terminal set to xterm-color in my .bashrc which resulted in the login issue. Setting it to xterm-256color as proposed makes everything working as expected again.

[BubbleSnap]

Same issue, Windows 10 (build 1703), Vagrant 2.0.1, Git bash 2.15.0, Virtualbox 5.2.0.
vagrant ssh from within git bash doesn't work. Using Putty or similar works, or using command via powershell or command prompt.

The terminal resey didn't seem to work for me.

[lanshark]

I am getting the same issue.

This is with git-bash, v2.9.0, virtualbox 5.1.30, and vagrant 2.0.1 on Windows 7 fully patched.

Using Powershell 5, it works with vagrant ssh. Windows cmd vagrant ssh works.

SSH (not vagrant ssh) to the 127.0.0.1 box from git command line, windows cmd, or Powershell works.

Only vagrant ssh fails. It does not provide a command prompt, and will not accept commands.

Loading the gui, and logging in there works.

Changing the terminal type to xterm-256color does not change the behaviour.

Updating to git-bash 2.15.0.windows.1 did not change anything

[pomareb]

Same issue here on windows 8, using cygwin, vagrant 2.0.1, while trying to launch debian/stretch64 wich was working fine on vagrant 1.8.5.
My terminal is already on xterm-256color, cywing is up to date

[dkelly-sighter]

Hitting the same issue. Windows 10, Git V 2.9.2.windows.1, vagrant 2.0.1, Virtualbox 5.1.30. Work around with xterm-256color does not change behavior. However, I still get the welcome header on my ubuntu 14.04.5 LTS box and am able to navigate the file system, but no prompt:

[FlipperPA]

The workaround worked for me, but not a colleague. Another workaround: ssh vagrant@[hostname or IP] with password vagrant may work as well.

[jk3us]

For some reason, it isn't creating a pseudo terminal:

$ vagrant ssh web -- -vvv
OpenSSH_7.5p1, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /etc/ssh/ssh_config
Pseudo-terminal will not be allocated because stdin is not a terminal.   <----
debug2: resolving "127.0.0.1" port 2222
...

A more general workaround is to dump vagrant's ssh config and tell ssh to use it:

$ vagrant ssh-config > .vagrant_ssh.conf
$ ssh -F .vagrant_ssh.conf default   # where default is the name of your box, 

[jk3us]

Now I see that vagrant ships with an msys environment, and it's running that ssh and not cygwin's by default, which is apparently problematic when calling from inside cygwin. If I call that ssh.exe directly (/cygdrive/C/HashiCorp/Vagrant/embedded/usr/bin/ssh -F .vagrant_ssh_config web), I get the same behavior.

You can tell Vagrant to prefer your system tools with the VAGRANT_PREFER_SYSTEM_BIN environment variable, which seems to fix this problem (for me):

VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh

or put this into your .bash_profile:

export VAGRANT_PREFER_SYSTEM_BIN=1

[pomareb]

Nice, the VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh worked just fine for me

[ghost]

Hi everyone, I'm trying to vagrant ssh to create a new database with mysql, the above command worked for me, but now I'm stucked in the password field. It just wont take anything, is like if the keyboard wasn't working when I type the pass.

Eduardo's PC@LAPTOP-7MVVJUG0 MINGW64 ~/Documents/Root/local-sites
$ node --version
v8.9.1

Eduardo's PC@LAPTOP-7MVVJUG0 MINGW64 ~/Documents/Root/local-sites
$ npm --version
5.5.1

Eduardo's PC@LAPTOP-7MVVJUG0 MINGW64 ~/Documents/Root/local-sites
$ git --version
git version 2.15.0.windows.1

I'm running Git Bash as admin (and tried with no admin privileges). Windows command line and Node.js command prompt, and Windows Powershell do the same thing when I get to the password field.

Windows 10 - 64bit

I would really appreciate any help on this matter.

Thank you!

[vovkvlad]

Guys, I have the same problem but on macOS Sierra 10.12.6, after running vagrant ssh pseudo terminal is not invoked:

I tried setting VAGRANT_PREFER_SYSTEM_BIN system variable to 1 - it did not help in my case.

UPDATE:
running bash -i worked for me once, but after that I encountered the same issue and running bash -i thing does not making a thing anymore....

[fraserredmond]

VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh (and ssh vagrant@[hostname or IP]) worked for me, but xterm-256color didn't.

Hoping for a proper fix :)

[nospamcalfee]

Hi, I had a similar problem on Windows 7 - do "vagrant ssh" and it zipped to the next line and did not start vagrant. I could directly ssh vagrant@127.0.0.1 etc!

What I found is I had (BOTH!) cygwin and msys in my path and they both has ssh.exe programs. I removed them from the path and now vagrant ssh works. So something requires that the internal ssh and presumably the hidden .ssh directory must be in the hashicorp\ directory tree.

[alelavoie]

VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh (and ssh vagrant@[hostname or IP]) worked for me, but xterm-256color didn't.

Same here

[zach007]

i got the same problem ~ i was wondering what was wrong for a week .
vagrant version : 2.0.1
windows 10
virtualbox : 5.1.30
git bash : 2.15

1. when i use git bash , VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh works for me ~ but sometimes when i typed ,git bash crashed
   

2.and when i use powershell it seems ok to show prompt,but while using vim(plugin : vim-haskell-now), the color has some problem

[ghost]

The best solution for me is to use:

• Vagrant 2.0.0
• Virtualbox 5.1.x

Otherwise our developers on windows can't run there virtual machine correctly.

[leandroruel]

just coming here to say it: i typed vagrant up and provision in git bash, but not worked to me, he freezes and stops on it:

$ vagrant ssh
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-101-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

0 packages can be updated.
0 updates are security updates.

typed vagrant ssh on Windows Power Shell, that worked normally. this no make sense to me.

[iainhallam]

Same problem here, with these versions:

Windows 10 Pro 64-bit version 1709, build 16299.15
Git Bash 2.8.3.windows.1
Vagrant 2.0.1
VirtualBox 5.1.32

Using winpty vagrant ssh worked to get back a command prompt on Scotch Box, as did VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh. My Git Bash terminal was already set to xterm-256color.

[mark1282]

Updated to Vagrant 2.0.2 and it seems to have fixed the issue for me. Hopefully it's resolved it for others too?

[chrisroberts]

Hi there. The 2.0.2 release of Vagrant has an updated approach to the ssh client. The installer package ships with its own vendored ssh client so things are functional if the user has not yet installed an SSH package. This caused issues in special environments like cygwin or msys2, which could be rectified with wrapping the ssh process within a winpty process. However, this was also fragile and did not consistently work in all setups. So the 2.0.2 release removed the winpty wrapping and will search first for an ssh client on the host's path, and then fall back to the vendored ssh client as a last resort.

Apologies for the troubles encountered within different shell environments. This update should resolve most of the issues that were encountered.

Cheers!

[HSarode-Compumatrice]

hey guys,
my vagrant ssh freezes like below,
$ vagrant ssh
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-112-generic x86_64)

• Documentation: https://help.ubuntu.com
• Management: https://landscape.canonical.com
• Support: https://ubuntu.com/advantage

Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.
.
.
.
.
any suggestion please, and also didn't understand where to apply "VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh" in vagrantfile or where.
thankyou

[FlipperPA]

@HSarode-Compumatrice This was fixed in version 2.0.2 - upgrade Vagrant. :)

[HSarode-Compumatrice]

hey @FlipperPA Thank you so much,upgrading vagrant it worked,it basically for ubuntu xenial 16.04.3 box !!!

[grahamh]

I had a similar problem with the latest version of Vagrant 2.0.2 running on Windows 7 host, with Archlinux/Arlinux box. The prompt appeared intermittently and was sometimes corrupted. I installed OpenSSH for windows from http://www.mls-software.com/opensshd.html and all seems good now.

[c-gregory]

I am having this same problem. I have tried installing cygwin and using VAGRANT_PREFER_SYSTEM_BIN=1 but the prompt is still blank. Also tried uninstalling and redownloading Vagrant and VirtualBox with no luck.

OS: Win 7 Home Premium Version 6.1 (Build 7601: Service Pack 1)
Virtual Box Verison: Version 5.2.97 r120712 (Qt5.6.2)
Vagrant Version: 2.0.2
PowerShell: 5.1.14409.1012

[kylegibson]

My team and I have been experiencing this issue frequently recently. The hosts we've been using are ubuntu and macos, the guest is always ubuntu 16.04.

The versions of vagrant I've tested: 2.0.2, 1.95.
Versions of virtualbox I've tested, 5.2.8, 5.2.6, 5.2.0, 5.1.34

I'm commenting now because the hang happened again, and VAGRANT_PREFER_SYSTEM_BIN=1 does not fix the issue for me:

> VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh -- -vvv
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/kyle/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/tmp/127.0.0.12222vagrant" does not exist
debug2: ssh_connect: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 2222.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/kyle/dev/xxxxx/.vagrant/machines/dev/virtualbox/private_key" as a RSA1 public key
debug1: identity file /home/kyle/dev/xxxxx/.vagrant/machines/dev/virtualbox/private_key type -1
debug1: identity file /home/kyle/dev/xxxxx/.vagrant/machines/dev/virtualbox/private_key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
<hang>
ssh_exchange_identification: read: Connection reset by peer

The vagrant up looks like this:

==> dev: Clearing any previously set network interfaces...
==> dev: Preparing network interfaces based on configuration...
    dev: Adapter 1: nat
    dev: Adapter 2: hostonly
==> dev: Forwarding ports...
    dev: 8000 (guest) => 8000 (host) (adapter 1)
    dev: 3306 (guest) => 3306 (host) (adapter 1)
    dev: 8888 (guest) => 8888 (host) (adapter 1)
    dev: 22 (guest) => 2222 (host) (adapter 1)
==> dev: Running 'pre-boot' VM customizations...
==> dev: Booting VM...
==> dev: Waiting for machine to boot. This may take a few minutes...
    dev: SSH address: 127.0.0.1:2222
    dev: SSH username: vagrant
    dev: SSH auth method: private key
<hang>

After the default boot-timeout (300 seconds), this happens:

Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

When SSH does not hang, the delay for SSH working is about 5 seconds.

[fpilee]

the fix is for when you successfully login but there is no prompt.

[49handyman]

i brought up gui vm window and found that i had virtualization off in bios. turned on and booted first time.

try opening virtualbox manager and click show to watch the prograss of booting.

no it doesnt lockup at ssh generating keys

[montao]

I have this error using Vagrant 2.0.4. I tried everything. Nothing works.

$ VAGRANT_PREFER_SYSTEM_BIN=1 vagrant ssh
ssh_exchange_identification: read: Connection reset by peer

[jk3us]

@montao that looks like a different problem. Try vagrant ssh -- -v and get more info from ssh and see if you can narrow it down from there. Open a new issue if you need to.

[HSarode-Compumatrice]

thanks but didnt worked out, first question: where to put "VAGRANT_PREFER_SYSTEM_BIN=1" whether in vagrant file or some where else .please suggest

[dkarvounaris]

The problem is, that ssh thinks this is no terminal and such does not create TTY … there's an ssh config file option RequestTTY which can be used, which does the same things like the "-t" and "-T" parameters for ssh. See https://man.openbsd.org/ssh_config#RequestTTY . However...

The better solution is, in your Vagrantfile set the option for its ssh configuration, as it's mentioned here: https://www.vagrantup.com/docs/vagrantfile/ssh_settings.html
I added after this line at this location in my Vagrantfile

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    config.ssh.extra_args = "-tt"
   ….

That's correct "-tt", not "-t" to enforce creating it.

This is working in Git Bash perfectly!

[ivan-brko]

Thanks @dkarvounaris, your solution works for me

[tuomitie]

Remember to check that virtualization is enabled in BIOS. I had the same problem, but got it working by going to BIOS > Advance mode > Advance tab > CPU Configuration > Intel Virtualization Technology (or other virtualization setting). found the tip here

[Trollwut]

Could we get a vagrant ssh -tt to get the same behaviour as in config.ssh.extra_args = "-tt"?

[kindlehl]

I had a similar issue to this one. I had just reinstalled my OS and transported my ssh keys from the old installation in. The ownership and mode on the ssh keys were not properly set, and vagrant could not access them. I just did this:

sudo chown -R $USER:$USER ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
chmod 644 ~/.ssh/*.pub

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.