Blocking SSH with access lists

bengma

Hi,

I am playing around with ssh and trying to disable it via an access list on the vty line.

I have a PC, switch and router connected as follows:

PC1 (10.1.1.100)

---

SW1 (10.1.1.11)

---

(10.1.1.1) R1

SW1 has ssh enabled:

line vty 0 4
login local
transport input ssh
line vty 5 15
login local
transport input ssh

and I can ssh from both the PC and the router to the switch.

Next, I added an extended access list on SW1 as follows:

SW1#show access-lists
Extended IP access list 100
10 deny tcp host 10.1.1.1 host 10.1.1.11 eq 22
20 permit tcp host 10.1.1.100 host 10.1.1.11 eq 22

line vty 0 4
access-class 100 in
login local
transport input ssh
line vty 5 15
access-class 100 in
login local
transport input ssh

Which has blocked access from R1 as intended but also blocked access from the PC.

Any ideas what I've got wrong?

Many thanks.

bhcs2014

Hello. Try applying a standard ACL to the vty lines. I believe extended ACLs do not work on vty lines.
A standard ACL will have the same effect since only ssh is allowed on the line (transport input ssh).

edit: Ok so I just tested your lab setup in packet tracer. Extended access list would not work unless the destination in the extended ACL was 'any':

10 permit tcp host 10.1.1.100 host 10.1.1.11 eq 22
20 permit tcp host 10.1.1.100 any eq 22 (2 match(es))

do sh access output ^^^

As you can see the first permit statement would not be matched by a ssh attempt. so the permit statement should be: permit tcp host 10.1.1.100 any eq 22. Of course standard ACLs will work as well but I think this is your issue. Neither your deny or permit statements are being matched and all traffic into the vty line is matched the 'implicit deny' automatically added to the end of all ACLs.

bengma

Thanks very much, I've tried both your suggestions and they both work. I've done some further reading and it looks like it's best to stick to standard access lists for VTY, exactly as you suggested.

I did some further reading (https://supportforums.cisco.com/discussion/10756526/access-list-line-vty) and found this:

The optimum solution for access-class applied on vty is to use a standard access list. It is possible to use an extended access list in the access-class but when you do the "destination" address must be any (which sort of defeats the purpose of using extended access lists).

While an extended access list can specify more specific addresses as source and destination when used in access-group on an interface (where it sees traffic with valid, specific source and destination addresses) it does not work that way in access-class on the vty. The reason for this has to do with how the access-class is implemented. One of the advantages of access-class is that it works on remote access to the vty ports. It does not matter which interface the request arrived on (what was the destination address) so there is no evaluation of the destination address in access-class only evaluation of the source address. So if you attempt to use an extended access list with a specific destination address it will not create a match in the logic of access-class.

Thanks again for your help.

james43026

There are still use cases for using an extended ACL on a VTY line. Like if you wanted to block telnet for a specific subnet, but then allow SSH from that same subnet. With a standard ACL you couldn't do that.