Remote SSH access

[tebbens]

Hi !

To allow remote SSH access, I need to add an entry for the VTY ACL, but do I also need to add and entry for my WAN in (FE0) ACL ?

Thanks !

Matthew

[pkhatri]

Hi Matthew,

Yes, you will need to permit the relevant source addresses on any ACLs applied to the interfaces through which your SSH traffic is coming in...

Hope that helps - pls rate the post if it does.

Paresh

[Richard Burts]

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.

HTH

Rick

[tebbens]

Rick,

Yes, Default setup (via SDM) allowed both telnet and ssh only from the local network, but I wanted to be able to control the router/switch remotely. So I added/changed some stuff in the configuration;

Added the following to the ACL in, on FE0.

------------------------------------------

access-list 101 permit tcp any any eq 22

Added same for the VTY ACL.

---------------------------

access-list 102 remark VTY Access-class list

access-list 102 remark ---------------------

access-list 102 permit ip 192.168.1.0 0.0.0.255 any

access-list 102 permit tcp any any eq 22

access-list 102 deny ip any any

Here are the VTY entries

------------------------

line vty 0 4

access-class 102 in

authorization exec local_author

login authentication local_authen

transport input ssh

line vty 5 15

access-class 102 in

authorization exec local_author

login authentication local_authen

transport input ssh

I think I did everything correctly, seems to work ok.

Its my first cisco router/switch, so I'm new to this.

Thanks !

Matthew

Ps. Stopped using SDM after first day. :)

[Richard Burts]

Matthew

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.)

HTH

Rick

[tebbens]

Rick,

Yes, SDM created that on its own after I ran the SDM Security Audit. That was one of the listed recommendations...

access-list 102 remark VTY Access-class list

access-list 102 remark SDM_ACL Category=1

access-list 102 permit ip 192.168.1.1 0.0.0.255 any

access-list 102 deny ip any any

line vty 0 4

login authentication local_authen

authorization exec local_author

no privilege level

access-class 102 in

exit

line vty 5 15

login authentication local_authen

authorization exec local_author

no privilege level

access-class 102 in

exit

Matthew

[Richard Burts]

Matthew

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.

HTH

Rick

[tebbens]

Rick,

I want to be able to access my router and a Linux Box from anywhere via SSH, so I added that line to both my ACL-in for the CableModem interface and the VTY ACLs.

access-list 102 permit tcp any any eq 22

I don't understand where/why you think the port numbers change ?

I don't think I've opened up my router to anyone, as you still have to login with a valid id/pw, and SSH is all encrypted.

Matthew

[Richard Burts]

Matthew

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.

HTH

Rick