Blocking SSH on a Cisco Router: ACLs, VTY Lines, and the Lockout Trap

To control SSH to a Cisco router, apply an access class to the VTY lines rather than filtering the interface. An interface ACL filters traffic passing through the router; a VTY access class filters traffic terminating on it, which is what a management session is.

This distinction is the whole answer, and getting it wrong is why forum threads exist where someone applied a deny rule to an interface and management access is still working. The two mechanisms operate on different traffic.

Table of contents

• Why the interface ACL does not do what you expect
• Restricting SSH to specific sources
• Disabling SSH entirely
• Not locking yourself out
• The rest of the hardening
• How this fits the rest of the stack
• FAQ

Why the interface ACL does not do what you expect

An ACL applied inbound on an interface filters traffic arriving on that interface, including traffic destined for the router itself. So it can work - but it is the wrong tool for three reasons.

First, it is per-interface. A router with several interfaces needs the ACL applied to each one, and the one you forget is the one that stays open.

Second, it mixes concerns. That ACL is probably also doing transit filtering. Combining management access control with data plane policy in one list makes both harder to reason about and easier to break during an unrelated change.

Third, it filters by destination address. Management traffic can arrive addressed to any interface IP on the box, so a correct rule has to enumerate all of them, and it breaks when someone adds an address.

The VTY access class avoids all three. It applies to the virtual terminal lines themselves, which is where every inbound management session terminates regardless of which interface or address it came in on.

Restricting SSH to specific sources

The usual requirement is not blocking SSH entirely but allowing it only from a management network.

! Define who is allowed
ip access-list standard MGMT-ACCESS
 permit 10.0.100.0 0.0.0.255
 permit host 192.168.50.14
 deny   any log

! Apply it to the VTY lines
line vty 0 15
 access-class MGMT-ACCESS in
 transport input ssh
 exec-timeout 10 0
 login local
!

Four things are happening. The access class restricts which source addresses may open a session. The transport input line permits SSH only, disabling Telnet - if that is the only change you make today, it is still the most valuable one. The exec timeout closes idle sessions. And local login means credentials are checked rather than a shared line password.

Note the wildcard mask. Cisco standard ACLs use wildcard masks, not subnet masks, so a 24-bit network is expressed as the inverse. Writing a subnet mask here silently produces a rule matching the wrong range.

The range in the VTY line matters too. Different platforms and configurations support different numbers of VTY lines, and applying the access class to only the first few leaves the rest unprotected. Check what exists before assuming a range.

show running-config | section line vty

Disabling SSH entirely

If the requirement is genuinely no SSH at all, there are two levels.

! Refuse all inbound sessions on the VTY lines
line vty 0 15
 transport input none
!

That is the clean way. It refuses every inbound session type on those lines, leaving console access as the only management path.

! Remove the SSH host key, disabling the server
crypto key zeroize rsa
!

That is the heavier option and it is worth understanding before running it. Zeroizing the RSA keys disables the SSH server outright, and it may affect other features that depend on those keys. Regenerating them means reconfiguring anything that trusted the old fingerprint.

Before disabling SSH completely, be certain about console access. A device with no remote management and no working console is a device someone has to physically visit, and if it is in a rack in another building that is a genuinely bad afternoon.

Not locking yourself out

The classic failure: you apply an access class that does not include your own address, the session drops immediately, and you have no way back in. There are two well-established defences and both are worth the small amount of setup.

The reload timer. Schedule an automatic reboot before making the change. If you lock yourself out, the device reboots into the last saved configuration - which does not contain your mistake, because you had not saved it.

! Before making changes
reload in 10
! System configuration has been modified. Save? [yes/no]: no
! Reload scheduled in 10 minutes

! ... make and verify your changes ...

! Once you are certain it works
reload cancel
write memory

This is the single most useful habit in network configuration and it costs one command. Use it for anything touching management access, routing, or interface addressing.

Configuration replace with a rollback timer. On platforms that support it, an archived configuration is automatically restored unless you confirm within a set time - the same safety net with a cleaner mechanism.

archive
 path flash:backup
 maximum 5
!
configure terminal revert timer 5

And before either: know your own source address as the router sees it. If your traffic is translated on the way, the address in the ACL must be the post-translation one, not the one on your laptop.

show users
show tcp brief | include ESTAB

The rest of the hardening

Restricting the source is one control. A few others belong in the same change window.

! SSH version 2 only
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 2

! Adequate key length
crypto key generate rsa modulus 2048

! Named users rather than a shared password
username netadmin privilege 15 secret <strong-password>

! Log what happens
logging host 10.0.100.20
login on-failure log
login on-success log

Version 2 only is not optional - version 1 has known weaknesses and should not be reachable. The authentication retry limit and timeout blunt brute-force attempts, and the logging lines turn failed access into something you can see rather than something you find out about later.

The wider principle: management interfaces should be reachable from a management network and nowhere else. An ACL on the VTY lines is the last line of that policy, not the whole of it. Ideally the management addresses are not routable from general user networks at all, and the access class is defence in depth rather than the only defence.

Verify after every change, from an allowed source and a denied one.

show line vty 0 15
show access-lists MGMT-ACCESS
show ip ssh

How this fits the rest of the stack

The reason network device hardening is fiddly is that the management plane and the thing being managed are the same box, so a mistake removes your ability to fix it. Application platforms separate those concerns - on RunxBuild, a service is reached over its live route while configuration, logs, and rollback live in the dashboard, so a bad change is undone rather than locked in. The RunxBuild hosting calculator shows what a service and its managed database cost as separate line items.

Useful related references:

• What Port is SSH: 22 (Default), How to Change, and Why
• Default Port for SSH: Why 22, and When to Change It
• What Port for SSH: 22, 2222, and the Right Defaults
• Database connection limits on RunxBuild

FAQ

How do I block SSH access on a Cisco router?

Apply an access class to the VTY lines rather than filtering an interface. The VTY lines are where inbound management sessions terminate, so a standard ACL applied there controls SSH regardless of which interface or address the connection arrived on.

Why does my interface ACL not block SSH to the router?

Interface ACLs primarily filter transit traffic, and getting them to cover management access means applying the rule on every interface and enumerating every address the router owns. The VTY access class handles all of that in one place, which is why it is the right tool.

How do I avoid locking myself out of a Cisco router?

Schedule an automatic reload before making the change and cancel it once you have verified access still works. If the change locks you out, the device reboots into the last saved configuration, which does not include your mistake because you had not saved it yet.

How do I disable SSH completely on a Cisco device?

Set the VTY lines to accept no inbound transport, which refuses every remote session type and leaves console access as the only path. Zeroizing the RSA keys also disables the SSH server but is heavier, since other features may depend on those keys.

Should I use a standard or extended ACL for VTY access?

A standard ACL is normally correct, because you are filtering on source address only - the destination is the router itself and the service is already constrained by the transport input line. Extended ACLs add complexity here without adding control.