From daniel.schmidt at wyo.gov Wed Mar 9 21:12:40 2016 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 9 Mar 2016 14:12:40 -0700 Subject: [tac_plus] New do_auth Message-ID: Jathan and I have release a new do_auth that fixes long pairs for ASA: https://github.com/jathanism/do_auth For those who unaware, do_auth provides granular control to tac_plus thus giving you the option to limit access to your gear based on command, ip, or even source ip in any combination you want. It also helps nx-os and IOS to play well on the same tac_plus server and even lets you switch tac_pairs sent to devices. (NXOS roles, for instance) Tacacs implementations vary greatly. If you find a device that doesn't work, shoot me an email - we can probably fix it. Lastly, if you have found do_auth to be helpful in your environment, I would appreciate a quick email and, if possible, note what company is using it. -- E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahafaye at gmail.com Wed Mar 9 22:55:50 2016 From: mahafaye at gmail.com (Mohamed Faye) Date: Wed, 9 Mar 2016 22:55:50 +0000 Subject: [tac_plus] New do_auth In-Reply-To: References: Message-ID: Thanks so much for the feedback. On Wednesday, 9 March 2016, Daniel Schmidt wrote: > Jathan and I have release a new do_auth that fixes long pairs for ASA: > > https://github.com/jathanism/do_auth > > For those who unaware, do_auth provides granular control to tac_plus thus > giving you the option to limit access to your gear based on command, ip, or > even source ip in any combination you want. It also helps nx-os and IOS to > play well on the same tac_plus server and even lets you switch tac_pairs > sent to devices. (NXOS roles, for instance) > > Tacacs implementations vary greatly. If you find a device that doesn't > work, shoot me an email - we can probably fix it. > > Lastly, if you have found do_auth to be helpful in your environment, I > would appreciate a quick email and, if possible, note what company is using > it. > > -- > > E-Mail to and from me, in connection with the transaction > of public business, is subject to the Wyoming Public Records > Act and may be disclosed to third parties. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20160309/92acdc1f/attachment.html > > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Cruse at Instinet.com Wed Mar 16 15:52:49 2016 From: Kevin.Cruse at Instinet.com (Kevin.Cruse at Instinet.com) Date: Wed, 16 Mar 2016 11:52:49 -0400 Subject: [tac_plus] Tacacs host key and do_auth questions In-Reply-To: References: <20160105181103.GH65066@shrubbery.net> Message-ID: Hi All I have a few questions regarding host keys and do_auth. First, I have a few routers i'd like to configure with a separate 'tacac-server key' than rest of our network. These devices require external users to access and therefore will need higher level of security. In my tac_plus.cfg i have the global configuration of: key = blahblahblah and the individual routers which require different key, i've configured the following in tac_plus.cfg: host = 1.1.1.1 { key = differentkey } The issue I have is when logging into router with separate key, it fails authentication as server is expecting 'blahblahblah' but router is sending 'differentkey'. I thought by configuring the 'host' object it would override the global key. Does anyone know how I may get this to work? I've pasted the debug from server for your review tac_plus.cfg key = blahblahblah host = 1.1.1.1 { key = differentkey } Debug output: !! ROUTER 1.1.1.1 is configured with "tacacs-server key differentkey" !! Reading config Version F4.0.4.28 Initialized 1 tac_plus server F4.0.4.28 starting socket FD 4 AF 2 uid=0 euid=0 gid=0 egid=0 s=15505120 session request from 1.1.1.1 sock=5 connect from 1.1.1.1 [172.28.10.124] Waiting for packet Read AUTHEN/START size=40 validation request from 1.1.1.1 PACKET: key=blahblahblah version 192 (0xc0), type 1, seq no 1, flags 0x1 session_id 2825152057 (0xa8646639), Data length 28 (0x1c) End header type=AUTHEN/START, priv_lvl = 72 action=UNKNOWN 132 authen_type=unknown 215 service=unknown 219 user_len=208 port_len=45 (0x2d), rem_addr_len=0 (0x0) data_len=61 AUTHEN/START data length (314) exceeds packet length length 20 1.1.1.1 : Invalid AUTHEN/START packet (check keys) Writing AUTHEN/ERROR size=87 PACKET: key=blahblahblah version 192 (0xc0), type 1, seq no 2, flags 0x1 session_id 2825152057 (0xa8646639), Data length 75 (0x4b) End header type=AUTHEN status=7 (AUTHEN/ERROR) flags=0x0 msg_len=69, data_len=0 msg: 1.1.1.1 : Invalid AUTHEN/START packet (check keys) data: End packet 1.1.1.1: disconnect Second, I have the following configured in do_auth.ini (this is a separate issue from tacacs-server key and not related...when I normalize the key on router to blahblahblah I get the following after successful authentication): [users] test_support = support [support] host_allow = 10.10.10.1 device_permit = 1.1.1.1 command_permit = .* 2016-03-16 11:36:56: User 'test_support' not allowed access to device '1.1.1.1' in 'support'->'device_permit' I thought by adding the router IP address of 1.1.1.1 under device_permit it should allow user to send commands. I am wondering if im hitting bug? Any ideas, thoughts, suggestions greatly appreciated. Thanks. Kevin ----------------------------------------------------------------- Kevin Cruse US Networks Instinet LLC 309 West 49th Street New York, NY 10019 US kevin.cruse at instinet.com 212-310-4734 ========================================================================================================= <<<< Disclaimer >>>> This message is intended solely for use by the named addressee(s). If you receive this transmission in error, please immediately notify the sender and destroy this message in its entirety, whether in electronic or hard copy format. Any unauthorized use (and reliance thereon), copying, disclosure, retention, or distribution of this transmission or the material in this transmission is forbidden. We reserve the right to monitor and archive electronic communications. This material does not constitute an offer or solicitation with respect to the purchase or sale of any security. It should not be construed to contain any recommendation regarding any security or strategy. Any views expressed are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. This communication is provided on an ?as is? basis. It contains material that is owned by Instinet Incorporated, its subsidiaries or its or their licensors, and may not, in whole or in part, be (i) copied, photocopied or duplicated in any form, by any means, or (ii) redistributed, posted, published, excerpted, or quoted without Instinet Incorporated's prior written consent. Please access the following link for important information and instructions: http://instinet.com/includes/index.jsp?thePage=/html/le_index.txt Securities products and services are provided by locally registered brokerage subsidiaries of Instinet Incorporated: Instinet Australia Pty Limited (ACN: 131 253 686 AFSL No: 327834), regulated by the Australian Securities & Investments Commission; Instinet Canada Limited, member IIROC/CIPF; Instinet Pacific Limited, authorized and regulated by the Securities and Futures Commission of Hong Kong; Instinet Singapore Services Private Limited, regulated by the Monetary Authority of Singapore, trading member of The Singapore Exchange Securities Trading Private Limited and clearing member of The Central Depository (Pte) Limited; and Instinet, LLC, member SIPC. ========================================================================================================= -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 41091648.gif Type: image/gif Size: 4077 bytes Desc: not available URL: From heas at shrubbery.net Wed Mar 16 16:15:35 2016 From: heas at shrubbery.net (heasley) Date: Wed, 16 Mar 2016 16:15:35 +0000 Subject: [tac_plus] Tacacs host key and do_auth questions In-Reply-To: References: <20160105181103.GH65066@shrubbery.net> Message-ID: <20160316161535.GB25224@shrubbery.net> Wed, Mar 16, 2016 at 11:52:49AM -0400, Kevin.Cruse at Instinet.com: > > Hi All > > I have a few questions regarding host keys and do_auth. > > First, I have a few routers i'd like to configure with a separate > 'tacac-server key' than rest of our network. These devices require > external users to access and therefore will need higher level of security. > In my tac_plus.cfg i have the global configuration of: > > key = blahblahblah > > and the individual routers which require different key, i've configured the > following in tac_plus.cfg: > > host = 1.1.1.1 { > key = differentkey > } > > The issue I have is when logging into router with separate key, it fails > authentication as server is expecting 'blahblahblah' but router is sending > 'differentkey'. I thought by configuring the 'host' object it would > override the global key. Does anyone know how I may get this to work? I've > pasted the debug from server for your review > > tac_plus.cfg > > key = blahblahblah > > host = 1.1.1.1 { > key = differentkey > } yes, this should work. You have obfuscated the addresses below, so is the device connecting from 1.1.1.1 or another interface? It must match and can usually be forced by configuring the source-interface on the device. also, you may need this patch: Index: packet.c =================================================================== --- packet.c (revision 3704) +++ packet.c (revision 3714) @@ -147,7 +147,7 @@ /* decrypt the data portion */ tkey = cfg_get_host_key(session.peerip); if (tkey == NULL && !STREQ(session.peer, session.peerip)) { - tkey = cfg_get_host_prompt(session.peer); + tkey = cfg_get_host_key(session.peer); } if (tkey == NULL) tkey = session.key; @@ -547,7 +547,7 @@ /* encrypt the data portion */ tkey = cfg_get_host_key(session.peerip); if (tkey == NULL && !STREQ(session.peer, session.peerip)) { - tkey = cfg_get_host_prompt(session.peer); + tkey = cfg_get_host_key(session.peer); } if (tkey == NULL) tkey = session.key; Index: CHANGES =================================================================== --- CHANGES (revision 3704) +++ CHANGES (revision 3714) @@ -488,3 +488,4 @@ XXX needs a configure test to check for sha512 support. - fix libtacacs link - from Gentoo via Ruben Farrelly - fix -U decription in manpage + - call correct function for host key look-up by hostname - Adam Dyess > > Debug output: > > !! ROUTER 1.1.1.1 is configured with "tacacs-server key differentkey" !! > Reading config > Version F4.0.4.28 Initialized 1 > tac_plus server F4.0.4.28 starting > socket FD 4 AF 2 > uid=0 euid=0 gid=0 egid=0 s=15505120 > session request from 1.1.1.1 sock=5 > connect from 1.1.1.1 [172.28.10.124] > Waiting for packet > Read AUTHEN/START size=40 > validation request from 1.1.1.1 > PACKET: key=blahblahblah > version 192 (0xc0), type 1, seq no 1, flags 0x1 > session_id 2825152057 (0xa8646639), Data length 28 (0x1c) > End header > type=AUTHEN/START, priv_lvl = 72 > action=UNKNOWN 132 > authen_type=unknown 215 > service=unknown 219 > user_len=208 port_len=45 (0x2d), rem_addr_len=0 (0x0) > data_len=61 > AUTHEN/START data length (314) exceeds packet length length 20 > 1.1.1.1 : Invalid AUTHEN/START packet (check keys) > Writing AUTHEN/ERROR size=87 > PACKET: key=blahblahblah > version 192 (0xc0), type 1, seq no 2, flags 0x1 > session_id 2825152057 (0xa8646639), Data length 75 (0x4b) > End header > type=AUTHEN status=7 (AUTHEN/ERROR) flags=0x0 > msg_len=69, data_len=0 > msg: > 1.1.1.1 : Invalid AUTHEN/START packet (check keys) > data: > End packet > 1.1.1.1: disconnect > > > Second, I have the following configured in do_auth.ini (this is a separate > issue from tacacs-server key and not related...when I normalize the key on > router to blahblahblah I get the following after successful > authentication): > > [users] > test_support = > support > [support] > host_allow = > 10.10.10.1 > device_permit = > 1.1.1.1 > command_permit = > .* > > 2016-03-16 11:36:56: User 'test_support' not allowed access to device > '1.1.1.1' in 'support'->'device_permit' > > I thought by adding the router IP address of 1.1.1.1 under device_permit it > should allow user to send commands. I am wondering if im hitting bug? i believe this just allows the user to login from the host 1.1.1.1. From daniel.schmidt at wyo.gov Wed Mar 16 18:33:18 2016 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 16 Mar 2016 12:33:18 -0600 Subject: [tac_plus] Tacacs host key and do_auth questions In-Reply-To: <20160316161535.GB25224@shrubbery.net> References: <20160105181103.GH65066@shrubbery.net> <20160316161535.GB25224@shrubbery.net> Message-ID: I'd change your host_allow to .* for the purposes of testing to see if that is it. On Wed, Mar 16, 2016 at 10:15 AM, heasley wrote: > Wed, Mar 16, 2016 at 11:52:49AM -0400, Kevin.Cruse at Instinet.com: > > > > Hi All > > > > I have a few questions regarding host keys and do_auth. > > > > First, I have a few routers i'd like to configure with a separate > > 'tacac-server key' than rest of our network. These devices require > > external users to access and therefore will need higher level of > security. > > In my tac_plus.cfg i have the global configuration of: > > > > key = blahblahblah > > > > and the individual routers which require different key, i've configured > the > > following in tac_plus.cfg: > > > > host = 1.1.1.1 { > > key = differentkey > > } > > > > The issue I have is when logging into router with separate key, it fails > > authentication as server is expecting 'blahblahblah' but router is > sending > > 'differentkey'. I thought by configuring the 'host' object it would > > override the global key. Does anyone know how I may get this to work? > I've > > pasted the debug from server for your review > > > > tac_plus.cfg > > > > key = blahblahblah > > > > host = 1.1.1.1 { > > key = differentkey > > } > > yes, this should work. You have obfuscated the addresses below, so is the > device connecting from 1.1.1.1 or another interface? It must match and > can usually be forced by configuring the source-interface on the device. > also, you may need this patch: > > Index: packet.c > =================================================================== > --- packet.c (revision 3704) > +++ packet.c (revision 3714) > @@ -147,7 +147,7 @@ > /* decrypt the data portion */ > tkey = cfg_get_host_key(session.peerip); > if (tkey == NULL && !STREQ(session.peer, session.peerip)) { > - tkey = cfg_get_host_prompt(session.peer); > + tkey = cfg_get_host_key(session.peer); > } > if (tkey == NULL) > tkey = session.key; > @@ -547,7 +547,7 @@ > /* encrypt the data portion */ > tkey = cfg_get_host_key(session.peerip); > if (tkey == NULL && !STREQ(session.peer, session.peerip)) { > - tkey = cfg_get_host_prompt(session.peer); > + tkey = cfg_get_host_key(session.peer); > } > if (tkey == NULL) > tkey = session.key; > Index: CHANGES > =================================================================== > --- CHANGES (revision 3704) > +++ CHANGES (revision 3714) > @@ -488,3 +488,4 @@ > XXX needs a configure test to check for sha512 support. > - fix libtacacs link - from Gentoo via Ruben Farrelly > - fix -U decription in manpage > + - call correct function for host key look-up by hostname - Adam > Dyess > > > > > Debug output: > > > > !! ROUTER 1.1.1.1 is configured with "tacacs-server key differentkey" !! > > Reading config > > Version F4.0.4.28 Initialized 1 > > tac_plus server F4.0.4.28 starting > > socket FD 4 AF 2 > > uid=0 euid=0 gid=0 egid=0 s=15505120 > > session request from 1.1.1.1 sock=5 > > connect from 1.1.1.1 [172.28.10.124] > > Waiting for packet > > Read AUTHEN/START size=40 > > validation request from 1.1.1.1 > > PACKET: key=blahblahblah > > version 192 (0xc0), type 1, seq no 1, flags 0x1 > > session_id 2825152057 (0xa8646639), Data length 28 (0x1c) > > End header > > type=AUTHEN/START, priv_lvl = 72 > > action=UNKNOWN 132 > > authen_type=unknown 215 > > service=unknown 219 > > user_len=208 port_len=45 (0x2d), rem_addr_len=0 (0x0) > > data_len=61 > > AUTHEN/START data length (314) exceeds packet length length 20 > > 1.1.1.1 : Invalid AUTHEN/START packet (check keys) > > Writing AUTHEN/ERROR size=87 > > PACKET: key=blahblahblah > > version 192 (0xc0), type 1, seq no 2, flags 0x1 > > session_id 2825152057 (0xa8646639), Data length 75 (0x4b) > > End header > > type=AUTHEN status=7 (AUTHEN/ERROR) flags=0x0 > > msg_len=69, data_len=0 > > msg: > > 1.1.1.1 : Invalid AUTHEN/START packet (check keys) > > data: > > End packet > > 1.1.1.1: disconnect > > > > > > Second, I have the following configured in do_auth.ini (this is a > separate > > issue from tacacs-server key and not related...when I normalize the key > on > > router to blahblahblah I get the following after successful > > authentication): > > > > [users] > > test_support = > > support > > [support] > > host_allow = > > 10.10.10.1 > > device_permit = > > 1.1.1.1 > > command_permit = > > .* > > > > 2016-03-16 11:36:56: User 'test_support' not allowed access to device > > '1.1.1.1' in 'support'->'device_permit' > > > > I thought by adding the router IP address of 1.1.1.1 under device_permit > it > > should allow user to send commands. I am wondering if im hitting bug? > > i believe this just allows the user to login from the host 1.1.1.1. > > _______________________________________________ > tac_plus mailing list > tac_plus at shrubbery.net > http://www.shrubbery.net/mailman/listinfo/tac_plus > -- E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From btttyttadmin at admin.shenzheh.win Wed Mar 23 21:57:12 2016 From: btttyttadmin at admin.shenzheh.win (Rubber tires and rubber products/769admin vvddadmin) Date: Wed, 23 Mar 2016 21:57:12 +0000 Subject: [tac_plus] =?gb2312?b?UnViYmVyIHRpcmVzIGFuZCBydWJiZXIgcHJvZHVj?= =?gb2312?b?dHMvNzY5YWRtaW4gdnZkZGFkbWlu0+vE+rmyz+3By8/gsuGhow==?= Message-ID: <001a11c2f1748b6f70052ebe690e@google.com> Dear Sir/Madam, Glad to hear that you"re on the market for rubber products. We specialized in producing good quality rubber tires and rubber products in Qingdao for 20 years, most of our tires are applied in planters,seeders,mowers, tillers, aerators, floor cleaning equipment, generators. etc our cooperative customers Hoosier, Maschio, Kubotam Torom OTR, etc Hope we would have more communication in the future if our wheels are suitable for your company. We can make samples according to your exact requirement and drawings. FREE existed SAMPLES could be sent on request. Please feel free to contact us in your convenient time. Wait for your reply! Thanks and best regards, Susie ************************************** Industrial Products Co., Ltd Qingdao, P.R.China https://picasaweb.google.com/lh/sredir?uname=116587663229581450330&target=ALBUM&id=6261825251642486897&authkey=Gv1sRgCOya88KHgLv3pAE&invite=CNu5uacL&feat=email -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: picasaweblogo-zh_CN.gif Type: image/gif Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: email.jpg Type: image/jpeg Size: 10281 bytes Desc: not available URL: