Linux ssh config file

Ubuntu Documentation

Introduction

Once you have installed an OpenSSH server,

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

sshd_config is the configuration file for the OpenSSH server. ssh_config is the configuration file for the OpenSSH client. Make sure not to get them mixed up.

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.

Disable Password Authentication

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:

#PasswordAuthentication yes

replace it with a line that looks like this:

PasswordAuthentication no

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

Disable Forwarding

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:

AllowTcpForwarding yes

X11Forwarding yes

and replace them with:

AllowTcpForwarding no

X11Forwarding no

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.

Specify Which Accounts Can Use SSH

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:

AllowUsers Fred Wilma

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:

DenyUsers Dino Pebbles

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

Rate-limit the connections

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.

MaxStartups 2:30:10

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.

LoginGraceTime 30

Log More Information

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:

LogLevel INFO

and change it to this:

LogLevel VERBOSE

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.

Display a Banner

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:

#Banner /etc/issue.net

and replace it with:

Banner /etc/issue.net

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:

Banner /etc/issue

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:

Troubleshooting

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

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.

SSH/OpenSSH/Configuring (последним исправлял пользователь peterson-ca 2015-08-24 19:51:36)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

OpenSSH Config File Examples For Linux / Unix Users

H ow do I create and setup an OpenSSH config file to create shortcuts for servers I frequently access under Linux or Unix desktop operating systems?

We can set up a global or local configuration file for SSH clients can create shortcuts for sshd servers, including advanced ssh client options.

Tutorial details
Difficulty level	Intermediate
Root privileges	Yes
Requirements	OpenSSH client
Est. reading time	7 mintues

You can configure your OpenSSH ssh client using various files as follows to save time and typing frequently used ssh client command-line options such as port, user, hostname, identity-file, and much more to increase your productivity from Linux/macOS or Unix desktop:

You can configure your OpenSSH ssh client to save typing time for frequently used ssh client command-line options such as port number, user name, hostname/IP address, identity file, and much more. In addition to that it will increase your productivity from Linux/macOS or Unix desktop.

System-wide OpenSSH config file client configuration

1. /etc/ssh/ssh_config : This files set the default configuration for all users of OpenSSH clients on that desktop/laptop and it must be readable by all users on the system.

User-specific OpenSSH file client configuration

/.ssh/config or $HOME/.ssh/config : This is user’s own configuration file which, overrides the settings in the global client configuration file, /etc/ssh/ssh_config.

/.ssh/config file rules

The rules are as follows to create an ssh config file:

You need to edit

/.ssh/config with a text editor such as vi.
One config parameter per line is allowed in the configuration file with the parameter name followed by its value or values. The syntax is:

Tip : If this is a brand new Linux, macOS/Unix box, or if you have never used ssh before create the

/.ssh/ directory first using the following syntax:
mkdir -p $HOME/.ssh
chmod 0700 $HOME/.ssh

Examples

For demonstration purpose my sample setup is as follows:

1. Local desktop client – Apple macOS/OS X/Ubuntu Linux.
2. Remote Unix server – OpenBSD server running latest OpenSSH server.
3. OpenSSH remote server ip/host: 75.126.153.206 (server1.cyberciti.biz)
4. Remote OpenSSH server user: nixcraft
5. OpenSSH dest port: 4242
6. Local ssh private key file path : /nfs/shared/users/nixcraft/keys/server1/id_rsa

Based upon the above information my ssh command is as follows:
$ ssh -i /nfs/shared/users/nixcraft/keys/server1/id_rsa -p 4242 nixcraft@server1.cyberciti.biz
OR
$ ssh -i /nfs/shared/users/nixcraft/keys/server1/id_rsa -p 4242 -l nixcraft server1.cyberciti.biz
See how much I need to type. I need to remember the remote hostname/IP, port number, the path to ssh key, username, etc. Too much typing and is not increasing my productivity. But fear not, there is an easy way out.

Using the ssh config file

You can avoid typing all of the ssh command parameters while logging into a remote machine and/or for executing commands on a remote machine. All you have to do is create an ssh config file. Open the Terminal application and create your config file by typing the following command:

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

Add/Append the following config option for a shortcut to server1 as per our sample setup:

Save and close the file in vi/vim by pressing Esc key, type :w and hit Enter key. To open your new SSH session to server1.cyberciti.biz by typing the following command:
$ ssh server1

Adding another host

Append the following to your

You can simply type:
$ ssh nas01

Understanding Host Patterns

A pattern for Host directive is nothing but IP address, DNS hostname, or combination of special wildcard characters. For example, ? wildcard that matches exactly one character. On the other hand, * wildcard matches zero or more characters. It allows us to define the usage pattern. For instance, to specify and allow login from laptop.sweet.home , desktop.sweet.home , rpi.sweet.home , and corerouter.sweet.home , I could use the following pattern:

The following pattern would match any host in the 192.168.2.9 network range:

We can also set a pattern list. It is a comma-separated list of patterns. Patterns within pattern lists may be negated by preceding them with an exclamation mark ( ! ) in your authorized_keys. Here is an example from

/.ssh/authorized_keys file on the remote server. First, login to the remote box:
$ ssh vivek@192.168.2.17
Now edit the file, run:
$ vim

/.ssh/authorized_keys
Update it as follows:

Putting it all together

Here is my sample

/.ssh/config file that explains and create, design, and evaluate different needs for remote access using ssh client:

Understanding

• Host : Defines for which host or hosts the configuration section applies. The section ends with a new Host section or the end of the file. A single * as a pattern can be used to provide global defaults for all hosts.
• HostName : Specifies the real host name to log into. Numeric IP addresses are also permitted.
• User : Defines the username for the SSH connection.
• IdentityFile : Specifies a file from which the user’s DSA, ECDSA or DSA authentication identity is read. The default is

/.ssh/identity for protocol version 1, and

/.ssh/id_rsa for protocol version 2.

ProxyCommand : Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed with the user’s shell. In the command string, any occurrence of %h will be substituted by the host name to connect, %p by the port, and %r by the remote user name. The command can be basically anything, and should read from its standard input and write to its standard output. This directive is useful in conjunction with nc(1) and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.1.0.253:
ProxyCommand /usr/bin/nc -X connect -x 192.1.0.253:3128 %h %p

LocalForward : Specifies that a TCP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument must be [bind_address:]port and the second argument must be host:hostport.

Port : Specifies the port number to connect on the remote host.

Protocol : Specifies the protocol versions ssh(1) should support in order of preference. The possible values are 1 and 2.

ServerAliveInterval : Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. See blogpost “Open SSH Server connection drops out after few or N minutes of inactivity” for more information.

ServerAliveCountMax : Sets the number of server alive messages which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session.

Speed up ssh session

Multiplexing is nothing but send more than one ssh connection over a single connection. OpenSSH can reuse an existing TCP connection for multiple concurrent SSH sessions. This results into reduction of the overhead of creating new TCP connections. Update your

Источник