Ssh Server For Mac
Back in 2011, I wrote a post on how to enable SSH on Cisco routers and switches. Unfortunately, it didn’t contain any of the advanced configurations that will harden Cisco IOS SSH server. To be fair, there were older IOS software versions that didn’t include advanced SSH commands that I will cover here. With this post, I’d like to share at least the minimum advanced SSH configuration that network engineers should consider adding to their template.
Ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to provide secure encrypted communications between two untrusted hosts over an insecure network. X11 connections, arbitrary TCP ports and UNIX-domain. The command 'sshd -T grep macs' shows the supported MAC algorithms, and all of the above are included (plus a bunch of the MD5 and 96bit algorithms). If I add a 'macs' line to '/etc/ssh/sshdconfig' to include just the secure algorithms above (by default there is no 'macs' line added to sshdconfig), the clients can't connect to the ssh server; I never get a login prompt; it just immediately drops the.
SSH Encryption Algorithms
If you’re a macOS 10.13.2 user and you use it to connect to Cisco routers and switches, you may have seen this error message already.
The issue here is that OpenSSH has deprecated the weaker ciphers in the default SSH configuration of the newest version of macOS. Unfortunately, older Cisco IOS software uses AES 3DES-CBC for the SSH server, by default. Below is an example of a Cisco router running an older version of IOS which uses default SSH configuration.
There are two options to get rid of the error message. One of the options is by configuring the client side to accept the legacy ciphers. The right course of action, in my opinion, is to change SSH server configurations. However, we still need to be able to connect to our Cisco IOS devices to correct the issue.
SSH client options
A quick fix here is to keep using compatible ciphers that the client would accept. There are three options that one could use for this workaround. Technically, they are all doing the same thing but just different approach.
Option #1
With this option, the user just needs to specify the cipher and KEX algorithms in the SSH command when connecting to an SSH server. One could create an alias to include all the necessary command flags for shorter keystrokes.
Option #2
With this option, the user does not need to create an alias or type the whole command shown above. The .ssh/config file is a user-specific configuration file. OpenSSH receives its configuration from this file when the command issued doesn’t include command flags.
Option #3
With this option, all users are affected by this configuration file. However, the command issued and user-specific configuration file take precedence over the global configuration file.
Ssh Server For Macos
SSH server options
As mentioned earlier, the server side option is the correct course of action. However, one still needs to connect the Cisco IOS devices to fix the issue. That said, the SSH client workaround still plays an important role.
SSH encryption algorithm
The command shown below is used to change SSH encryption key algorithm used on a Cisco IOS device. If one gets an error message, then the command is not available in that IOS version.
In this particular IOS version, the SSH server supports the encryption algorithms: AES-CTR, AES-CBC, and 3DES. According to this thread, use EAX or GCM, if available. If not, the author said to use CTR over CBC mode. By specifying the encryption algorithm, we’re telling Cisco IOS to only offer the AES-256-CTR mode to any clients that try to connect to it.
Below shows the verbose output of a Cisco IOS device using default SSH configuration.
Below shows the verbose output of a Cisco IOS device using the SSH configuration mentioned above.
SSH MAC algorithm
To change the default SSH MAC algorithm used on a Cisco IOS device, use the command below.
UPDATE: Newer IOS supports higher than SHA1.
In this particular IOS version, the SSH server supports two Message Authentication Code (MAC) algorithms: HMAC-SHA1 and HMAC-SHA1-96. The difference between the two algorithms is the digest length. The HMAC-SHA1-96 is a truncated message digest. From my limited understanding, the HMAC-SHA1-96 is the weakened version of HMAC-SHA1 due to the shortened message digest.
Below shows the verbose output of a Cisco IOS device using default SSH configuration.
Below shows the verbose output of a Cisco IOS device using the SSH configuration mentioned above.
UPDATE: Configured with SHA2
Key Exchange Algorithm
If my memory serves me right, even before macOS High Sierra, OpenSSH also deprecated the use of Diffie-Hellman key exchange with SHA-1. That said, users that tried to connect to Cisco IOS devices with default SSH configurations were greeted by an error message, like the one below.
The real issue is that most of the Cisco IOS versions use 1024-bit key size for Diffie-Hellman used for key exchange, by default. Though, there are old Cisco IOS versions that use 768-bit DH key size, by default. Prior the year of 2016, 1024-bit key size is adequate. However, NIST’s recommendation is to use 2048-bit key size or higher. Furthermore, the authors of the LogJam paper believes that it may be possible for a nation-state to break 1024-bit groups. Therefore, the authors recommend disabling DH Group 1.
Below shows the verbose output of a Cisco IOS device using the SSH configuration mentioned above.
Note: Changing the DH key size to 4096 value may break some applications that connect to Cisco IOS devices. For example, HPE Opsware Network Automation (now Micro Focus) uses a Java-based SSH client that is incompatible with SSH servers that use higher than 2048-bit DH key.
Additional SSH configuration
The commands covered here deserves consideration since they increase the level of protection to Cisco IOS SSH server.
RSA keys
As covered in this post, I used 4096-bit modulus in the second example. Cisco IOS users should consider generating higher than NIST’s recommendation of the 2048-bit modulus. Generating higher than the recommended value may take a minute or two (depending on the platform). Additionally, it may take few seconds to get the prompt when connecting to a Cisco IOS device. That said, make sure to take the two facts into consideration before using higher than the recommended value. In theory, newer Cisco platforms could handle the higher values without a significant impact on performance.
If you’re confused about the difference between RSA and DH mentioned here, then I recommend you to read this article. The article did a great job explaining the SSH connection process. If you just want to know the difference between the RSA and DH, then skip to the Negotiating Encryption for the Session section.
SSH authentication timeout
There is no reason to have a high authentication timeout, so it is recommended to lower the value to 60 seconds or less. This particular router has the SSH authentication timeout set to 120 seconds. We’ll change it to 30 seconds.
Line VTY
There four Cisco IOS features under VTY configuration that deserves consideration because they provide an increased level of protection to networking devices.
SSH transport protocols
As mentioned in this post, by default, Cisco IOS still allows telnet connection when the user doesn’t disable it. To disable, please issue the command below. If you only need 5 vty lines, I suggest disabling the remaining vty lines.
Ssh Server For Mac
SSH ACL
Creating and applying ACL to SSH is best practice, so I decided to cover it here, even though this is considered very basic security.
Session timeout
I think this is one of the controversial settings that require some discussions with the networking team. The STIG recommends to set it to 10 minutes or less. By default, Cisco IOS uses 10 minutes for this setting. Please feel free to change it to something else that follows your security policy or suggested setting by the networking team.
Final Words
All of the configurations covered here are what I’d say minimum security standard for all Cisco IOS devices. My advice for my fellow network engineers looking to secure network devices against management plane attacks must consider including this in their configuration template. Though, this blog post is just a small part of protecting the management plane. That said, I urge my fellow network engineers to research more about other settings that protect the management plane.
Are you ready to improve your network security?
Let us answer more questions by contacting us. We’re here to listen and provide solutions that are right for you.
NetworkJutsu provides networking and network security consulting services for startups, a more established small and medium-sized business (SMB), or large business throughout the San Francisco Bay Area.
Want to learn more about securing Cisco IOS?
Disclosure
NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.
Sometimes you run into issues ssh-ing into a remote VPS using your keys / public key. Sometimes all you see in the server logs will be something like
Now that is not very useful. So how can you get the user that is having issues ssh-ing into your server to get the necessary debug information? How to debug ssh server access by Mac. Let’s look at both the client and server side shall we?
Adding Keys to Keychain
When you are running the ssh client on a Mac client make also sure to do a:
to add the key to your keychain in MacOS on your Mac box. This is something you do on the user’s box so client side.
Verbose SSH client logging
Nex when you want to try ssh-ing into the remote server run this command:
for ssh with verbose output. This way you will get way more details on the issues you may be having.
Known Hosts
At the first connection choose yes to add the server’s key to you known hosts file at
Otherwise the connection will fail. Sometimes this is forgotten in the heat of the moment. Also if you server settings changed you may have to remove the old known host and re-add it on the next connection.
Server Side SSH Debugging
When necessary you can start server side SSH debugging as well using:
and then you can check any incoming traffic on that port for issues. Do make sure you are ssh-ing into that port then. Otherwise nothing will be recorded. You can do that using:
That way you use the port from the client the server is listening at and you should then be able to get all the debug information you need.
Well, this should help you work things out pretty well. Some users have issues with authorized_keys files on the server. Either permissions on the file or issues with keys stored in them. Debugging as suggested should help you work things out.
NBssh-keygen -t ecdsa -b 521 is better then just ssh-keygen -t rsa, but ssh-keygen -t rsa -b 4096 is way more secure these days