Prevent SSH response on VR-Default

I have an X460-G2 on firmware

I want SSH access to only be available from VR-Mgmt, so I have configured as follows:
enable ssh2 vr VR-Mgmt

If I attempt to SSH to the device using an IP that belongs to VR-Default, while I can’t log in I do get an SSH login prompt. Additionally if I use portqry to probe port 22 the port is returned as ‘listening’. The addresses in question are accessible from the internet so this is not really acceptable from a security standpoint.

I have already disabled SSH and re-enabled specifically specifying VR-Mgmt.

Firstly - how can I prevent all SSH repsonse on VR-Default? Port 22 should not be seen as open.
I do not wish to restrict access to specific IP addresses - it should be allowed from VR-Mgmt and nowhere else.

Secondly - surely this behaviour is a bug and there should be no response on VR-Default? Why would the device respond when SSH is specifically only enabled on VR-Mgmt?

10 replies

Userlevel 5

If you do a “show config”, are there any other lines that might enable ssh?
In my configs (on 16.x), the “enable ssh vr vr-mgmt” is the only “ssh” line in the config

Note: I’m clueless about 30.x ;)

I have the same as you:

# Module exsshd configuration.
enable ssh2 vr VR-Mgmt

All the rest of the SSH config is at default values I believe:

# show config detail exsshd
# Module exsshd configuration.
enable ssh2 port 22 vr VR-Mgmt
configure ssh2 secure-mode off
configure ssh2 dh-group minimum 14
configure ssh2 idletimeout 60
configure ssh2 disable cipher aes128-cbc
configure ssh2 disable cipher 3des-cbc
configure ssh2 disable cipher blowfish-cbc
configure ssh2 disable cipher cast128-cbc
configure ssh2 disable cipher aes192-cbc
configure ssh2 disable cipher aes256-cbc
configure ssh2 disable cipher arcfour
configure ssh2 disable cipher
configure ssh2 enable cipher aes128-ctr
configure ssh2 enable cipher aes192-ctr
configure ssh2 enable cipher aes256-ctr
configure ssh2 disable cipher arcfour256
configure ssh2 disable cipher arcfour128
configure ssh2 enable cipher
configure ssh2 disable mac
configure ssh2 enable mac
configure ssh2 enable mac
configure ssh2 enable mac
configure ssh2 disable mac
configure ssh2 disable mac
configure ssh2 disable mac
configure ssh2 disable mac hmac-md5
configure ssh2 enable mac hmac-sha1
configure ssh2 enable mac hmac-sha2-256
configure ssh2 enable mac hmac-sha2-512
configure ssh2 disable mac hmac-ripemd160
configure ssh2 disable mac
configure ssh2 disable mac hmac-sha1-96
configure ssh2 disable mac hmac-md5-96
configure ssh2 rekey time-interval none
configure ssh2 rekey data-limit default
configure ssh2 enable pk-alg ssh-rsa
configure ssh2 disable pk-alg ssh-dss
configure ssh2 enable pk-alg x509v3-sign-rsa
configure ssh2 enable pk-alg x509v3-sign-dss

Userlevel 5

Sounds like it’s similar to SNMP then - “we listen everywhere, and let the CPU sort things out”. I fear ACLs are in your future, but I hope someone with more experience can weigh in.


Userlevel 6

I was surprised because I with think ssh would be effectively disabled on the default VR. I would think getting a prompt is a bug. Unless Extreme agrees and changes the behavior which I am sure will require a code upgrade I agree an ACL would be the only option. 

So if I need to use an ACL, what is the best approach? It doesn’t seem to be possible to specify a VR as a match condition as far as I can see.

There are only two active VLANs/SVIs in VR-Default, would it be best just to deny SSH for those VLANs?

Can anyone give a sample configuration?

Userlevel 3

Hi Jon,

Below is an article that explains the ACL and how to apply it:



Chris Thompson

Userlevel 6

Next thought is that since you and I both mentioned this looks like a bug, open a TAC case and see if it can be resolved.

Or this is not exactly what you wanted to do but seems like a good work around since it sounded like the internet was your primary concern.

entry AllowTheseSubnets {
if match any {
source-address /24;
source-address /24;
} then {


  1. Write and quit the CLI editor by pressing the escape key and typing ":wq"
  2. Apply the access profile. "configure ssh2 access-profile <POLICY_NAME>"

Thanks for the suggestions - we did not want to go down the route of allowing specific IPs or IP ranges though. As mentioned above, there are only two active VLANs other than the management VLAN, so we have done the following:

create access-list DenySSH " protocol 6 ; destination-port 22 ;" " deny  ;"

configure access-list add DenySSH last vlan VLAN1 ingress
configure access-list add DenySSH last vlan VLAN2 ingress


This seems to have done the job.

I’d be interested to know if there are any potential drawbacks to this approach?


Userlevel 4

The drawback is that when you add the next VLAN in the future and forget to add the policy to that VLAN, you’ll not have the intended protection. In security, always forbid everything and allow only what you explicitly want. I’d rather use an ACL allowing SSH from the management network and then a global ACL to deny it.

Oh, by the way, you just disabled all SSH access THROUGH the switch as well… I guess that’s not what you intended?

I’m pretty sure there’s a better way of doing this but it’s way too late for me to think straight now.


Thanks @FredrikB - all good points. In this case I am working on a WAN edge switch which just has point to point VLANs to our ISP and our firewall’s WAN interface, and the management VLAN, so we will not be adding more VLANs and we don’t allow inbound or outbound SSH traffic.