I can successfully forward X11 by connecting to my Github Codespace via
$ gh cs ssh
as my ~/.ssh/config includes
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa
ForwardX11 yes
ForwardX11Trusted yes
and I am running an X server locally (locally DISPLAY=:0), and xauth is installed in the Github Codespace. I can successfully start X applications remotely and they are forwarded. In the remote shell, DISPLAY=localhost:10.0.
However, when I connect via VSCode and the Github Codespaces extension, X forwarding does not work.
DISPLAY is not set in the remote shell. Even if I set it manually (via export DISPLAY=localhost:10.0) it doesn't work. For instance, when I try to run an application using pygame, I get pygame.error: No available video device.
How can I forward X11 when connecting to a Github Codespace via the VSCode extension? Thank you.
Related
I know I can use KDE dolphin to open a directory in a remote machine that I can directly access via ssh, but what if that machine is 1 hop away? Normally, when I have to open a terminal on such machine (let's call it destination), I issue the following command:
ssh user1#intermediate_destination:dir1
which allows me to connect to an "intermediate" server. Then, from intermediate_destination:
ssh user2#destination:dir2
How do I open a file browser in destination from my local machine using KDE Dolphin?
As suggested by #sanette, I've tried setting up an ssh tunnel in the following way:
sudo ssh -J user1#intermediate_destination -NL 22:localhost:22 user2#destination
Then, I've tried to create a "Network folder" using Dolphin with the following parameters:
Type of network folder: Secure shell (ssh)
Name: whatever
User: user2
Server: localhost
Port: 22
Protocol: sftp
Folder: dir2
Encoding: Unicode (UTF-8)
And it finally worked!
I'm trying to use the private key from my openpgp card from my Debian laptop to a RPi. I followed the different hints found on google, in particular:
extra-socket in ~/.gnupg/gpg-agent.conf
removed it again when founding that this extra socket already will be created in /run/user/<uid>/gnupg
forward this socket using ~/.ssh/config
Host homegear
HostName homegear
RemoteForward ~/.gnupg/S.gpg-agent /run/user/1000/gnupg/S.gpg-agent.extra
changed the order of the both sockets in the RemoteForward line since I'm always confused which one should be the first one
add the following into /etc/ssh/sshd_config of the RPi
StreamLocalBindUnlink yes
reload the gpg-agent on the laptop
open new ssh connection to RPi
But I always get
Warning: remote port forwarding failed for listen path ~/.gnupg/S.gpg-agent
when connecting to the RPi.
openssh on both laptop and RPi is 7.4 (Debian Stretch), gpg is 2.1.18.
Forwarding the agent connect to be used as ssh private key (for connecting to gitlab from RPi) works perfectly, forwarding gpg private key (for signing commits) doesn't. I'm a bit helpless at the moment. Is there anything obviously wrong? Or is there still a problem with forwarding unix domain socket and I need to use the socat workaround?
Thank you!
I've run into exactly the same issue except between two Macs running 10.14.2 and GPG 2.2.11, and the only way I was able to get it to work was to specify the absolute path to the sockets on both ends. :( Having a relative path for either the remote or local socket both failed in various ways, which makes it a bit of a pain if you're connecting as different usernames on various machines.
I was able to work around that by specifying a number of different Match exec blocks in my ~/.ssh/config:
# Source machine is a personal Mac, connecting to another personal Mac on my local network
Match exec "hostname | grep -F .core" Host *.core
RemoteForward /Users/virtualwolf/.gnupg/S.gpg-agent /Users/virtualwolf/.gnupg/S.gpg-agent.extra
# Source machine is a personal Mac, connecting to my Linux box
Match exec "hostname | grep -F .core" Host <name of the host block for my Linux box>
RemoteForward /home/virtualwolf/.gnupg/S.gpg-agent /Users/virtualwolf/.gnupg/S.gpg-agent.extra
# Source machine is my work Mac, connecting to my Linux box
Match exec "hostname | grep -F <work machine name>" Host <name of the host block for my Linux box>
RemoteForward /home/virtualwolf/.gnupg/S.gpg-agent /Users/<work username>/.gnupg/S.gpg-agent.extra
(SSH bits are taken from this answer).
Whenever I try to connect to my local Vagrant, I get this error when I run ssh vagrant#127.0.0.1:2222 from the Windows git bash:
ssh: connect to host 127.0.0.1:2222 port 22: Bad file number
It was working previously, so I'm not sure what could have caused this. When I try to do an SFTP connection in PHPStorm 8, I get this error:
Connection to '127.0.0.1' failed.
SSH_MSG_DISCONNECT: 2 Too many authentication failures for vagrant
I've tried vagrant destroy with vagrant box remove laravel/homestead and then recreating the box from a backup I had that previously worked using vagrant box add laravel/homestead homestead.box but I still get the same errors.
I'm on Windows 7.
What can I do to get access to my vagrant box commandline again?
Try command:
ssh -p 2222 vagrant#127.0.0.1
The answer by outboundexplorer above is the correct one I believe.Here is my step-by-step approach on how I did this:
Step 1: Find out exactly what SSH settings to use
Ensure the vagrant box is running (you've done vagrant up that is)
From the command line, go to your project directory (the one where the Vagrantfile is located) and run vagrant ssh-config.
You'll get an output like this:
Host default
HostName 127.0.0.1
User ubuntu
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile C:/Projects/my-test-project/.vagrant/machines/default/virtualbox/private_key
IdentitiesOnly yes
LogLevel FATAL
Step 2: Setting up PHPStorm to SFTP to the Vagrant box
Based on the config settings shown above, I set up the following SFTP remote deployment server:
SFTP host: 127.0.0.1
Port: 2222
Root path: /home/ubuntu/my-test-project (this is the folder inside the Vagrant box where the files will be uploaded to, change to whatever suits your needs)
User name: ubuntu
Auth type: Select "Key pair (OpenSSH or PuTTY)"
Private key file: Point to the IdentityFile path shown (C:/Projects/....)
... and that was it.
I got this same failure when using PHpStorm to SSH into the VirtualBox guest machine that i had set up with Vagrant. Everything worked fine before I upgraded to Windows 10. After upgrading, first of all i had to upgrade to VirtualBox and Vagrant latest versions to get everything to work on Windows 10.
But then i couldn't ssh into the guest machine using the PhpStorm ssh client. After much reading, everything seemed to suggest that I had too many ssh-keys installed on my Windows machine, but checking regedit just showed that I only had a couple of keys which should be less than the suggested max 5 keys (as default). In the end i did vagrant ssh which didn't allow me to ssh into the guest machine, but it did reconfirm the ssh details for me. I then realized that after all the new installs it didn't want me to use the C:\Users\Andy\.vagrant.d\insecure_private_key key but instead use a key that it had placed within the project itself at C:/Users/Andy/CodeLab5/vagrant/.vagrant/machines/default/virtualbox/private_key.
Everything is working as it should again now :)
Make sure your vagrant is up and running by command : vagrant up
and then do vagrant ssh. It will connect to vagrant localhost
Hey I'm having an issue getting ssh X forwarding to work. The setup is I'm sshing into my ubuntu VM off OSX Yosemite host machine.
I already installed xQuartz on OSX, xauth on ubuntu, and I believe I've have all the correct options set in ssh_config files.
I get the
Warning: untrusted X11 forwarding setup failed: xauth key data not generated
X11 forwarding request failed on channel 0
message when opening a connection with ssh -X, and when I tried to run an X application:
xterm: Xt error: Can't open display:
xterm: DISPLAY is not set
I have the identical setup on my other machine except running Mavericks and it works fine, is there something specific to Yosemite specific I have to worry about?
Note that some incomplete answers might lead to security flaws.
Using ssh -Y means here having fake xauth information which is bad!
ssh -X should work since XQuartz, once enabled, uses xauth. The only problem is that ssh is looking for xauth in /usr/X11R6/bin and on macOS with XQuartz it is in /opt/X11/bin
Secure solution:
Enable the first option in the Security tab of preferences (Cmd-,) which enables authenticated connections.
Edit ~/.ssh/config, add XAuthLocation /opt/X11/bin/xauth to the host config.
ssh -X your_server works in a secure manner.
Ensure xauth is installed on the destination host.
On macOS Sierra, I now have to do ssh -Y instead of ssh -X to get a display from a linux machine to work on my Mac.
I received the same warning as you after upgrading to Yosemite.
After I added ForwardX11Trusted yes in my ~/.ssh/config file, the warning disappeared.
Do you have the following lines in your ~/.ssh/config file for enabling Trusted X11 forwarding?
Host APPROPRIATE_HOSTNAME
ForwardX11Trusted yes
ForwardX11 yes
OTHER_OPTIONS
Gilles Gouaillardet has the answer that solved this for me. Edit ~/.ssh/config to contain
Host *
XAuthLocation /opt/X11/bin/xauth
and ssh -X hostname now works (XQuartz 2.7.11, macOS 10.4 Mojave)
I already had the latest XQuartz 2.7.11 installed, but I think I've also updated the OS a few times since then. I reinstalled XQuartz 2.7.11, and now it is working fine.
ForwardX11Trusted is required even for connections you think are untrusted when your X server doesn't have the SECURITY extension (Apple servers have a ton of visuals that take up over 100 lines, so I suggest "xdpyinfo | grep SECURITY" to check; if that returns no output, you don't have it). There may be other reasons and exceptions, but this worked for me.
I've just downloaded the latest X11 version and it worked again
I just hit this issue using Mac OS X 10.6.8 to Linux Debian 9.
None of the solutions provided worked.
Root cause was: loopback interface was "DOWN" on the target Linux host.
I had to type the following on the target host to fix the issue
ip link set lo up
Same as answered by user Xvalidated above. but there was no ssh_config file in my .ssh directory.
1. copy ./etc/ssh_config to ~/.ssh/ #file if not there
2. edit
Host hostname
ForwardX11Trusted yes
ForwardX11 yes
As answered before, I would like to add one more thing which will work to reinstall X-supporting software.
When you login the cluster, do not use -X or -Y options.
Example:
ssh -Y remotelogin: gives me X11 related warning.
ssh remotelogin: No warning, works fine.
I am testing a Google Compute Engine, and I created a VM with Ubuntu OS. When I connect to it, by clicking this Connect SSH button, it opens a console window.
Is that the connection you get?
How do I open a real screen with a GUI on it? I don't want the console.
Much better solution from Google themselves:
https://medium.com/google-cloud/linux-gui-on-the-google-cloud-platform-800719ab27c5
You need to forward the X11 session from the VM to your local machine. This has been covered in the Unix and Linux stack site before:
https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-from-ubuntu-machine
Since you are connecting to a server that is expected to run compute tasks there may well be no X11 server installed on it. You may need to install X11 and similar. You can do that by following the instructions here:
https://help.ubuntu.com/community/ServerGUI
Since I have needed to do this recently, I am going to briefly write up the required changes here:
Configure the Server
$ sudo vim /etc/ssh/sshd_config
Ensure that X11Forwarding yes is present. Restart the ssh daemon if you change the settings:
$ sudo /etc/init.d/sshd restart
Configure the Client
$ vim ~/.ssh/config
Ensure that ForwardX11 yes is present for the host. For example:
Host example.com
ForwardX11 yes
Forwarding X11
$ ssh -X -C example.com
...
$ gedit example.txt
Trusted X11 Forwarding
http://dailypackage.fedorabook.com/index.php?/archives/48-Wednesday-Why-Trusted-and-Untrusted-X11-Forwarding-with-SSH.html
You may wish to enable trusted forwarding if applications have trouble with untrusted forwarding.
You can enable this permanently by using ForwardX11Trusted yes in the ~/.ssh/config file.
You can enable this for a single connection by using the -Y argument in place of the -X argument.
These instructions are for setting up Ubuntu 16.04 LTS with LXDE (I use SSH port forwarding instead of opening port 5901 in the VM instance firewall)
1. Build a new Ubuntu VM instance using the GCP Console
2. connect to your instance using google cloud shell
gcloud compute --project "project_name" ssh --zone "project_zone" "instance_name"
3. install the necessary packages
sudo apt update && sudo apt upgrade
sudo apt-get install xorg lxde vnc4server
4. setup vncserver (you will be asked to provide a password for the vncserver)
vncserver
sudo echo "lxpanel & /usr/bin/lxsession -s LXDE &" >> ~/.vnc/xstartup
6. Reboot your instance (this returns you to the Google cloud shell prompt)
sudo reboot
7. Use the google cloud shell download file facility to download the auto-generated private key stored at $HOME/.ssh/google_compute_engine and save it in your local machine*****
cloudshell download-files $HOME/.ssh/google_compute_engine
8. From your local machine SSH to your VM instance (forwarding port 5901) using your private key (downloaded at step 7)
ssh -L 5901:localhost:5901 -i "google_compute_engine" username#instance_external_ip -v -4
9. Run the vncserver in your VM instance
vncserver -geometry 1280x800
10. In your local machine's Remote Desktop Client (e.g. Remmina) set Server to localhost:5901 and Protocol to VNC
Note 1: to check if the vncserver is working ok use:
netstat -na | grep '[:.]5901'
tail -f /home/user_id/.vnc/instance-1:1.log
Note 2: to restart the vncserver use:
sudo vncserver -kill :1 && vncserver
***** When first connected via the Google cloud shell the public and private keys are auto-generated and stored in the cloud shell instance at $HOME/.ssh/
ls $HOME/.ssh/
google_compute_engine google_compute_engine.pub google_compute_known_hosts
The public key should be added to the home/*user_id*/.ssh/authorized_keys
in the VM instance (this is done automatically when you first SHH to the VM instance from the google cloud shell, i.e. in step 2)
you can confirm this in the instance metadata
Chrome Remote Desktop allows you to remotely access applications with a graphical user interface from a local computer or mobile device. For this approach, you don't need to open firewall ports, and you use your Google Account for authentication and authorization.
Check out this google tutorial to use it with Compute Engine : https://cloud.google.com/solutions/chrome-desktop-remote-on-compute-engine