Tag Archives: Linux

VSCode, SSH, and you

In this very short post we’ll take a look at how to properly set up your environment to allow you working with your local IDE to a remote server.

Identity files

Since you’re logging through an identity file — because you’re not logging in with a password now, are you? — we need to bind a specified host to a user and identity file, also known as OpenSSH private key. To do so we modify or create ~/.ssh/config or %UserProfile%\.ssh\config on Windows. The file structure is pretty simple:

Host <ip/hostname>
	User <username>
	IdentityFile <PEM file path>

With that information saved, we can simply ssh <ip/hostname> to remote in, without specifying anything.

Identity passphrase

The next problem in our automation process is to store the passphrase for the session, to avoid manual prompts each time we start a remote instance of VSCode. In order to do this we need to ensure that ssh-agent is running properly. On Windows it’s enough to make sure that the “OpenSSH Authentication Agent” service is running, while on Linux it depends on the distro. Generally, we can make sure that it’s running by issuing ps x | grep ssh-[a]gent, and running ssh-agent once if it’s not.

Now we can simply ssh-add <PEM file path>, insert our passphrase, and ssh with reckless abandon.

Visual Studio Code

The majority of the work has now been done, we can simply install the Remote Development extension, and to remote in we select “Remote SSH: Connect to Host…” from the command palette, or press on the little green area in the bottom left part of the status bar.

From there we just “Open folder” and navigate the remote server directory structure, open where we want and code at leisure.

Samba, Windows, *nix, SELinux and you

Let’s face it: SMB/CIFS comes in handy plenty of times. Works great under Linux, works great with Windows, and if it’s configured properly it’s fun times for everyone. There are multiple potential behavioural problems though, mostly involving charsets.

Samba charset (and filesystem) setup

While I’ve been successfully using iso-8859-1 by default for a long time in my Samba servers, until recently I also used the same charset in the *nix filesystem, which brought all kind of oddities. 20/20 hindsight, as per usual. In smb.conf, you can configurn though you can specify different charsets to make everyone happy:

[global]
dos charset = iso-8859-1
unix charset = utf-8
preserve case = yes
short preserve case = yes
default case = lower
case sensitive = no

This has multiple advantages:

  • Windows gets its iso-8859-1 charset, and is happy;
  • Linux gets its utf-8 charset, and is happy;
  • preserve cases make sure that filenames aren’t changed while moving files across machines;
  • disabling case sensitive avoid weird behaviour under Windows.

This is the configuration I’ve been running for years, sharing files across Windows/Linux/OS X machines since Windows XP, and has been working perfectly.

Changing filesystem charset

If you’re switching the unix charset though, you might need to convert existing files/directories to the new charset. Cue in convmv:

convmv -f <from_charset> -t <to_charset> -r --preserve-mtimes <dir>

In my case:

convmv -f iso-8859-1 -t utf-8 -r --preserve-mtimes .

With this simple command I was able to mass rename thousands of files in one go. Note that you also need the --notest parameter to actually apply the changes, and not just list the files in a dry run.

SELinux

While playing around Centos I stumbled into SELinux problems I wasn’t prepared for. Consider the following:

[Share]
comment = Personal share
path = /home/<username>/share/
guest ok = no
browseable = yes
writable = no
create mask = 0660
directory mask = 0775
write list = <username>

Supposing the path actually exists, that the username is added to the samba user database and that the password is correct, everything should work fine. Except that it mostly likely won’t, because we need to configure SELinux on top of everything else:

restorecon -R -v /home/<username>/share/
chcon -R -t samba_share_t /home/<username>/share/

That’s all there is to properly setup and have the content accessible. Contrary to what other people claims, you don’t have to increase permissions in the samba path tree. A 0700 on the /home/<user> works perfectly fine.