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. In Finder, open the Applications folder and double click on the Utilities folder. Double click on the Terminal application. You can drag this icon to your dock for easy access. Step 2: Enter the standard SSH command. SSH (or Secure Shell) is a great service to enable on your Mac at home or work. This useful tool not only enables the ability to remotely access the command line interface of your Mac, but also to. Open PuTTY as normal, filling in the IP address or DNS alias name. Before clicking OK to connect to the server, go to the connection menu in PuTTY, select SSH, X11 and tick the box X11 forwarding.

• Ssh Config Settings
• User Ssh Config File
• Open Ssh Config File Mac

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:

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

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:

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.

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).

Ssh Config Settings

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.

So far in this series of posts on ssh on macOS:

• Transferring files with ssh (this post)
• SSH Tunnels (upcoming)

Please consider supporting Scripting OS X by buying one of my books!

In the previous posts we looked how to connect with ssh to a remote computer (host) and how to setup the keys necessary for a secure connection.

Despite the name ssh does not actually provide a shell or command line interface to the host itself. it ‘merely’ provides a secure connection to connect to the default shell on the host itself.

Even this basic use of ssh is already very useful and powerful. It allows to open one or more full command line sessions to remote computers as if we sat at their keyboard. You can also send individual commands and receive and process the results.

However, ssh has a few more powerful tools available.

Copy Files Remotely

You can also use the ssh connection to copy files to and from a remote host.

The command you use for this is scp (secure copy) and it use the same basic syntax as the cp command

But, since scp can copy from the local computer to a remote host or vice versa, you usually add a bit more information:

(The examples will use a file name hello.txt. To create one quickly, simply type echo 'Hello SSH' > hello.txt in Terminal.)
To simplify this, a few examples:

This will copy the local file sample.txt from the current working directory to the remote host’s ~/Documents/ directory. scp will show an ascii progress bar for every file copied. (though with these small files, you will not see much of it) You can suppress the progress display with the -q (quite) option.

For the destination, the colon : separates the hostname (DNS) from the file path.

This command will prompt for the user’s password on the remote host, unless you have added your public key to the remote host’s authorized_keys file.

Since no user name is given before the hostname (separated with an @) scp uses the username that you are logged in with on the local computer. If the remote user has a different name, use:

We do not want the local shell to evaluate the ~ to the local home directory, but want the remote computer to evaluate ~ to the remote user’s home directory, so we have to quote the remote path.

Like cp, when the source is a file and the destination is a directory, then the file will be placed into the destination directory.

If the remote path does not exist, then scp will present an error:

User Ssh Config File

You can also rename the file while copying:

You can copy files from the remote host to your local machine:

In this case we passed . or the current working directory as the destination. You can also pass a local path:

Use the -r option to copy all the contents of a directory:

Remote-to-remote Copies

You can copy from one remote host to another.

There are two solutions for this. The first will copy the file to the local computer and then back up to the other remote host. You invoke this version of remote-to-remote with the -3 option.

(I am shortening the full domain names from primus.example.com and secundus.example.com to primus and secundus for simplicity.)

Under most circumstances copying a file down to your Mac and then back up to the other remote host is less than ideal. Imagine you are working from home with your laptop and want to copy a large file from one server at work to another.

The other option is to tell the source remote host to scp the to the other remote host. You could achieve this by sshing to the remote machine and running scp from there. Thankfully, scp is smart enough to attempt exactly that when you type

This command will probably fail right now. It requires a few things to be set up to work:

• either: client key authentication to be setup from primus to secundus
• or: client key authentication from your local computer to primus and secundus with agent forwarding enabled

The first option is fairly easy to understand. scp will connect to primus and authenticate with your local client key. Then it will tell primus to connect to secundus, authenticating using primus’ client key and the copy the file. It basically works as if you sshed in to primus and ran scp without the extra typing.

There are drawbacks to this. If ssh-agent is not running on primus and does not have the passphrase stored yet, then primus cannot unlock its private key and authenticate to secundus.

Also you basically need to prepare all remote hosts to have keys exchanged between each other, which can be painful, if not impossible to manage.

Agent Forwarding

The second option, called ‘Agent Forwarding’, circumvents these problems. This will tell the first remote host (primus) to ask your local ssh-agent for a key to authenticate to secundus. The system does not actually transfer the private key, but asks ssh-agent on your local computer to encode the authentication challenge for primus.

That way you only need to manage the keys for all remote hosts on your local computer.

You can also use agent forwarding with normal ssh connections. It is not enabled by default, but you can enable it for an ssh session with the -o ForwardAgent=yes option:

Since this is hard to type, there is a shortcut:

When you are logged in to the remote host with agent forwarding enabled, you can then ssh from there to another remote host (secundus) and it will try to use the keys from your local computer’s ssh-agent to authenticate.

This can be a useful strategy if direct access to the second remote host (other.mac.com) is blocked with firewalls.

You can also use this for the scp remote-to-remote copy. Unfortunately, scp does not have a convenient -A option, so you have to use the long parameter form:

When you need agent forwarding regularly for a specific host, you can enable it by default for this particular host in your ~/.ssh/config file. Add the following lines:

Note: There are some security concerns with agent forwarding. A user with root access on the intermediate system can gain access to the connection to your local ssh-agent, thus gaining the ability to encrypt with your private keys. Be aware of this in security sensitive environments.

SFTP

If you have many files in a complex file structure , scp can be a little cumbersome. There is a special interactive mode that you can invoke with the sftp command (secure file transfer program).

Note: sftp(according to its man page) is ‘similar’ to ftp but not identical. It also should not be confused with ftps which is ftp over SSL.

Obviously, if you have key authentication setup, sftp will use that.

There are many interactive commands to navigate the local and remote file system and upload (put) and download (get) files. You can look at the details in the sftp man page. However, if you need to use sftp frequently, then you should use a graphical sftp application. There are a large number of SFTP client for macOS and iOS. Here is a list of some popular clients: (AppStore links are affiliate links.)

• Transmit (Mac Version, also iOS AppStore): Aside from a great macOS application, Transmit also comes as an iOS App.
  Update 2018-01-10:Panic is going to cease development and sale of Transmit for iOS for the time being
• Fetch (Mac AppStore): Fetch offers free licenses for educational and charitable organisations
• CyberDuck (Mac AppStore): CyberDuck has an optional command line tool
• MountainDuck (Mac AppStore): Sibling to CyberDuck, but mounts remote servers in the Finder.
• FileZilla: free open source solution

All of these tools connect to many other server protocols other than sftp. However, the advantage of sftp is not just the built-in security, but that you don’t need other software than sshd running on the server.

Summary

Previous Post: Client Verification

• you can use scp [[user@]host:]source [[user@]host:]destination to copy files from or to a remote host over ssh
• you can use agent forwarding to simplify key management in triangle setups
• sftp help managing/transferring multiple files over ssh, there are many UI applications

Open Ssh Config File Mac

Next Post: SSH Tunnels