I've got a strange behaviour of ssh and ssh-keygen: they do not react at all. Cygwin is started with admin rights and works normally. The host 192.168.1.1 is up and I can remote desktop to it:
When I try:
$ ssh -vvv pi#192.168.1.1
OpenSSH_8.3p1, OpenSSL 1.1.1f 31 Mar 2020
I get only one line but nothing else, even if I wait hours. I reinstalled cygwin, openssh, I deleted the .ssh folders, no success.
When I enter
ssh-keygen -b 4096
nothing happens at all. For me it seems that the user interaction does not work. Any ideas?
Thanks
Update: I tried:
reinstalling cygin for all users, one user, running the installation with admin rights, without. No success.
Started ssh and ssh-keygen with an absolute path to make sure that the windows openssh is not used
Checked the folder permissions on .ssh
Here is my strace: Pastebin
Update 2: I found the following: if I run ssh-keygen or ssh often enough (!) it will sometimes work! Now that's weird.
Philippe had the right idea. Basically the citrix workspace app is crashing ssh cygwin. When I uninstalled citrix everything worked fine!
I found that it is down to a bug in epclient64.dll of citrix: it crashes my ssh in my internal network. After uninstallation of citrix it would work normally. Here is the log
Pastebin log of strace
https://pastebin.com/FJfUj3C1[Pastebin][1]
Without the app protection it works fine. So to sum up:
with app protection ssh crashes again and again, it does not even start properly
without citrix ssh works fine
citrix without app protection ssh works fine
--> epclient64.dll does not work with ssh
And we are talking about the most recent versions of ssh & citrix as of Jan 2021.
I found that when I uninstalled citrix, it had no effect.
I opened up the folder in Windows Explorer where the ssh.exe resides. I right clicked on this executable, navigated to Compatibility tab, selected Run this program in compatibility mode for "Windows 8". Then I at least got a response from the command line, but it would never connect to the host I entered. It would get stuck and I would have to kill it from taskmgr.
When I ran whereis ssh, I had 2 versions in Cygwin, one in /usr/bin and one in /cygdrive/c/WINDOWS/System32/OpenSSH. So what I did was to move the /usr/bin version to a backup file and create a link in a cygwin shell to /cygdrive/c/WINDOWS/System32/OpenSSH/ssh.exe. Now it works like it used to.
By the way my OpenSSH version is "OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5" running on Windows 10.
Problem:
When I launched Ubuntu 20.04, it pops up: "Press any key to continue...", and then if I press any key, it exits immediately. This prevents me from using (typing any command) in Ubuntu WSL. (It occurred suddenly today. For the last couple of days it has been working properly.)
Screenshot: Press any key to continue pops up after startup
Attempts Tried:
LxssManager service is running. But LxssManagerUser and LxssManagerUser_60d78 are stopped. Manually starting the two services doesn't help as they automatically stop themselves right afterwards.
Hyper-V service is set to auto. Virtualization mode is enabled (task manager -> performance -> CPU)
Trying to re-run the update from here https://learn.microsoft.com/en-us/windows/wsl/wsl2-kernel, but it shows WSL not installed (which is weird since I have been using it for a long time before)
Environment:
OS: Microsoft Windows 10 Family, Insider Preview
Version: 10.0.20152 Version 20152
System Type: x64 based
I'd accidentally mounted the WSL virtual disk image by double-clicking it in explorer, and it remained mounted to my machine even though it reported an error that made having it mounted useless. Unmounting the vdisk from Disk Management resolved the issue for me.
From https://github.com/microsoft/WSL/issues/4177#issuecomment-597736482
There is a conflict between wsl.exe and Proxifier.
Developers of Proxifier gave a solution.
Thanks for the info.
We have reproduced this issue. Apparently, wsl.exe displays this error
if Winsock LSP DLL gets loaded into its process.
The easiest solution is to use WSCSetApplicationCategory WinAPI call
for wsl.exe to prevent this. Under the hood the call creates an entry
for wsl.exe at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinSock2\Parameters\AppId_Catalog
This tells Windows not to load LSP DLLs into wsl.exe process.
We have a tool that can make this call:
www.proxifier.com/tmp/Test20200228/NoLsp.exe
Please just run as admin with the full path to wsl.exe as the
parameter: NoLsp.exe c:\windows\system32\wsl.exe
This has fixed the problem in my case.
Please let me know how it works for you.
And it works well for me!
This worked magic! Go to the Windows Command Prompt and run the following command:
netsh winsock reset
Then Restart your computer. NB: Don't Shutdown since it did not work for me. Instead, Restart!
More answers can be found here.
I solved by downloading the https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msimsi and excuting it.
see https://learn.microsoft.com/en-us/windows/wsl/wsl2-kernel
I went into the bios and had to enable virtualization from there
if you got this error:
An operation was attempted on something that is not a socket.
there is something wrong with windows sockets and try this command in cmd administrator mode to reset windows sockets.
1. netsh winsock reset catalog
2. netsh int ipv4 reset reset.log
3. netsh int ipv6 reset reset.log
4. Restart the computer.
Maybe not relevant for TO but I had the same issue and just had to run in Windows Terminal:
wsl --shutdown
After that Ubuntu worked again.
powershell => type "wsl --shutdown" => error message
ctrl-alt-del => services => HvHost => right button => restart (think to stop all hyperv virtual machines before ?)
powershell => type "wsl" => OK
restart hyperv virtual machines
When I connect x2go with XFCE Ubuntu 20.04 (KVM VM) after ~10 minutes of idle time, x2go will lose its mouse focus and keyboard focus and there is no way to grab control of the session. Even restarting x2go will not bring the focus back.
The XFCE VM is still running because I can see the top output in the console.
I tried several key combinations to bring the focus back but it does not. I tried LXDE and it does not have this issue. I tried XFCE desktop 20.04 on its running in a KVM VM. I also tried installing Ubuntu server 20.04 and load Xubuntu-desktop (KVM VM) - the same issue. After ~10 minutes the x2go session-focus is lost.
What brings the session focus back is if I reboot the VM and then connect to the VM again using x2go. as I mentioned just restarting x2go will not bring the session focus back.
I tried uninstalling the screensaver and the power management features in XFCE but that did not fix this issue.
Update: this x2go bug report log suggests its screensaver related. Using the applications/settings/screensaver allowed me to turn off anything related to the screensaver, solving the problem for me. Issue appears to be solved here similarly: askubuntu forum
I've been having the same issue w/ XFCE and LXDE both after an idle period (10-15 minutes), and only on Ubuntu 20.04, not on 18.04 or earlier. In either desktop env, the session was not recoverable and required termination of the session either from the client side or via a separate terminal ssh session to kill <PID> the x2gocleansessio process on the server side (after seeing it was running using top). For a short period, I regained control in the new session until the cycle recurred.
Seems like a major problem for x2go in Ubuntu 20.04.
Just to save everyone the time of digging through the AskUbuntu forum... run this + restart and you should be good to go on Ubuntu 20.04 -
sudo apt-get remove xfce4-screensaver
If your are login via x2go and don't want to uninstall xfce4-screensaver, it's hard to solve the problem because there are intern script of xfce who launch xfce4-screensaver whatever you told him to do. I found my own workaround WITHOUT root privilege:
First activate screensaver on start-up :settings-manager -> Session and Startup->check screensaver(that sound weird but by this way you are sure to launch your xfce4-screensaver localy otherwise it's the root user who launch it which this own startup file which you can't edit without root)
Second : in ~/.config/autostart/xfce4-screensaver.desktop (if it doesn't exist uncheck then check screensaver in first step). Add to the end of this file:
Exec=sh -c "kill $(pgrep -u <YOUR-USERNAME> screen)"
This will launch it but auto-kill it after OnLogin
Edit: it's better than uninstall it because in my case that was the administrator that install for every user xfce4-screensaver so I can't uninstall it because the computer need a screensaver on the real sessions (I mean not in ssh on the physique machine). Maybe switch to Xscreensaver or other screensaver will solve this problem
I have been looking out for ways to setup an automation environment and I found this application named Vagrant. I read the docs on the site, however I wanted to know from the experts out there if Vagrant with Oracle VirtualBox would suffice my needs.
I need to have a script that will call Vagrant to initialize a VM [The VM-Image is always the same - Windows Server 2008 R2]
I need to copy some of my project related files from a shared location onto the VM
Call a Batch file that will take care of test runs for me inside the VM
Once my test run is complete, This VM needs to be self destroyed/destructed.
Also, I would like to know if the Image be a custom .ISO file?
Sounds like Vagrant and VirtualBox will work for that scenario. Also, you might find that running commands in the VM using WinRM or SSH may be the easiest way to launch tests.
If you haven't already seen it, the blog post about Windows support in Vagrant 1.6 is informative: https://www.vagrantup.com/blog/feature-preview-vagrant-1-6-windows.html
Creating a VirtualBox/Vagrant base VM from an .iso should work, and you can then do all of your work using the VM from that point onward.
To get started, you might try these steps:
Create a VirtualBox VM from your Windows .iso, using the VirtualBox GUI or cmdline tools.
Once you have the VM in the state you want it, shut it down and package it as a vagrant box - for example, on a Mac that step looks like (where Win7x64 is the dir containing the VirtualBox VM):
cd ~/VirtualBox\ VMs
vagrant package --base Win7x64 --output win7x64_base.box
Once that finishes, tell vagrant about the new base box:
vagrant box add win7x64_base /path/to/win7_base.box
Then you can vagrant init/vagrant up the VM:
mkdir win7 && cd win7
vagrant init win7x64
vagrant up
To enable SSH access, I installed Cygwin in the VM and configured sshd. So, after launching you can SSH in by running vagrant ssh
Note that if there's no Windows user in the VM named 'vagrant', you can specify the SSH username to use with vagrant ssh by placing this in your Vagrantfile:
config.ssh.username = 'user1'
As mentioned above, WinRM is also an option for remotely running commands.
And Vagrant apparently has some convenience features to make it easy to RDP into the VM, but I haven't looked at that.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am running vagrant 1.4 and virtual box 4.3 on fedora 17 machine. When I do "vagrant up", I get this error:
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["hostonlyif", "create"]
Stderr: 0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: VBoxNetAdpCtl: ioctl failed for /dev/vboxnetctl: Inappropriate ioctl for devic
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterface, interface IHostNetworkInterface
VBoxManage: error: Context: "int handleCreate(HandlerArg*, int, int*)" at line 66 of file VBoxManageHostonly.cpp
I had the same problem today. The reason was that I had another VM running in VirtualBox.
Solution:
Open VirtualBox and shut down every VM running
Go to System Preferences > Security & Privacy Then hit the "Allow" button to let Oracle (VirtualBox) load.
Restart VirtualBox
sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart
You should now be able to run vagrant up or vagrant reload and have your new host configured.
As mentioned in this answer, recent versions of macOS can block VirtualBox.
Solution:
Go to System Preferences > Security & Privacy Then hit the "Allow" button to let Oracle (VirtualBox) load.
(thanks to #pazhyn, #lsimonetti & #dave-beauchesne for clarifications)
For Mac OS X 10.9.3 and Vagrant 1.6.3 and VirtualBox 4.3.6 this problem was fixed with restarting the VirtualBox
sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart
TL;DR MacOS is probably blocking VirtualBox. Go to System Preferences > Security & Privacy Then hit the "Allow".
Solution:
Go to System Preferences > Security & Privacy Then hit the "Allow" button to let Oracle (VirtualBox) load.
MacOS by default can block kexts from loading. You must click the "allow" button before executing the VirtualBoxStartup.sh script.
Then run:
sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart like the answer above.
(This article provides more clarity to MacOS kernel extension loading)
This issue appears to be fixed by installing the latest version of Virtual Box.
I had this issue after upgrading to OS X El Captian. Upgrading to the latest version of VB solved the issue for me. Virtual box will give you the latest link if you go to the virtualbox menu at the top of your screen and clicking check for updates.
Got the error in Mac after the update to Mojave. Probably you have an older version of virtual box.
Update to a recent version of virtualbox. (5.2 at the time of wrting this post)
Edit: adding #lsimonetti's comment.
In addition to that upgrade to Virtualbox 5.2, you need Vagrant >= 2.0.1
If you are on Linux, simply run: sudo vboxreload
I'm running Oracle VM Virtualbox on Ubuntu 16.04 LTS.
The solution that worked was to reinstall virtualbox as mentioned here:
sudo apt remove virtualbox virtualbox-5.0 virtualbox-4.*
sudo apt-get install virtualbox
I couldn't find my VirtualBox installation folder, as such could not issue the command:
$sudo /Library/StartupItems/VirtualBox/VirtualBox restart
I had to reinstall Virtual Box on my machine.
Here's the downloads page: Downloads Page
Then vagrant up worked for me after.
If after performing what is said by #totophe and on macOS it still doesn't work, just restart your mac. Then open the terminal and vagrant up.
This usually happens after each macOS update.
I had similar problem upgrading to OSX Monterey.
Solution:
Install VirtualBox Extension (download)
Accept VirtualBox Security & Privacy/Privacy/Input Monitoring
VirtualBox can also have and lose permissions for Accessibility, check that as well
In my case, I was able to solve this issue by reinstalling virtual box. I was trying to use laravel's homestead and was having this error. Reinstalling helps creating the directories that are needed for virtual box again. Took me an hour to figure out.
I'm running Debian 8 (Jessie), Vagrant 1.6.5 and Virtual Box 4.3.x with the same problem.
For me it got fixed executing:
sudo /etc/init.d/vboxdrv setup
Tried multiple solutions but the below sequence works for me.
Virtual Box: 5.2.34
Vagrant: 2.2.5
Mac OSX: 10.14.6
First Allow access to oracle inc:
Go to System Preferences > Security & Privacy Then hit the "Allow" button to let Oracle (VirtualBox) load.
Then restart VBox by this command:
sudo /Library/Application\ Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh restart
Now try Vagrant up again.
I've just had the same problem after upgrading to mac os Big Sur
Linus solution worked for me
Grant permission to VirtualBox under System Preferences > Security & Privacy > General (this request is new to macOS High Sierra)
Open Terminal and run: sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart
https://stackoverflow.com/a/47652517/6146535
$sudo /Library/StartupItems/VirtualBox/VirtualBox restart
Worked great for me on Mac. This normally happens when I shut down my computer without running
$vagrant suspend
I am using ubuntu 14.04. I have genymotion installed on virtualbox. Every time I start genymotion I had no problem, but suddenly one time it said unable to load virtualbox engine and it didn't open. I went through the log file and found out it could not create a new host only network because it has already created all possible host only networks. And the problem is that it cannot allocate memory for a new network.
Fix: go to your virtual box File --> Preferences --> Network
Click the host-only tab and just delete some of the host-only networks so that you will get some memory freed and next time, a new network can be created easily.
Deletion fixed my problem.
In my case I had to do the following to solve this error for me:
totophe's answer in combination with (re)installing the latest VM-version (https://www.virtualbox.org/wiki/Downloads) (Thanks to jacobappleton & user1718159)
Steps:
First (re)install latest VirtualBox;
Run sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart in terminal (not sure if this is needed in order to get the system preferences show up the allow/disallow option);
Allow in Security & Privacy
Restart your machine
Run sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart again.
Ready to run vagrant up again.
I fixed this error by installing VirtualBox 4.2 instead of 4.3. I think the latest version of vagrant and VB 4.3 are incompatible on a fedora system.
CentOS Linux release 7.2.1511 (Core)
VirtualBox-5.0
I came across this tread while searching Google for...
VBoxManage: error: Failed to create the host-only adapter
I was using VirtualBox-5.0 to test some virtual machines created with Vagrant and setting private networks in my Vagrantfile
web.vm.network "private_network", ip: "192.168.10.2"
When evoking the command $ vagrant up I would get the above mentioned error along with /dev/vboxnetcrl does not exist.
It seems that my version of VirtualBox did not have the proper kernel module compiled for my version of Linux and the device, /dev/vboxnetcrl, does not get created.
Since I wanted to test virtual machine and not troubleshoot VirtualBox, my work around (not a solution) was to:
# yum remove VirtualBox-5.0
# yum install VirtualBox-4.3
After that I was able to create the virtual machines with specified host-adapters. And of course, under VirtualBox-4.3, /dev/vboxnetcrl was there.
Now on to testing my VMs. And when I have time, I'll see if I can get it working under VirtualBox 5.0
If you are on Linux:
sudo service virtualbox restart
Windows 10 Pro
VirtualBox 5.2.12
In my case I had to edit the Host Only Ethernet Adapter in the VirtualBox GUI. Click Global Tools -> Host Network Manager -> Select the ethernet adapter, then click Properties. Mine was set to configure automatically, and the IP address it was trying to use was different than what I was trying to use with drupal-vm and vagrant. I just had to change that to manual and correct the IP address. I hope this helps someone else.
I had the same problem just now and it was solved by simply reinstalling to the latest version of VirtualBox.
For those on Mac OS High Sierra - the installation might fail at first but you need to go to System Preferences > Security & Policy and click on the "Allow" button to allow Oracle installing the software.
For macOS Mojave, this solution worked:
sudo "/Library/Application Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh" restart
I faced this issue on mac.
I did the following
Go to:
Launcher->Virtualbox
Click the icon to open Virtualbox
Start Virtualbox with the button that pops up once Virtualbox starts. Wait till the terminal window gives you the prompt,
docker#boot2docker
Then try to open docker. Hope it works!
If you are sure you have allow Oracle from system preference and the error still persist. It is highly possible you have not started VirtualBox. Ensure it is running and run vagrant up again.
Finally worked for me by following Given link.
https://www.mediacurrent.com/blog/drupal-vm-failed-create-host-only-adapter/
Tried on : 06 Mar, 2021
Mac OS = 11.2.2 (20D80)
Oracle Virtual Box = Version 6.1.18 r142142 (Qt5.6.3)
~ ➤ docker-machine create --driver virtualbox Manager1
Running pre-create checks...
Creating machine...
(Manager1) Copying /Users/speedoo/.docker/machine/cache/boot2docker.iso to /Users/speedoo/.docker/machine/machines/Manager1/boot2docker.iso...
(Manager1) Creating VirtualBox VM...
(Manager1) Creating SSH key...
(Manager1) Starting the VM...
(Manager1) Check network to re-create if needed...
(Manager1) Found a new host-only adapter: "vboxnet0"
(Manager1) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env Manager1
~ ➤
~ ➤
~ ➤ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
Manager1 - virtualbox Running tcp://192.168.99.100:2376 v19.03.12
~ ➤
What helped me on Opensuse 42.1 is to install VirtualBox and Vagrant from the official RPMs instead of from Opensuse repositories.
I encountered this problem on Windows 8.1, VirtualBox 5.1.18 and Vagrant 1.9.3.
Deleting the VirtualBox Hosts-only Ethernet Adapter from VirtualBox Preferences (Network --> Hosts-only networks) fixed this for me, and vagrant up could continue and start the VM.
I had the same problem while following a tutorial on setting up Laravel Homestead for Windows 10. The tutorial provides an example IP address 192.168.10.10 to use for the server. The problem with their example IP is that if you already have a VirtualBox Host-Only Adapter set up, the IP you use for your vagrant server must have the same first three parts of the IP address of your current adapter.
You can check what your current Virtualbox Host-Only Adapter IP address is by running ipconfig (windows) ifconfig (mac/linux) and looking for VirtualBox Host-Only Adapter's IPv4 address. 192.168.56.1 was mine. Usually if the host IP is 192.168.56.1 then the guest IP will be 192.168.56.101 so instead of using the example IP I used 192.168.56.102. Any IP that is within 192.168.56.* that is not already taken should work.
After this homestead up worked perfectly for me.
TL;DR - If your current VirtualBox Host-Only Adapter IP is 192.168.56.1, make your Vagrant server IP 192.168.56.102.