I believe some clarification of the original question is called for. The original question mentions changes to the VTY ACL. To me that implies that there is already remote access via telnet and that they want to change it to access via SSH. I believe it depends a little bit on how the VTY ACL is coded, and especially depends on whether there is to be any change in the addresses that are allowed remote access. But in most cases (where the VTY ACL is done with a standard ACL rather than an extended ACL) I believe no change will be needed in the VTY ACL.
I believe that whether changes are needed in the interface ACL depends on how the ACL is coded. If the interface ACL is coded with permit for certain source addresses and TCP port 23 (telnet) then yes changes will be needed to permit those addresses for TCP port 22 (SSH). But if the interface ACL permits IP for the source addresses then I believe no change will be needed.
So if the original poster can provide some clarification about what currently exists then we will be able to give better answers about whether changes are needed.
The entry that you added to access list 101 seems right and would allow SSH traffic (assuming that it is applied inbound on the interface).
The use of access list 102 on the VTY seems to me to be a bit unusual. Access class on the VTY usually uses a standard access list rather than an extended list. Did SDM create that or was that your choice? (access class can work with either standard or extended access lists, but I find the logic to construct the extended list to be a bit more complex.)
Well that is one more thing that surprises me about SDM. As I said extended access lists can work in access-class but the usual practice is to use standard access lists.
I looked again at your earlier post and noticed the line that you inserted into access-list 102 was permit tcp any any eq 22. I have not used it that way and am not sure what effect specifying the tcp port will have. When I have done extended access lists for access-class I permitted and denied ip source_address any (as the list produced by SDM does). By the time the packet gets to the access class I am not sure that it will match to tcp port 22. Also by specifying "any" as the source you have opened the router up to anyone and I wonder if that is what you really want to do.
I do not "know" that the port numbers change. I just know that using extended access lists for access-class does not always work the way that you would think. I suggest that you test it and let us know the outcome.
You are correct that requiring a valid userID and password does provide some protection. My point about permit any any is that it does not provide any protection. If you are going to permit anything that comes in then there is very little reason to configure access-class on the vty because it will not protect anything because it is permitting everything that comes through. So if you are going to permit any any why not just take out the access-class?
It is your router and you certainly may configure it any way that you want. But my advice is to not put something in that looks like it is doing something, but really is doing nothing.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...