I would like to have the IOS: c7600s72033-advipservicesk9-mz.122-33.SRE1.bin running on the 7609 router. Is this IOS compatible with 6509, so I can update the IOS on the 6509 and then move the SUP?
You're speaking about a subject which is very confusing, and I apologize. For years, you could mostly get away with saying the biggest difference between a Catalyst 6500 chassis and Cisco 7600 chassis was the paint.
Times changed, starting in IOS 12.2SRB. Now, you are strongly discouraged from running IOS 12.2SRB (or after) on a Catalyst 6500 chassis, because Cisco split support for Catalyst 6500 and Cisco 7600 chassis into different software images and business units. There were business reasons for splitting support for Catalyst 6500 and Cisco 7600 branded systems. If you feel that you must run 7600 12.2SRB or later on a Catalyst 6500, please speak with your Cisco account manager; he should be able to contact the 7600 BU and get discussions going.
does the IOS s72033-adventerprisek9_wan-mz.122-33.SXJ.bin allow mac access-lists? I can create them but can't apply it to an interface ... Should I take into account something else?
It should, with some linecard limitations. Quoting the LAN Switching command reference:
For the Cisco 7600 series platform when ES20 or ES40 line cards are used, only the {permit | deny} {src-mac mask | any} {dest-mac mask | any}
part of the command syntax applies. If an extended MAC Access Control List is created using the [protocol [vlan vlan] [cos value]]
options, these options are ignored.
These options apply to LAN cards. If you were using an OSM or other "WAN" card, the issues are different.
Without TACACS, you have to setup a privilege level ("view") that only allows the commands you want them to run. Allowing access to the full config may expose passwords to accounts that have higher access than they do -- eventually, they'll figure that out and bypass such weak controls.
TACACS is really the direction you need to move. However, I do understand not wanting that headache.
Best Answer
You already know the majority of the answer to your own question - you need to configure commands the user can run at a specific privilege level.
enable
without a privilege level argument defaults to privilege level 15, which has permissions to run all commands. The two things you need to do are:Change the default enable password so the user doesn't have access to it anymore and therefore can't get to privilege level 15.
Set the user's default privilege level at login to the same privilege level that you've changed the desired commands the user can run at:
Router(config)#username joe privilege <x> password foobar
where X is the privilege level for your desired command set.
EDIT: I should point out that this doesn't actually provide true user based command authorization, it only provides privilege level based authorization, because the commands themselves are only bound to one privilege level at a time, so it's effectively a router-wide change. It's intended to work in a hierarchical fashion; each privilege level can run the commands at that level as well as all levels below it. If you want true user based authorization, you need an AAA server of some kind (see my note below).
You could technically also change the privilege level of the
enable
command to be one higher than the user's privilege level so they don't even have the option of running it:Router(config)#privilege exec level <x> enable
This of course assumes that you don't want the user to be able to run any configuration commands.
Another option is to make sure that when the user logs in and types
enable
they need to specify their privilege level rather than no privilege level, which defaults to 15.Router>enable <x>
Obviously you can specify enable passwords for all 16 privilege levels if you so desire.
My final point is that without an external AAA server, all of this is a giant pain in the ass. There are a multitude of open source TACACS+ implementations available that only have a cost of initial setup, but they make doing stuff like this somewhat trivial, and it's centralized, so if you have multiple routers you don't have to keep repeating the same command privilege jumprope on every device you manage. This is why AAA servers exist in the first place, so your requirement that you don't want to use one doesn't make a lot of sense.