If you work in IT, you have probably faced a thousand times the need to log into a device or server remotely - such a task can be performed in several ways, the main two are for controlling a device via the command line - Telnet and Secure Shell (SSH).

There is one main difference between them - in the protocol Telnet all data is transmitted over the network in unencrypted form, and in the case of SSH all commands are encrypted with a special key. SSH was developed as a replacement for Telnet to securely manage network devices over an insecure network such as the Internet. Just in case, remember that Telnet uses the port 22 and SSH is 23 .

Customization

First, you need Packet Tracer- a program for emulating networks from the Cisco company. It is completely free and can be downloaded from netacad.com after registration. Launch Packet Tracer and proceed with configuration.

Build the topology as in the screenshot below - one computer and one Layer 3 switch. You will need to connect them together and start setting up.

Ready? Now we will provide network connectivity and configure the interface vlan 1 on the switch, to do this, enter the following commands:

If immediately after creation in the switch console there is a question whether to start the initial configuration dialog - answer "No".

en conf t interface vlan 1 ip address 192.168.1.1 255.255.255.0 no shutdown

Now let's try to ping the switch and telnet into it from our PC to the switch - and you will see that the connection will be rejected due to the fact that we have not yet configured authentication on the switch.

Let's move on to setting up authentication. The system supports 20 virtual tty / vty lines for Telnet, SSH and FTP services. Each session using the above protocol occupies one line. You can also enhance overall security by validating authorization requests on the device. Switch back to general configuration mode ( conf t) on the switch using the exit command and enter the following commands:

Line vty 0 15 password cisco login end

The cisco password used in this article is extremely unsafe and serves solely for demonstration purposes. If you leave such a password on real hardware, the chances of being hacked are endless. Better use our :)

Now try to Telnet to the switch again - everything should work out! However, when you try to go to configuring and executing the enable command, you will see that this is impossible, due to the fact that the password for the global mode is not set. enable.

To fix this, enter the following commands:

Conf t enable password cisco

Try again - you should be fine now!

Now let's configure SSH on the switch - for this, you must specify the hostname, domain name and generate an encryption key.

Enter the following commands (from the main configuration mode):

Hostname merionet_sw1 ip domain name merionet crypto key generate rsa

Select the key length - by default, the value is equal 512 bits, for SSH version 2 the minimum length is 768 bits. Key generation will take some time.

After generating the key, we will continue configuring the switch:

Ip ssh version 2 line vty 0 15 transport input ssh

Now you won't be able to log in via Telnet, since we replaced it with SSH. Try ssh using the default login admin. Let's change it to something more decent (again from conf t):

Username admin secret cisco line vty 0 15 login local do wr

Now try logging into the switch from your workstation and make sure the new settings take effect.

Was this article helpful to you?

Please tell me why?

We are sorry that the article was not useful to you: (Please, if it does not make it difficult, indicate why? We will be very grateful for a detailed answer. Thank you for helping us become better!

The question “how to set up a connection to Cisco by protocol SSH? " occurs to everyone who encounters this equipment. The answer is "Simple!"
Let's take the router model as an example Cisco 881... The commands for configuring other routers (1841, 2800, 3825 ...) or switches (2900, 3500, 4800 ...) will be similar. The only difference can be in the interface settings. (Configuring protocol access SSH to firewalls Cisco ASA described in the article ""
So, at our disposal:

Task: set up a secure connection to the router Cisco by protocol SSH and provide secure remote management.

Step 0. Configuring the interface

The interface must be enabled on the router to be used for management. In our case it will be interior (LAN) interface Fastethernet 0.

For reference:
On Router Cisco 881 there is one interface 3rd level Fastethernet 4(the one on which you can immediately set IP address) and built-in switch with four interfaces 2nd level ( Fastethernet 0 - Fastethernet 3). For each of these 4 interfaces, you can bind one (!) virtual interface 3rd level. ( Vlan).
For the management interface of the router, select the first available address in the office network - 192.168.0.1 ... Next, go to the settings of the virtual interface Vlan 1 and assign this ip address. After that we bind it to one of the physical router interfaces ( Fastethernet 0) and turn it on with the command no shut.

For clarity:
ip address => interface Vlan X => interface Fastethernet Y
We set ip interface address Vlan 1
R-DELTACONFIG (config) #
interface Vlan 1
ip address 192.168.0.1 255.255.255.0
no shutsown
Bind Vlan 1 to the physical interface FastEthernet 0
R-DELTACONFIG (config) #
interface Fa 0
switchport access vlan 1
no shutsown
The last step is performed in order to make sure that the settings are correct. Vlan 1 bound by default to every interface 2nd level and line will be displayed in the configuration only if the number Vlan will be different from 1.
Next, you need to check the availability of the created interface from the router itself, and then from any workstation in the office, for example, from an administrator's workstation. A simple check with the command will do. Ping... Naturally, the router interface Fastethernet 0 must be connected to the LAN switch (or directly to the administrator's computer) and the address of the computer from which the test is performed is on the same network as the router interface address (for example 192.168.0.10 ).

Step 1 Create Administrator Account

For remote control, you need to create an account, if one does not already exist.
R-DELTACONFIG (config) #
username admin secret *****
Instead of asterisks ******, set the password for the admin account.

Important!
According to the rules of good form, the password consists of uppercase and lowercase letters, numbers and specials. characters, at the same time not shorter than 8 characters.

Step 2 setting the password for the configuration mode

When you open the router's management console, the user enters the simplified mode, from which it is possible to view only some of the device's parameters and technical information about it. In this case, next to the name of the device there is an arrow sign “ > »
R-DELTACONFIG>
To view the router configuration and further configure it, enter the command enable
> enable
#
Initially, this mode is not password protected and any user who connected with a console cable (about the cable and how to connect is described in) will be able to get into configuration mode... On the other hand, the user who connected remotely ( ssh / telnet), for which no privilege level is set (just our case), will not be able to enter the configuration mode.
Set a password for privileged mode(hash sign # next to the router name) by entering the configuration mode ( conf t).
R-DELTACONFIG (config) #
R-DELTACONFIG (config) # enable secret ******
This password will be the same for all users.
You can read more about the configuration modes.

Step 3. Enabling Remote Control

For remote control, you must specify the user authentication method with the command login local
R-DELTACONFIG (config) #
line vty 0 4
login local
After completing this step and provided that the management interface of the router is available to the user, it becomes possible to connect to the router using the protocol telnet... To do this, run the command from the command line of the administrator's workstation
C: \ Documents and Settings \ ***> telnet 192.168.0.1
There should be a request for the user and password that were set in step 1... After successful authorization, it will be available simplified router management mode (with the arrow " > "). To access privileged mode ( # ) you must enter the command enable, and after the password from step 2.

Step 4 Configuring SSH

When using the protocol Telnet(TCP port 23) all commands and device configuration data are transmitted in clear text, which is potentially insecure. The protocol is used to secure the connection SSH(TCP port 22).
To set up a protocol connection SSH you need to set a domain name (any), generate a cryptographic access key and enable the protocol itself SSH version 2.
R-DELTACONFIG (config) #
ip domain-name site
crypto key generate rsa
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
// after the request, you must specify 1024
How many bits in the modulus: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable ...
ip ssh ver 2
After completing this step, it becomes possible to connect via SSH using a special program that supports this function, for example putty... You can download this link.

Step 5. Restricting the connection to the router via SSH only

In order to exclude the possibility of connecting to the router via the protocol Telnet you must enter the following commands:
R-DELTACONFIG (config) #
line vty 0 4
transport input ssh
After that, remote access to the device console will not be possible except via the SSH protocol.
Additionally, you can restrict access to the management of a Cisco router or switch only from certain IP addresses. How to do it is described.

Important!
Be careful about accessing devices. Do not neglect the protection of connection and restriction of the circle of persons allowed to operate.

Important!

Do not forget save configuration of all devices with the command write or copy run start... Otherwise, after a reboot, all changes will be lost.
write
Building configuration ...

SSH protocol is often used for remote management of routers and switches. In particular, for the management of Cisco network equipment. Configuring this equipment for connecting via SSH will be discussed in this article.

Why SSH for Cisco

SSH is a secure protocol that will discourage pickers and burglars who want to take over your Cisco network equipment.

But proper configuration is essential if you want your router to be safe.

And for Cisco, configuring the SSH protocol is carried out according to special rules, not in the same way as creating remote server management in Free BSD.

How to set up SSH connection for Cisco

The setup begins with the fact that you need to enter privileged mode. To do this, use the following command: cisco> enable. It is best to use a public key to connect to equipment, therefore it is recommended to generate RSA. And for this, in Cisco, you need to set the exact date and time, otherwise the key will not work: cisco # clock set 17:10:00 28 Aug 2016. After that, go to the direct configuration change mode, which you will need to create a connection via SSH protocol: cisco # configure terminal

To generate a public key, you will need to enter the domain name under which the client will connect to the network equipment. To do this, use the command: cisco (config) # ip domain name domain_name.ru. After that, you can generate an RSA key using the following combination: cisco (config) # crypto key generate rsa. If you want to strengthen the protection of your network equipment, you can use additional passwords, just activate their encryption first using the command: cisco (config) # service password-encryption.

Next, you have to create a user, create a password for it and specify the access level: cisco (config) # username username privilege 15 password 7 password. Only after you have created at least one user on the system can you start the AAA protocol using the following command: cisco (config) # aaa new-model. And in order to finally launch terminal lines via SSH protocol, you need to go to their configuration. To do this, write: cisco (config) # line vty 0 4, where you can specify the configuration value from 0 to 4. After that, you can activate the connection via SSH protocol - write cisco (config-line) # transport input ssh.

Although you have already started terminal lines over SSH, enter this function to save the changes: cisco (config-line) # logging synchronous, and also write down the value for the SSH session timeout: cisco (config-line) # exec-timeout 60 0. After that, exit config-line and config. Finally, add new configurations to the Cisco network equipment system: cisco # copy running-config startup-config. That's it - the job is done, your equipment will now work over a secure SSH connection.

Connecting and configuring Cisco Catalyst 2960 has its own nuances and is somewhat different from connecting equipment from other manufacturers.

Connecting and configuring Cisco Catalyst 2960 has its own nuances and is somewhat different from connecting equipment from other manufacturers. The initial setup will require a proprietary RJ-45-RS-232 flat cable (in blue braid, supplied with the equipment) and a COM port on the computer's motherboard through which the setup procedures will be performed.

There is no COM port on motherboards of modern computers, so a special adapter is required to carry out the configuration. Cisco uses Mini-USB connectors in its console hardware. To configure via the Mini-USB port, download the cisco usb console driver program.

Configuring Hyper Terminal

If the setup procedure is performed using the Windows 7/8 operating system, then there will be a problem with the absence of HyperTerminal. It can be quickly solved by copying the required folder with Windows XP OS to any directory of Windows 7/8. In Windows XP, the folder is located in the Program Files directory. To run the program, the file hypertrm.exe is used, which is located in the same folder. Another program, Putty, can also be used. In addition to connecting to Cisco equipment, it is used to work with routers, servers, when SSH configuration is needed to connect them.

To complete the connection procedure, the cable must be plugged into the RJ-45 connector, which is labeled “Console” on the front panel. Next, you need to turn on the power supply to the switch and go to HyperTerminal on your computer. In the program, you need to select the connector interface corresponding to COM1 and its speed equal to 9600 B / s. For all subsequent questions, you should choose a negative answer "No". If you select the VLAN setting in the slot interface, you can configure the device's IP address on it.

General principles of configuring Cisco equipment

To ensure a high level of security, Cisco switches support two modes of command entry:

• custom - used to check the state of the equipment;
• privileged - used to change the configuration of the switch (it is analogous to administrator mode for Windows or root for UNIX).

If there is a "#" character in the line before the command, then privileged mode is active. As with UNIX systems, the password will not be displayed on the screen when you enter it. The enable command is used to enter privileged mode, and disable is used to exit.

Initial switch configuration. When, during the first boot, the installation wizard displays a step-by-step configuration message, you need to refuse it: Continue with configuration dialog? : no. This will load the custom mode: Switch>

Switch> enable

To configure settings that are switch-wide, you must enable global configuration mode. To configure individual interfaces use the appropriate interface mode.

Basic Cisco 2960 Settings

Change the name of the switch (originally it is Switch):

Switch # configure terminal

Switch (config) # hostname Switch01 (a new name is set - Switch01)

Switch01 (config) #

If there are many switches, each must have a unique name. In the future, this will help determine that the configuration is being implemented on exactly the device that is needed. It is not recommended to use long names, it is better to choose short ones.

Setting the IP Address for the Management Port of the Switch

Switch01 (config) # interface fa0 / 0 (sets the interface for configuration)

Switch01 (config-if) # no shutdown (interface is enabled)

Switch01 (config-if) # ip address 192.168.0.1 255.255.255.0 (set the IP address and mask)

Switch01 (config-if) # exit (exit from interface configuration mode)

Switch01 (config) #

Setting a privileged mode password

Switch01 (config) # enable secret pass1234 (password pass1234)

Switch01 (config) # exit

Considering that information is transmitted in clear text during telnet connections, you need to use SSH connections, which will provide traffic encryption.

Switch01 # conf t Switch01 (config) # ip domain name geek-nose.com (domain is set, if it is not written any)

Switch01 (config) # crypto key generate rsa (generating RSA key under ssh)

Switch01 (config) # ip ssh version 2 (ssh protocol version)

Switch01 (config) # ip ssh autentification-retries 3 (number of ssh connection attempts)

Switch01 (config) # service password-encryption (save passwords in encrypted form)

Switch01 (config) # line vty 0 2 (transition to the mode of conf-and terminal lines)

Switch01 (config-line) # transport input ssh (ssh connection only)

Switch01 (config-line) # exec timeout 20 0 (activate automatic disconnection of ssh session after 20 minutes)

Switch01 (config-line) # end (Exit configuration mode)

Switch01 # copy running-config startup-config

This was a basic SSH setup. More advanced looks like:

Switch01 # conf t Switch01 (config) # aaa new-model (AAA protocol is enabled)

Switch01 (config) # username root privilege 15 secret pass1234 (creates a root user with a maximum privilege level of 15 and a password of pass1234)

Switch01 (config) # access-list 01 permit 192.168.0 0.0.0.255 (an access rule with the name 01 via ssh is set for all hosts on the 192.168.0.0/24 network; a specific IP address can be set)

Switch01 (config) # line vty 0 2 (peekhod to the mode of conf-and terminal lines) Switch01 (config-line) # privilege level 15 (permission to enter the privileged mode)

Switch01 (config-line) # access-class 23 in (binding the created ssh access rule to the terminal line)

Switch01 (config-line) # logging synchronous

Switch01 (config-line) # end (exit configuration mode)

Switch01 # copy running-config startup-config (save settings).

This completes the basic configuration of the Cisco 2960 switch. If necessary, you can always reset to factory settings and perform the settings "from scratch".

Install SSH

For network equipment, this step is not necessary - SSH support is almost always integrated even into the most minimalistic version of the OS. The only exception is the fairly old Cisco IOS version of W / O CRYPTO.

This version of IOS - with the deliberate removal of all even insignificant traces of what relates to cryptography (up to the absence of (config) #enable secret) was needed for export to countries with strict legislation in terms of importing cryptography. Incidentally, this is not only obvious Cuba + North Korea + Syria + Iran, but also, for example, Australia.

If you have a similar IOS - it can be, for example, on the Catalyst 2950, ​​which, although ancient, but may well come across in production - update it. Without updating, the features needed for SSH, in particular:

• Secure Shell SSH Version 1 Integrated Client;
• Secure Shell SSH Version 1 Server Support;
• Secure Shell SSH Version 2 Server Support;

will be physically absent from IOS.

Adding SSH Support to Windows Server

Starting with Windows Server 2016 build 1709, SSH support has been added to the Windows platform.

It's easy to turn it on.

The first step is to find out what version of the OpenSSH client and server is in the repositories available for installation right now. This is necessary so that when the versions go up (at the time of writing, version one, 1.0), then we would not get problems like “something the script that puts a specific version does not work”. Let's do it with the following cmdlet:

Get-WindowsCapability -Online | ? Name -like "OpenSSH *"

I have Windows Server 2019, so the output looks like this:

We see that the SSH client is already installed initially, but the SSH server is not. Windows Server 2016 will have a slightly different output, nothing was installed there initially. OK, let's install an SSH server:

Add-WindowsCapability -Online -Name OpenSSH.Server ~~~~ 0.0.1.0

The client, as is clear, if absent, is placed in the same way. Tild - four pieces, don't make a mistake.

If you get error 0x800f0950, don't despair - it's just that Feature-On-Demand can't find the repository. Try it through good old DISM:

dism / Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0 / LimitAccess / Online

Let's check that everything is installed:

Get-Service sshd

well, or just ask again Get-WindowsCapability -Online | ? Name -like "OpenSSH *":

If everything is OK, then the sshd service has appeared - however, stopped. Do not turn it on right away - first you need to make the minimum settings, which will be described in the corresponding section of the article.

Fixing the SSHv2 version

The starting zoo of SSH versions is SSH 1.3, then SSH 1.5, then “a special version from Cisco, showing that the server can do both 2.0 and previous”, which 1.99 is now completely irrelevant, since all software is able to SSHv2. Finding software that only supports SSH 1.x is a real challenge. Therefore, of course, make sure that you do not have such software, and update if necessary - but we will consider the functionality and security of only the second version of SSH.

Enabling SSH 2.x in Cisco IOS

It is fixed simply - for Cisco IOS it will be the command:

atraining (config) #ip ssh version 2

If at the moment you have not yet created a single key pair suitable for SSHv2, then you will receive something like this message:

Please create RSA keys to enable SSH (and of atleast 768 bits for SSH v2).

This is not a big deal, unless we note that SSHv2 has “lower” requirements for the length of a key in a key pair. However, we will not try to create keys that do not fall under this limitation - the days when, for example, 512-bit RSA keys were actively used, are gone.

If the keys have not been created yet, then this is done simply:

atraining (config) #crypto key generate rsa modulus 2048 label SSH_KEYS

The parameters are simple - rsa will set the algorithm (the ec variant is added in new IOS), modulus - the bit length (you can set it to 4096, it will certainly be safer), label - to create a "named for a specific purpose" key pair.

In some Cisco IOS versions, there is a limit on stored key pairs - up to 10 per device and up to 2 per user - so a warning like “attention, new key pair will overwrite the previous one” may be displayed. Track it down.

Now let's tell SSH to use exactly this pair:

atraining (config) #ip ssh rsa keypair-name SSH_KEYS

If everything is OK, we will get something like this:

% SSH-5-DISABLED: SSH 2.0 has been disabled
% SSH-5-ENABLED: SSH 2.0 has been enabled

This will indicate that the switch from "whatever keys" to "explicitly specified pair" was successful.

If we also need to inform that this device should only be connected using SSH, and not telnet, for example, then this is done as follows - first we go into the VTY configuration mode:

atraining (config) #line vty 0 5 (or line vty 0 15 - depending on the model)

and explicitly indicate that incoming connections must be exclusively via SSH:

atraining (config-line) #transport input ssh

Enabling SSH 2.x in Cisco NX-OS

It will be easy with Cisco Nexus - they only support SSH 2.x, so there is no need for additional steps to restrict connectivity to older versions of SSH.

Do not forget to explicitly enable the use of SSH:

If there are no keys, then you can explicitly create them, immediately of the desired length and with the desired algorithm. To do this, turn off SSH, generate keys and turn on SSH - then it will immediately "pick up" new ones:

atraining-nx (config) #no feature ssh

atraining-nx (config) #ssh key rsa 2048

atraining-nx (config) #feature ssh

The parameters for ssh key are trivial, except I will note that the old keys will not be automatically overwritten, if necessary, to overwrite them - add at the end of the command force

Enabling SSH 2.x in sshd

In the sshd settings, we will need to add (or replace) the line:

Enabling SSH 2.x on Windows Server

In the% WINDIR% \ System32 \ OpenSSH \ directory there will be a standard OpenSSH configuration file, sshd_config_default - and in theory there might be a setting about “only the second version”, but in fact only SSHv2 is always used. Therefore, there is no specific step to enable SSHv2 on Windows Server.

Now let's limit the list of protocols that can be used to authenticate when connecting a client.

Limiting the list of server authentication protocols

SSH supports several options for verifying the identity of the node to which the connection is made - using the DSA, ECDSA, RSA algorithms and the popular 25519 elliptic curve.

We don't like DSA right away, because he knows only keys of 1024 bits and there is an opinion expressed by Comrade Snowden that the NSA is not just so actively fond of DSA.

Therefore, we will immediately cut off the use case for DSA.

We fix the use of RSA for host identification in Cisco IOS

For Cisco, it will be simple:

atraining (config) #ip ssh server algorithm hostkey ssh-rsa

Fixing host identification algorithms for sshd

In the sshd settings, we will need to go to the / etc / sysconfig / sshd folder and correct the AUTOCREATE_SERVER_KEYS line there:

AUTOCREATE_SERVER_KEYS = "RSA ED25519"

As is clear, this is the setting “in the variants of which algorithms the host keys should be autogenerated”. Note that if the task is high reliability, then 4096-bit RSA is the right choice, and if the speed is, then EC 25519 will be preferable.

After that, go to the sshd settings directory - in our version it will be / etc / ssh - and delete the files of unused algorithms with host keys there. That is, from a list like:

• ssh_host_dsa_key
• ssh_host_dsa_key.pub
• ssh_host_ecdsa_key
• ssh_host_ecdsa_key.pub
• ssh_host_rsa_key
• ssh_host_rsa_key.pub
• ssh_host_ed25519_key
• ssh_host_ed25519_key.pub

we will leave only the necessary ones.

If you are afraid to delete unnecessary - do not be afraid, when starting the sshd service will read the configuration file and create the missing ones, if necessary.

After that, in the configuration file, you need to find directives for using these files with keys - they (directives) usually look like this:

• HostKey / etc / ssh / ssh_host_rsa_key
• HostKey / etc / ssh / ssh_host_dsa_key
• HostKey / etc / ssh / ssh_host_ecdsa_key
• HostKey / etc / ssh / ssh_host_ed25519_key

and leave only the ones you need, commenting out the rest by adding the # (hash) character in front of the lines.

If the directive about using the file is absent or the file is unavailable, then the corresponding algorithm will not be able to be used to verify the identity of the node, which can lead to connection problems.

For example, if you leave only the fancy Ed25519 and turn off RSA, then the widely used PuTTY might say something like this:

This, by the way, is treated by updating PuTTY to the latest version, which has support for new algorithms. So do it ahead of time.

Leaving only the required key types - usually ED25519 and RSA - you need to recreate them manually, i.e. to outsource “let the server do it on the next service restart” is not a good idea.

This is done like this:

For Ed25519: ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ""

For RSA: ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N ""

By doing this step manually, you can be sure that the RSA key will be the correct length and not the default length.

Limiting Protocols for SSH Authentication in Windows Server

The scheme is the same - go to the sshd_config_default file and leave only there:

• HostKey ssh_host_rsa_key
• HostKey ssh_host_ed25519_key

If you need both Ed25519 and RSA, or in general only Ed25519. After - we generate keys:

For Ed25519:. \ Ssh-keygen -t ed25519 -f ssh_host_ed25519_key

For RSA:. \ Ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key

. \ ssh-add ssh_host_ed25519_key

In principle, everything, the sshd service can be started.

Branded crutch from Microsoft

The fruit of the dark mind of Microsoft developers is a crutch for registering the rights to files with keys. It is recommended to run it, but if you are mentally healthy and guess that the service should have rights to the key files that it uses, you can do without it. However, if anything, it is put like this:

Install-Module -Force OpenSSHUtils

Repair-SshdHostKeyPermission -FilePath

It will require NuGet and in general ... see for yourself:

Estimate the level of the target audience, which for these actions needs to download the module package and run the cmdlet - i.e. not turn on the brain and distribute the rights, but you can memorize the command yourself. I am sure that Microsoft will issue a couple of MVPs for this module.

Now about the exchange of key information.

Setting up key exchange / key material creation

There are many variants of DH, or the Diffie-Hellman-Merkle algorithm. Without delving into the materiel of the algorithm itself in this article, let's see how we can strengthen the front from this side.

Key exchange and co-generation of key material for a particular session is a very serious security topic. Our task is to avoid the option when we will have a scenario “authentication is strong, but key exchange is not”.

Let's see how we now have DH configured in SSH on Cisco IOS:

atraining # sh ip ssh | inc Diffie

Minimum expected Diffie Hellman key size: 1024 bits

Badly. It must be at least 2048 bits. We set this with the command:

atraining (config) #ip ssh dh min size 2048

Therefore, make your own choice - SHA-512, with its support on all used equipment, will be the best choice.

But there is one subtlety - the mode of using hash and encryption.

By default, SSH uses a variant called Encrypt-and-MAC - the MAC that was read as unencrypted is appended to the encrypted data. In this case, to check the MAC, you must first decrypt the received block of information to get the plaintext, and then calculate and compare the hashes. This option makes it possible to attack encryption algorithms and obtain "intermediate" data in the event of a compromise of the target system.

The best option from a security point of view is Encrypt-Then-MAC. Why? In the case when the "hash from already encrypted" scheme is used, the first step is to check the integrity, and if something is wrong, the data is immediately discarded; no trial decryption occurs. Such MAC variants will have the -etm suffix. With these points in mind, our configuration will look like this:

MACs [email protected],[email protected]

In Cisco IOS, the MAC type will be set like this:

atraining (config) #ip ssh server algorithm mac hmac-sha1

Cisco IOS has a limited choice - hmac-sha1 and hmac-sha1-96. The second option with cutting the SHA-1 output from 160 bits to 96 (as in ipsec) will not work for us, because it is considered at the same speed (you still need to count the usual SHA-1), and saving traffic - well, ahem , none at all.

MAC for fingerprint key counting

In OpenSSH, we can also specify an algorithm for calculating the "fingerprint" - the fingerprint of the key. The default is MD5 - however, it would be better to explicitly indicate that SHA-2/256 is better for displaying and comparing key hashes:

FingerprintHash sha256

Now let's move on from the cryptographic part to the network part.

SSHv2 network settings

There will be a lot of network settings, but most of them are trivial - “what to use” and “how to filter traffic”, so there is no point in creating a section for each one.

The block will look something like this:

Port 22
AddressFamily inet
IgnoreRhosts yes
UseDNS no
ListenAddress x.x.x.x
TCPKeepAlive yes
#VerifyHostKeyDNS no
#UseRoaming no

Some of the settings are clear - for example, Port 22 binds the SSH service to the specified port number, which can be changed if necessary - at least so that bots-password-bots do not knock, and ListenAddress clearly indicates on which L3 addresses to accept connection requests (the restriction is actual in the case of several addresses and / or network interfaces, or in the scenario "the host may have new network interfaces on the fly, and this does not mean that you have to wait for SSH connections on them"). Other settings are less obvious.

AddressFamily inet says that we will only wait for IPv4 connections. If you use IPv6 and you can connect to the SSH server over it, add AddressFamily inet, inet6.

TCPKeepAlive yes will be needed to detect disconnected users at the network level and terminate their sessions. Disabling this mechanism, which is sometimes recommended “to save traffic” (tears, not savings), will lead to a situation where ssh will not be able in some cases to understand that the user is not just inactive, but will never be able to continue working in this session. Therefore, we include.

IgnoreRhosts yes disables the ancient mechanism for creating a list of hosts (usually in the .rhosts file) from which unauthenticated logins are possible.

UseDNS no will be needed to disable the checking of the PTR record for the connecting subscriber - in addition to being in the internal network, and when connecting from external networks, the presence of PTR is also completely optional, this measure only slows down the connection, and does not raise the security level - the maximum is that does - writes a warning to the log about “the connecting user did not say his real FQDN name”. Although it is possible that this check is enabled, and the DNS on the host does not work (for example, it indicates the wrong IP address of the DNS server), in this case, it is possible that it will not be possible to connect to the host. But this is not a "protective measure" at all, but rather another reason to disable this check, since because of it, it turns out, the number of involved subsystems increases, and therefore the overall reliability of the system decreases.

Is used, then you do not need to disable it. This is, by its logic, a client setting, but for some reason, sometimes there are thoughts “enable it on the server”. I added it to this list and commented it out to emphasize this point - you do not need to specify this option in the server settings.

UseRoaming no turns off support for roaming - an experimental extension to OpenSSH, which was supposed to handle scenarios like “started admin from one place, then moved to another and continued from there”. In fact, this functionality turned out to be of no use to anyone and did not add any breakthrough innovations, but it brought security problems - up to vulnerabilities with PoC. Therefore, we explicitly disable it. Like the previous parameter, it is client-side, i.e. is given here because, again, in a number of guides it is written “turn off everywhere, both on the client and on the server”. This is not the case, only on the client.

SSH restrictions on session connection procedure

The process of connecting to the session also needs to be worked out, since that the use of "unusual" methods of connection, that providing the connecting client with unnecessary information, that spending the server's resources on maintaining a set of "parallel" requests is unnecessary.

The block of our settings for all this will look like this:

RhostsRSAAuthentication no
PubkeyAuthentication no
HostbaseAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
PasswordAuthentication yes

LoginGraceTime 15

ClientAliveInterval 1800
ClientAliveCountMax 0

MaxAuthTries 3
MaxSessions 1
PermitTunnel no

MaxStartups 10:50:20
ShowPatchLevel no

Let's figure out what and how.

The block from RhostsRSAAuthentication no, PubkeyAuthentication no, HostbaseAuthentication no, ChallengeResponseAuthentication no, KerberosAuthentication no disables unused authentication methods. Of course, if you use, say, Kerberos to log into the SSH server, then you do not need to disable Kerberos. But in a typical scenario, when the login is carried out in more common ways, the excess must be explicitly disabled.

The LoginGraceTime parameter tells how much time the user can spend on the login procedure. The default is 2 minutes. This is a lot. A very slow user must be so that it takes him so long to log in. Therefore, this parameter is set to 15 - you can enter in 15 seconds. If you need longer, you can increase it, but reasonably. More importantly, the server will quickly "reset" sessions that have started but have not yet completed authentication, and save resources.

The Cisco IOS counterpart to LoginGraceTime is the atraining (config) #ip ssh time-out command, which sets the maximum time for the login procedure. The default is also 2 minutes, which is also a bit too much and should be reduced. In the case of Cisco NX-OS, this would be atraining-nx (config) #ssh login-gracetime.

A couple of settings ClientAliveCountMax and ClientAliveInterval will be needed to determine when to disconnect an inactive client. ClientAliveInterval is the inactivity time in seconds after which the client will be disconnected, and ClientAliveCountMax is the number of attempts to “wake up” the client. In our case, the client will be disconnected after half an hour of inactivity.

The MaxAuthTries parameter tells after how many attempts of unsuccessful authentication (for example, entering an incorrect password) the session will be disconnected by the server. The default is 6, which is a bit too much. Three times is enough.

The analogue of MaxAuthTries in Cisco IOS is the atraining (config) #ip ssh authentication-retries command, with a default of 3 attempts.

The MaxSessions parameter shows how many sessions inside one SSH connection can be initialized. This is not a limitation on “concurrent sessions from the same host”! This is exactly “put the SSH pipe to the server and inside it you multiplex many sessions with data forwarding”. If you don't need such a scenario - when you connect to the X server and forward traffic deep into the network through it, then only a few will be enough - and you just need to connect to a specific server and administer it, then MaxSessions 1, yes. The PermitTunnel no parameter will complete the configuration of the “ssh only for administration of the server to which we are connecting” mode.

MaxStartups 10:50:20 is a WRED-like mechanism, the family of which is discussed on and the logic of its configuration will be as follows - the first and last values ​​are the starting number of connections (we are only talking about connections that have not passed authentication), starting from which the mechanism the maximum number of connections possible in general will start working (in our case, the mechanism will turn on when there are 10 connections to the server, and 21e connection is technically impossible), and the average parameter is the probability in percent. We have it 50, i.e. we will refuse in half of the cases when the number of sessions "hanging in the authentication phase" will be from 10 to 20.

You can make it easier - for example, MaxStartups 10, i.e. set MaxStartups with one parameter. This will simply indicate the maximum number of concurrently authenticated sessions.

The Cisco IOS counterpart to MaxStartups N with one parameter is the atraining (config) #ip ssh maxstartups N command, where N is the same maximum number of concurrently authenticated sessions.

Using the ShowPatchLevel no command, we turn off the publication of detailed information about the SSH version to the connecting client.

Now let's move on to the block of settings related to accounts.

Groups and users in SSH server setup

It is quite obvious that we need to somehow explicitly indicate who can connect to us and what requirements for this someone will be put forward.

AllowUsers admin admin2
AllowGroups nixadmins
DenyUsers nginx
DenyGroups nginx
PermitEmptyPasswords no
PermitRootLogin no
UsePrivilegeSeparation sandbox

There is also nothing particularly surprising here, all the parameters are named very accurately - except that I will dwell on the explicit prohibition of logging in via ssh for service accounts and groups (in my example, nginx). Do not be lazy to write it down explicitly, such accounts change extremely rarely, and a safety net will not hurt. Yes, and do not work under the root, no matter how trivial it may sound.

In the variant with Cisco IOS, it makes no sense to make such settings locally on the device, since it would be more logical to use AAA and redirect requests for authentication and authorization via RADIUS / TACACS to some centralized server, or (in new IOS) go directly to the LDAP storage with requests “is there such a user”. It is inconvenient and unsafe to create local bases on every device. This whole mechanism is not tied to SSH, but is a more general way of redirecting requests for authentication / authorization, so it is not described here so that the article remains about SSH, and not "about everything that may be related to SSH."

However, in terms of passwords, setting it up does not hurt - the command

atraining (config) #security password min-length N

will set the minimum length of passwords on this device.

The UsePrivilegeSeparation sandbox setting will explicitly tell ssh that for each incoming connection a separate sshd process with minimal privileges will be created - and after successful authorization a new one will be created, which will process the session of a specific connected user. This reduces losses in the event of a new vulnerability in the sshd connection mechanism - the one who will exploit this vulnerability, even if the ssh process is hijacked, will receive a minimum of rights in the system.

Short summary

Hope you find this little checklist helpful. SSH is widely used, so predictable and secure access through it is the foundation for a reliable network infrastructure.

Date of last text editing: