- Cisco Community
- Technology and Support
- Security
- Security Knowledge Base
- Guide to better SSH-Security
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
10-28-2014 08:08 AM - edited 09-28-2019 04:21 AM
There are countless recommendations for the configuration of SSH on Cisco devices available. But many of them propose settings that are not adequate any more. This document shows how to set up SSH on IOS and ASA for advanced session-security and how to configure an Apple Mac with OS X to only negotiate secure crypto. The client-side part of this document can also be used for checking the settings on a Linux-system.
Cisco IOS
It always starts with the generation of a public/private keypair that will be only used for the SSH-process. In this command we use a dedicated label "SSH-KEY" which we later assign to the SSH-config. The default-keylength ist typically too small, it's time to move to a stronger crypto. For new setups I only use 4096 Bit keys. Thats more then recommended on sites like http://www.keylength.com and makes the session-setup a little slower. But by far not that slow that it's unusable. And it typically doesn't hurt to have better crypto then the others.
crypto key generate rsa label SSH-KEY modulus 4096
The RSA-Keypair is assigned to the SSH-config:
ip ssh rsa keypair-name SSH-KEY
Next we only allow SSH version 2. By default also version 1 is allowed:
ip ssh version 2
When the SSH-session is established, the session-keys are computed with the Diffie-Hellmann key exchange protocol. By default this is done with 768 Bit, which is not state-of-the-art any more. For my setups (with MacOS and Linux clients) I configure a bitlength of 4096 Bit. If you are using Putty in the actual version (0.63 at the time of writing), this is more then Putty can handle. You should change to a more powerful terminal like SecureCRT or use only a size of 2048 Bit which is still very secure. And if your IOS is to old, this command will also not be available.
ip ssh dh min size 4096
Depending on your needs you could enable the logging of SSH-login-events:
ip ssh logging events
The last step is to restrict the vty-lines to only use SSH, so that Telnet is not allowed any more:
line vty 0 4
transport input ssh
In some setups, where SSH has to be reachable over the internet, I also change the SSH-port to something non-standard. This won't really increase the security of the setup, but it gives less log-entries from bots that try to login to SSH with commonly used username/password-combinations.
ip ssh port 7890 rotary 1
!
line vty 0 4
rotary 1
If the IOS-device is running at least 15.5(2), then it's possible to disable unwanted algorithms. In security-audits, all CBC-ciphers are often a problem.
By default there are many algorithms supported:
rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96
With the following config only aes256-ctr with hmac-sha1 is allowed on the router:
ip ssh server algorithm encryption aes256-ctr
ip ssh server algorithm mac hmac-sha1
rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes256-ctr
MAC Algorithms:hmac-sha1
Usernames and Passwords in Cisco IOS
There are different ways in IOS to configure users with corresponding passwords. For SSH, the Router/Switch doesn't need the cleartext password. That means you should not configure your users with
rtr(config)#username USER password PASS
Better configure your users with hashed passwords. If you are running a recent IOS, you can configure the passwords to be hashed with PBKDF2:
rtr(config)#username USER algorithm-type sha256 secret VERYSECUREPASSWORD
If your IOS doesn't support this new username-parameter, you configure them the following way:
rtr(config)#username USER secret VERYSECUREPASSWORD
Some more protection-mechanisms that should be thought about are Control-Plane-Protection and Management-Plane-Protection. But that is not SSH-specific.
Cisco ASA
The setup on the ASA has the same goal as on IOS, but there are less options to secure SSH. The syntax is also a bit different:
crypto key generate rsa modulus 4096
ssh version 2
ssh key-exchange group dh-group14-sha1
The keylength is dependent on the ASA platform in use. The legacy ASAs are not capable of a keylength larger then 2048 Bit. On the actual 5500-X devices, 4096 Bit is also possible.
The command "ssh key-exhange group group14-sha1" was introduced in 8.4(4.1) and 9.1(2).
Starting with 9.6(1) and 9.1(7), it's possible to limit the ciphers that are allowed on the ASA.
These are the defaults:
asa(config)# show ssh | inc Cipher
Cipher encryption algorithms enabled: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
Cipher integrity algorithms enabled: hmac-sha1 hmac-sha1-96
The available options are:
asa(config)# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
Encryption Algorithms:
all: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
low: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
medium: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
fips: aes128-cbc aes256-cbc
high: aes256-cbc aes256-ctr
Integrity Algorithms:
all: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
low: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
medium: hmac-sha1 hmac-sha1-96
fips: hmac-sha1
high: hmac-sha1
With the following config only aes256-ctr with hmac-sha1 is allowed on the ASA:
ssh cipher encryption custom aes256-ctr
ssh cipher integrity custom hmac-sha1
On the ASA, the SSH-access has to be allowed from the management-IPs:
ssh 10.10.0.0 255.255.0.0 inside
ssh 192.0.2.100 255.255.255.255 outside
Cisco Nexus
The Nexus by default uses only 1024 Bit keys, and only supports SSH version 2.
The only available option (to my knowledge and based on the config guide) is to use keys with a maximum length of 2048 Bits for the SSH-server:
ssh key rsa 2048 force
Client-config on MacOS (and Linux)
On a default-install of MacOS and also some Linux-versions, the optimum crypto is not always negotiated. For that, some settings should be adjusted to provide more security.
SSH-parameter can be configured at two places:
- globally at
/etc/ssh_config - per User at
~/.ssh/config
In the systemwide config on MacOS the following three lines are most relevant for the used cryptography of the SSH-sessions (shown are the defaults on OS X Mavericks 10.9):
#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96
There are a couple of changes needed to make SSH-sessions more secure:
Ciphers
If you don't have any legacy devices to manage you can remove everything other then the AES-ciphers. If there are still older devices like Catalyst 2950 to manage, 3des-cbc could be left in the config:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
I prefer to not have any legacy crypto in my cipher-string. If I have to connect to a legacy device, I specify that on the ssh-command which is shown later in this document.
Based on the manpage (and also based on the used OpenSSH-version which is 6.2p2 on both Mavericks and Yosemite), modern cipher-types like AES-GCM should also work. But when trying to configure them I only get the error „Bad SSH2 cipher spec“.
When connecting to Cisco routers and switches, typically the CBC-versions are used, the more modern CTR is only supported with IOS 15.4 which at least I don't use yet.
KexAlgorithms
This option controls the Key-Exchange. A more secure config on Mac OS is the following:
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
I removed the ElipticCurve algorithms as they are suspected to contain backdoors.
The probably trustworthy curve25519 from D.J. Bernstein is only available starting with OpenSSH 6.6p1. Based on the availability, this algorithm should be added.
The last option in this line is again for legacy systems. Again, I don't have these configured, instead I use these options only for the sessions where needed.
MACs
In this default I don't like the MD5 MACs and that the more secure ones don't have the highest priority. So this line should be cleaned up and rearranged:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1
Just notice the etm-MACs in the line. These are not relevant for accessing Cisco Network-devices, but can strengthen the crypto when connecting to other SSH-servers. A little excursion into Message Authentication Codes:
The protocols SSL/TLS, IPsec and SSH by default use different methods to encrypt the data and protect the integrity:
- SSL: mac-then-encrypt. The MAC is build first, then MAC and data are encrypted.
- IPsec: encrypt-then-mac. The data is first encrypted, the MAC is build over the encrypted data.
- SSH: encrypt-and-mac. The data is encrypted, but the MAC is build over the cleartext data.
Cryptographers have shown that the method used by IPsec is the most secure one. This method (encrypt-then-mac) can also be used by SSH when supported on both the client and server.
Update: RFC 7366 defines an extention to TLS that also allows to use "encrypt then mac".
What will change for our SSH-sessions with this new config? Before activating the config-changes, this is an SSH-session (on a Cisco 3560 with IOS 15.0(2)SE5):
c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
1 2.0 IN aes128-cbc hmac-md5 Session started ki
1 2.0 OUT aes128-cbc hmac-md5 Session started ki
The used crypto is aes-128-cbc with an MD5-HMAC. After applying the new client-config, the used crypto is much better (as far as possible with this IOS):
c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes256-cbc hmac-sha1 Session started ki
0 2.0 OUT aes256-cbc hmac-sha1 Session started ki
This is the used ~/.ssh/config that still includes the legacy methods:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1
As mentioned earlier, I also removed the legacy crypto from my ~/.ssh/config:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1
If an ssh-session to a legacy device is still needed, the older crypto has to be specified with the ssh-command. This is an example for a connection to an old Catalyst 2950:
ssh -l ki 10.10.10.200 -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"
Any suggestions or improvements? Please comment!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Informative article on SSH. Thank you for your contribution.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thank you Karsten:) Very usefull for me and my customer...
@Karsten Iwen wrote:
There are countless recommendations for the configuration of SSH on Cisco devices available. But many of them propose settings that are not adequate any more. This document shows how to set up SSH on IOS and ASA for advanced session-security and how to configure an Apple Mac with OS X to only negotiate secure crypto. The client-side part of this document can also be used for checking the settings on a Linux-system.
Cisco IOS
It always starts with the generation of a public/private keypair that will be only used for the SSH-process. In this command we use a dedicated label "SSH-KEY" which we later assign to the SSH-config. The default-keylength ist typically too small, it's time to move to a stronger crypto. For new setups I only use 4096 Bit keys. Thats more then recommended on sites like http://www.keylength.com and makes the session-setup a little slower. But by far not that slow that it's unusable. And it typically doesn't hurt to have better crypto then the others.
crypto key generate rsa label SSH-KEY modulus 4096
The RSA-Keypair is assigned to the SSH-config:
ip ssh rsa keypair-name SSH-KEY
Next we only allow SSH version 2. By default also version 1 is allowed:
ip ssh version 2
When the SSH-session is established, the session-keys are computed with the Diffie-Hellmann key exchange protocol. By default this is done with 768 Bit, which is not state-of-the-art any more. For my setups (with MacOS and Linux clients) I configure a bitlength of 4096 Bit. If you are using Putty in the actual version (0.63 at the time of writing), this is more then Putty can handle. You should change to a more powerful terminal like SecureCRT or use only a size of 2048 Bit which is still very secure. And if your IOS is to old, this command will also not be available.
ip ssh dh min size 4096
Depending on your needs you could enable the logging of SSH-login-events:
ip ssh logging events
The last step is to restrict the vty-lines to only use SSH, so that Telnet is not allowed any more:
line vty 0 4
transport input ssh
In some setups, where SSH has to be reachable over the internet, I also change the SSH-port to something non-standard. This won't really increase the security of the setup, but it gives less log-entries from bots that try to login to SSH with commonly used username/password-combinations.
ip ssh port 7890 rotary 1
!
line vty 0 4
rotary 1
If the IOS-device is running at least 15.5(2), then it's possible to disable unwanted algorithms. In security-audits, all CBC-ciphers are often a problem.
By default there are many algorithms supported:
rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
MAC Algorithms:hmac-sha1,hmac-sha1-96
With the following config only aes256-ctr with hmac-sha1 is allowed on the router:
ip ssh server algorithm encryption aes256-ctr
ip ssh server algorithm mac hmac-sha1
rtr#show ip ssh | inc Encryption|MAC
Encryption Algorithms:aes256-ctr
MAC Algorithms:hmac-sha1
Usernames and Passwords in Cisco IOS
There are different ways in IOS to configure users with corresponding passwords. For SSH, the Router/Switch doesn't need the cleartext password. That means you should not configure your users with
rtr(config)#username USER password PASS
Better configure your users with hashed passwords. If you are running a recent IOS, you can configure the passwords to be hashed with PBKDF2:
rtr(config)#username USER algorithm-type sha256 secret VERYSECUREPASSWORD
If your IOS doesn't support this new username-parameter, you configure them the following way:
rtr(config)#username USER secret VERYSECUREPASSWORD
Some more protection-mechanisms that should be thought about are Control-Plane-Protection and Management-Plane-Protection. But that is not SSH-specific.
Cisco ASA
The setup on the ASA has the same goal as on IOS, but there are less options to secure SSH. The syntax is also a bit different:
crypto key generate rsa modulus 4096
ssh version 2
ssh key-exchange group dh-group14-sha1
The keylength is dependent on the ASA platform in use. The legacy ASAs are not capable of a keylength larger then 2048 Bit. On the actual 5500-X devices, 4096 Bit is also possible.
The command "ssh key-exhange group group14-sha1" was introduced in 8.4(4.1) and 9.1(2).
Starting with 9.6(1) and 9.1(7), it's possible to limit the ciphers that are allowed on the ASA.
These are the defaults:
asa(config)# show ssh | inc Cipher
Cipher encryption algorithms enabled: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
Cipher integrity algorithms enabled: hmac-sha1 hmac-sha1-96
The available options are:
asa(config)# show ssh ciphers
Available SSH Encryption and Integrity Algorithms
Encryption Algorithms:
all: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
low: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
medium: 3des-cbc aes128-cbc aes192-cbc aes256-cbc aes128-ctr aes192-ctr aes256-ctr
fips: aes128-cbc aes256-cbc
high: aes256-cbc aes256-ctr
Integrity Algorithms:
all: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
low: hmac-sha1 hmac-sha1-96 hmac-md5 hmac-md5-96
medium: hmac-sha1 hmac-sha1-96
fips: hmac-sha1
high: hmac-sha1
With the following config only aes256-ctr with hmac-sha1 is allowed on the ASA:
ssh cipher encryption custom aes256-ctr
ssh cipher integrity custom hmac-sha1
On the ASA, the SSH-access has to be allowed from the management-IPs:
ssh 10.10.0.0 255.255.0.0 inside
ssh 192.0.2.100 255.255.255.255 outside
Cisco Nexus
The Nexus by default uses only 1024 Bit keys, and only supports SSH version 2.
The only available option (to my knowledge and based on the config guide) is to use keys with a maximum length of 2048 Bits for the SSH-server:
ssh key rsa 2048 force
Client-config on MacOS (and Linux)
On a default-install of MacOS and also some Linux-versions, the optimum crypto is not always negotiated. For that, some settings should be adjusted to provide more security.
SSH-parameter can be configured at two places:
- globally at
/etc/ssh_config- per User at
~/.ssh/config
In the systemwide config on MacOS the following three lines are most relevant for the used cryptography of the SSH-sessions (shown are the defaults on OS X Mavericks 10.9):
#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96
There are a couple of changes needed to make SSH-sessions more secure:
Ciphers
If you don't have any legacy devices to manage you can remove everything other then the AES-ciphers. If there are still older devices like Catalyst 2950 to manage, 3des-cbc could be left in the config:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
I prefer to not have any legacy crypto in my cipher-string. If I have to connect to a legacy device, I specify that on the ssh-command which is shown later in this document.
Based on the manpage (and also based on the used OpenSSH-version which is 6.2p2 on both Mavericks and Yosemite), modern cipher-types like AES-GCM should also work. But when trying to configure them I only get the error „Bad SSH2 cipher spec“.
When connecting to Cisco routers and switches, typically the CBC-versions are used, the more modern CTR is only supported with IOS 15.4 which at least I don't use yet.
KexAlgorithms
This option controls the Key-Exchange. A more secure config on Mac OS is the following:
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
I removed the ElipticCurve algorithms as they are suspected to contain backdoors.
The probably trustworthy curve25519 from D.J. Bernstein is only available starting with OpenSSH 6.6p1. Based on the availability, this algorithm should be added.
The last option in this line is again for legacy systems. Again, I don't have these configured, instead I use these options only for the sessions where needed.
MACs
In this default I don't like the MD5 MACs and that the more secure ones don't have the highest priority. So this line should be cleaned up and rearranged:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1
Just notice the etm-MACs in the line. These are not relevant for accessing Cisco Network-devices, but can strengthen the crypto when connecting to other SSH-servers. A little excursion into Message Authentication Codes:
The protocols SSL/TLS, IPsec and SSH by default use different methods to encrypt the data and protect the integrity:
- SSL: mac-then-encrypt. The MAC is build first, then MAC and data are encrypted.
- IPsec: encrypt-then-mac. The data is first encrypted, the MAC is build over the encrypted data.
- SSH: encyrpt-and-mac. The data is encrypted, but the MAC is build over the cleartext data.
Cryptographers have shown that the method used by IPsec is the most secure one. This method (encrypt-then-mac) can also be used by SSH when supported on both the client and server.
Update: RFC 7366 defines an extention to TLS that also allows to use "encrypt then mac".
What will change for our SSH-sessions with this new config? Before activating the config-changes, this is an SSH-session (on a Cisco 3560 with IOS 15.0(2)SE5):
c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
1 2.0 IN aes128-cbc hmac-md5 Session started ki
1 2.0 OUT aes128-cbc hmac-md5 Session started ki
The used crypto is aes-128-cbc with an MD5-HMAC. After applying the new client-config, the used crypto is much better (as far as possible with this IOS):
c3560#sh ssh
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes256-cbc hmac-sha1 Session started ki
0 2.0 OUT aes256-cbc hmac-sha1 Session started ki
This is the used
~/.ssh/configthat still includes the legacy methods:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1
As mentioned earlier, I also removed the legacy crypto from my
~/.ssh/config:
Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1
If an ssh-session to a legacy device is still needed, the older crypto has to be specified with the ssh-command. This is an example for a connection to an old Catalyst 2950:
ssh -l ki 10.10.10.200 -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"
Any suggestions or improvements? Please comment!
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thanks for the explanation but I get a question. Looks like this encryption algorithm is vulnerable too.
aes256-ctr
[low] [22/tcp/ssh] SSH Server CBC Mode Ciphers Enabled
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Is there a way to disable week ciphers and CBC mod. We got vulnerability in audit point.
MODEL : Cisco WS-C3750V2-24TS
VERSION : 15.0(2)SE11
Need to Disable MD5 and 96-bit MAC algorithms and Enable CTR or GCM cipher mode
Current config as below.
HOST_NAME# show ssh
*Mar 1 05:35:37 IST: %SYS-5-CONFIG_I: Configured from console by xyz_usrnm on console
Connection Version Mode Encryption Hmac State Username
0 2.0 IN aes256-cbc hmac-sha1 Session started xyz_usrnm
0 2.0 OUT aes256-cbc hmac-sha1 Session started xyz_usrnm
%No SSHv1 server connections running.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Very useful up until now.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thanks a lot, it helped me to get into my AP1242
- « Previous
-
- 1
- 2
- Next »
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: