Start or restart the Remote Login (SSH) Service under System Preference / Sharing pane on Mac OS X. The SSH daemon should run on the remote machine as well! See “man ssh”, “man sshconfig” and “man sshdconfig” for the complete explanation. 3 Simple Steps to X11 Forward on Mac OS X. Open “Terminal” in Mac OS X Leopard. The config files are all hidden in some deep directories, and they use a plist format, i messed with them at one point, but i don't remember where the files are, sorry. Pretty much its all in an xml style formatting, instead of a simple unix type config. This post totally ignores the fact that Big Sur has changed the way the ssh client works (basically f.ed it up). On many linux servers you cannot connect to using SSH unless you solve this client side in Big Sur on your Mac, by editing the /etc/ssh/sshconfig file and removing or commenting out the line “SendEnv LANG LC.” so the last part reads. I tried editing the /etc/ssh/sshconfig file on my Mac to change the forwardX11 from no to yes, and this to enable X11 features. I try to change permission in the file sshconfig and in the folder etc, I did it, but in vain; still no permission to go inside the file to change something. SSH Config generates an SSH config file adapted to the network you are currently using. In this way, you always use the fastest paths available for your SSH related activities (sshfs, email, vnc, mercurial, etc.).

October 3, 2019 by Sana Ajani, @sana_ajani

In a previous Remote SSH blog post, we went over how to set up a Linux virtual machine and connect to the VM using the Remote - SSH extension in Visual Studio Code. In this blog post, we'll go into some tips and tricks that you can use to get the most out of your remote setup.

Connect using Remote SSH

The Visual Studio Code Remote - SSH extension allows you to connect to a remote machine or VM using SSH, all from inside VS Code. If you don't already have the extension installed, you can search for 'remote ssh' in the Extensions view (⇧⌘X (Windows, Linux Ctrl+Shift+X)).

After you install the extension, you'll notice an indicator on the bottom-left corner of the Status bar. This indicator tells you in which context VS Code is running (local or remote). Click on the indicator to bring up a list of Remote extension commands.

SSH configuration file

In the earlier Remote SSH blog post, we only connected to a single machine and did so by entering the 'user@host' when prompted. If you log in to multiple remote servers or local virtual machines on a regular basis, there's a better way to connect without having to remember all the usernames, addresses, and additional configuration options.

OpenSSH supports using a configuration file to store all your different SSH connections. To use an SSH config file, click on the remote indicator to bring up the remote commands, choose Open Configuration File, and select the file that follows the path 'Users/{yourusername}/.ssh/config'.

Here's an example of an SSH config file:

Ssh Config Settings

There are many more configuration options you can specify in the SSH config file format. You'll get completions and colorizations in this file and you can press (⌃Space (Windows, Linux Ctrl+Space)) for IntelliSense to learn more about the config options.

The options used above are:

You can add the information for all the hosts you have. Once you've saved the config file, you'll be able to see those hosts in the Remote Explorer, as well as any folders you have opened on that host. You can select the icon next to each host or folder and it will launch a new VS Code window (instance) and connect you to that host. In the screenshot below, I'm connected to my remote machine 'python-linux-vm' and the Remote Explorer shows me the folders I have connected to in the past, as well as any forwarded ports from the remote machine.

ProxyCommand

Sometimes you may need to connect from your desktop or laptop to a remote machine over your company's Intranet or behind a firewall. In this case, you may be using an intermediate server or jump box. This kind of setup is useful if you are working within a secure system that is configured to only accept SSH connections from a fixed set of hosts.

To use a jump-box setup with the Remote - SSH extension, you can use the ProxyCommand config option. This configuration will open a background SSH connection to the jump box, and then connect via a private IP address to the target.

You can set the ProxyCommand config option in the SSH config file like this:

ControlMaster

If you are connecting to a remote SSH host using other authentication methods besides key-based authentication, such as two-factor, password-based, or an SSH key with a passphrase, you may have to enter the required information multiple times.

Instead of opening multiple SSH connections, you can use ControlMaster option (only on macOS/Linux clients) to reuse an existing connection and reduce the number of times you must enter your passphrase.

To use this feature, add the following to your SSH config file:

Offline remote machine

If you are restricted by a firewall or your company locks down your VMs and they cannot connect to the Internet, the Remote - SSH extension won't be able to connect to your VM because VS Code needs to download a component called the VS Code Server to the remote machine.

However, you can now solve this issue by a new user setting in the Remote - SSH extension. If you enable the setting remote.SSH.allowLocalServerDownload, the extension will install the VS Code Server on the client first and then copy it over to the server via SCP.

Note: This is currently an experimental feature but will be turned on by default in the next release.

Remote - SSH Nightly extension

If you're interested in testing new updates and experimental features as soon as they are available, install the Remote - SSH Nightly extension (uninstall the Remote-SSH stable extension first). This is the nightly build of the extension where we experiment with new features and settings before releasing them into the stable version.

We'd like your feedback

Thanks for trying out the Remote - SSH extension! If you run into any issues or would like to suggest new features or scenarios for us, please open an issue on our GitHub repo. If you want to see what features we're currently working on or are upcoming, take a look at our Remote Development release notes and iteration plans. You can also try out the introductory Remote development over SSH tutorial, which walk you through using the other remote extensions to work inside Docker containers and the Window Subsystem for Linux (WSL).

Happy Remote Coding,

Sana Ajani, VS Code Program Manager @sana_ajani

Parent page: Internet and Networking >> SSH

Once you have installed an OpenSSH server,

you will need to configure it by editing the sshd_config file in the /etc/ssh directory.

First, make a backup of your sshd_config file by copying it to your home directory, or by making a read-only copy in /etc/ssh by doing:

Creating a read-only backup in /etc/ssh means you'll always be able to find a known-good configuration when you need it.

Once you've backed up your sshd_config file, you can make changes with any text editor, for example;

runs the standard text editor in Ubuntu 12.04 or more recent. For older versions replace 'sudo' with 'gksudo'. Once you've made your changes (see the suggestions in the rest of this page), you can apply them by saving the file then doing:

If you get the error, 'Unable to connect to Upstart', restart ssh with the following:

Configuring OpenSSH means striking a balance between security and ease-of-use. Ubuntu's default configuration tries to be as secure as possible without making it impossible to use in common use cases. This page discusses some changes you can make, and how they affect the balance between security and ease-of-use. When reading each section, you should decide what balance is right for your specific situation.

Because a lot of people with SSH servers use weak passwords, many online attackers will look for an SSH server, then start guessing passwords at random. An attacker can try thousands of passwords in an hour, and guess even the strongest password given enough time. The recommended solution is to use SSH keys instead of passwords. To be as hard to guess as a normal SSH key, a password would have to contain 634 random letters and numbers. If you'll always be able to log in to your computer with an SSH key, you should disable password authentication altogether.

If you disable password authentication, it will only be possible to connect from computers you have specifically approved. This massively improves your security, but makes it impossible for you to connect to your own computer from a friend's PC without pre-approving the PC, or from your own laptop when you accidentally delete your key.

It's recommended to disable password authentication unless you have a specific reason not to.

To disable password authentication, look for the following line in your sshd_config file:

replace it with a line that looks like this:

Once you have saved the file and restarted your SSH server, you shouldn't even be asked for a password when you log in.

By default, you can tunnel network connections through an SSH session. For example, you could connect over the Internet to your PC, tunnel a remote desktop connection, and access your desktop. This is known as 'port forwarding'.

By default, you can also tunnel specific graphical applications through an SSH session. For example, you could connect over the Internet to your PC and run nautilus 'file://$HOME' to see your PC's home folder. This is known as 'X11 forwarding'.

While both of these are very useful, they also give more options to an attacker who has already guessed your password. Disabling these options gives you a little security, but not as much as you'd think. With access to a normal shell, a resourceful attacker can replicate both of these techniques and a specially-modified SSH client.

It's only recommended to disable forwarding if you also use SSH keys with specified commands.

To disable forwarding, look for the following lines in your sshd_config:

and replace them with:

If either of the above lines don't exist, just add the replacement to the bottom of the file. You can disable each of these independently if you prefer.

You can explicitly allow or deny access for certain users or groups. For example, if you have a family PC where most people have weak passwords, you might want to allow SSH access just for yourself.

Allowing or denying SSH access for specific users can significantly improve your security if users with poor security practices don't need SSH access.

It's recommended to specify which accounts can use SSH if only a few users want (not) to use SSH.

To allow only the users Fred and Wilma to connect to your computer, add the following line to the bottom of the sshd_config file:

To allow everyone except the users Dino and Pebbles to connect to your computer, add the following line to the bottom of the sshd_config file:

It's possible to create very complex rules about who can use SSH - you can allow or deny specific groups of users, or users whose names match a specific pattern, or who are logging in from a specific location. For more details about how to create complex rules, see the sshd_config man page

It's possible to limit the rate at which one IP address can establish new SSH connections by configuring the uncomplicated firewall (ufw). If an IP address is tries to connect more than 10 times in 30 seconds, all the following attempts will fail since the connections will be DROPped. The rule is added to the firewall by running a single command:

On a single-user or low-powered system, such as a laptop, the number of total simultaneous pending (not yet authorized) login connections to the system can also be limited. This example will allow two pending connections. Between the third and tenth connection the system will start randomly dropping connections from 30% up to 100% at the tenth simultaneous connection. This should be set in sshd_config.

In a multi-user or server environment, these numbers should be set significantly higher depending on resources and demand to alleviate denial-of-access attacks. Setting a lower the login grace time (time to keep pending connections alive while waiting for authorization) can be a good idea as it frees up pending connections quicker but at the expense of convenience.

By default, the OpenSSH server logs to the AUTH facility of syslog, at the INFO level. If you want to record more information - such as failed login attempts - you should increase the logging level to VERBOSE.

It's recommended to log more information if you're curious about malicious SSH traffic.

To increase the level, find the following line in your sshd_config:

and change it to this:

Now all the details of ssh login attempts will be saved in your /var/log/auth.log file.

If you have started using a different port, or if you think your server is well-enough hidden not to need much security, you should increase your logging level and examine your auth.log file every so often. If you find a significant number of spurious login attempts, then your computer is under attack and you need more security.

Whatever security precautions you've taken, you might want to set the logging level to VERBOSE for a week, and see how much spurious traffic you get. It can be a sobering experience to see just how much your computer gets attacked.

If you want to try to scare novice attackers, it can be funny to display a banner containing legalese. This doesn't add any security, because anyone that's managed to break in won't care about a 'no trespassing' sign--but it might give a bad guy a chuckle.

To add a banner that will be displayed before authentication, find this line:

and replace it with:

This will display the contents of the /etc/issue.net file, which you should edit to your taste. If you want to display the same banner to SSH users as to users logging in on a local console, replace the line with:

To edit the banner itself try

Here is an example for what you might put in an issue or issue.net file and you could just copy&paste this in:

Ssh Configuration File

Once you have finished editing sshd_config, make sure to save your changes before restarting your SSH daemon.

Ssh Config File Location

First, check that your SSH daemon is running:

This command should produce a line like this:

If there is no line, your SSH daemon is not running. If it is, you should next check that it's listening for incoming connections:

This command should produce a line that looks like one of these:

Open Ssh Config File Mac Os

If there is more than one line, in particular with a port number different than 22, then your SSH daemon is listening on more than one port - you might want to go back and delete some Port lines in your sshd_config. If there are no lines, your SSH daemon is not listening on any ports, so you need to add at least one Port line. If the line specifies something other than '*:22' ([::]:22 is IPv6), then your SSH daemon is listening on a non-standard port or address, which you might want to fix.

Next, try logging in from your own computer:

This will print a lot of debugging information, and will try to connect to your SSH server. You should be prompted to type your password, and you should get another command-line when you type your password in. If this works, then your SSH server is listening on the standard SSH port. If you have set your computer to listen on a non-standard port, then you will need to go back and comment out (or delete) a line in your configuration that reads Port 22. Otherwise, your SSH server has been configured correctly.

Mac Ssh Config File

To leave the SSH command-line, type:

If you have a local network (such as a home or office network), next try logging in from one of the other computers on your network. If nothing happens, you might need to tell your computer's firewall to allow connections on port 22 (or from the non-standard port you chose earlier).

Open Ssh Config File Mac

Finally, try logging in from another computer elsewhere on the Internet - perhaps from work (if your computer is at home) or from home (if your computer is at your work). If you can't access your computer this way, you might need to tell your router's firewall to allow connections from port 22, and might also need to configure Network Address Translation.