SSH into a Toolbox

Do you guys know if there is any way to SSH into them locally? I’ve been unable to get it working and while it may sound strange to you, it would make my life way easier.

What do you mean by SSH into them locally ?

The Toolbox environment is a container, not a virtual machine, so there’s no separate system to SSH into. You just SSH into the host that you are interested in, and use toolbox enter. If you want to enable the SSH server on a Silverblue system, you can use Settings. The Sharing panel has remote login toggle for this.

I’m trying to get the VSCode remote development extensions working with a Toolbox, since the container extensions doesn’t work with podman, I was trying to get the SSH extension working…

I tried VSCode as a layered RPM, as a Flatpak, and installed as an RPM inside a toolbox.

The first two options have issues with some extensions needing native programs (such as jshint/webhint related things needing binaries on the system).

The Flatpak approach needs a workaround to launch a container using a special flatpak-spawn --host toolbox enter -c container-name-here command deep in VSCode’s configs, as seen elsewhere in this forum. Even still, it execs commands in the Flatpak instead of in the container. (Perhaps there’s a workaround for this too.) And there’s a small, but noticable performance hit.

For me, at least, running inside a toolbox itself is the best way to run VSCode… and then you don’t have to do anything special. The built-terminal will be in the container already and so will all the commands it might want to run.

The only downside to running the RPM’d version of VSCode in a toolbox that I haven’t been able to get apps in toolboxes to launch with custom desktop files. (That is: a desktop file in ~/.local/share/applications/ with something like Exec=toolbox run -c container-name app-name %f to launch the app inside the container. I think it should work… but doesn’t.)

So right now, I either open my terminal with the development container profile I made (which automatically runs toolbox enter) and type code to launch VSCode or do toolbox run code in my terminal’s system profile.

Also, if you have multiple toolbox containers, you might also need to have VSCode in each one… unless you have a main dev container and just access the directory from the other.

I’d love to be able to launch it like any other app, even if it’s inside a container.

4 Likes

I’ve checked those options and yes, installing VSCode inside the toolbox seems to be the best way right now (But it’s not the SIlverblue/Flatpak way, which is the sad thing). My only problems are that the Toolbox VSCode is missing some fonts and it’s not rendering properly the application text, and also, it’s not working on Wayland, only on Xorg.

The flatpak-spawn approach is not bad, but the extensions integration with SDK would be missing, which is a fundamental feature of the IDE.

I use the Flatpak version of VSCode, and either use Flatpak extensions to add what I need to the VSCode environment, or have it in my home directory so Flatpak can see it anyway.

In my case for example I doing some stuff with Flutter, and while the SDK can be installed at $HOME, it requires libstdc++.i686 (Or something like that) to work. I will have a look into Flatpak extensions and how they work but I think there is no Flutter extension yet.

oh, the vscode manifest might need to add the org.freedesktop.Platform.Compat.i386 extension to get multilib.

Can I try it somehow locally?

I have tried adding this to the metadata file in /var/lib/flatpak/app/com.visualstudio.code/current/active

[Extension org.freedesktop.Platform.Compat.i386]
version=18.04
directory=lib

But I’m actually clueless on how to do this

So I installed VSCode into a named toolbox container. To start VSCode from localhost without entering the toolbox I do this,

toolbox run -c $MYTOOLBOXNAME bash -c "code"
1 Like

What was the failure that you saw when you tried to run Visual Studio Code on Wayland?

Running code from toolbox would be a valid option… Only for some reason the Adwaita (dark) theme is not applied to the menu-bar and menu which is a huge no-go for me.

There is a way to ssh into your container though, something like this:

⬢[root@toolbox ~]# dnf install -y openssh-server
Fedora Modular 31 - x86_64                                                                                                     
...
Complete!
⬢[root@toolbox ~]# /usr/libexec/openssh/sshd-keygen dsa
⬢[root@toolbox ~]# /usr/libexec/openssh/sshd-keygen rsa
⬢[root@toolbox ~]# /usr/libexec/openssh/sshd-keygen ecdsa
⬢[root@toolbox ~]# /usr/libexec/openssh/sshd-keygen ed25519

Open /etc/ssh/sshd_config to change the line with:

#
# Port 22
#AddressFamily any

in

#
Port 2222
#AddressFamily any

And you can now fire the sshd with:

 ⬢[root@toolbox ~]# /usr/sbin/sshd 

Due to container limitations this sshd won’t be able to allocate a /dev/pty, so interactive shells won’t work:

$ ssh -p 2222 localhost
Connection to localhost closed by remote host.
Connection to localhost closed.

But non-interactive ssh sessions work just fine:

 $ ssh -p 2223 localhost date
 Wed Jan  1 13:57:54 CET 2020

And apparently that’s enough for a remote ssh connection from VS Code.

Adding the following to ~/.ssh/config and you’re ready to roll:

Host ToolboxDev
  Port 2222
  HostName localhost
1 Like

For me it was /usr/share/code/bin/../code: error while loading shared libraries: libX11-xcb.so.1: cannot open shared object file: No such file or directory

Interesting. What do you see if you enter the toolbox and run ldd against the VS Code binary?

❯ ldd /usr/bin/code
	not a dynamic executable

I had installed libX11-xcb and everything works now.

Ah, it seems like /usr/bin/code is a wrapper script. ldd needs to be pointed at the actual ELF binary. Ultimately, I think this is a bug in the VS Code packaging where the libX11-xcb dependency was left out.

Anyway, I am glad you managed to figure it out.

In case anyone’s interested, I wrote down a simple guide to configuring a Toolbox/SSH/VSCode setup.

It’s a combination of @buzzy’s post and CLions’s approach with WSL. I experienced several hurdles along the way, so I decided to document it at least.

Overall, the workflow I ended up with is completely seemless, everything just works the way it should without workarounds. For me this is the way to do dev work on Silverblue atm.

5 Likes

Looks interesting! Thanks for the write up. I use a Toolbox for my project’s dev environment, and use Ansible to provision it (so it’s easy to set up again on a new laptop), but even with this I’ve more or less given up using VSCode and gone back to nvim because it’s cumbersome to run VSCode inside the toolbox (although the fact that it’s possible at all is very cool) and the Flatpak version alone is too restrictive for an IDE. This looks like a step up from my current workflow.

1 Like

It works! But how do you solve the issue of executables not being found by extensions in the built-in shell? I do Ruby development, and the Solargraph extension needs the solargraph executable. I tried to point the extension to use bundler, and if I start a terminal, I can type bundle exec solargraph and it works, but the solargraph extension itself doesn’t work. Probably some path thing that needs a proper config?

I have not had a problem like this. I use clangd along with its extension for C++ development, the whole thing runs inside the Toolbox. Maybe you haven’t installed the extension inside the remote? Try looking in the extensions tab, there should be an option for that.