SHARIFUL's TECH BLOG

This is the continuation of Part - I , where we have configured X.509 certificate based SSH login with a Cisco Nexus switch. In this part we will do the same configuration; but AAA will be implemented in Cisco ISE with TACACS+ protocol. But we have the same limitations on the client side - we must use SecureCRT or  Pragma Fortress SSH Client .  In this blog the main difference will be two things. Firstly - we will not define any local user in the switch for whom we have the certificate in the YubiKey. Secondly - we will configure TACACS+ in the switch and configure Cisco ISE as TACACS+ server to do AAA remotely . One important difference here with normal AAA with TACACS+ is that - with X.509 based SSH - Authentication will be done still locally in the switch by verifying the user's CA certificate (no need of local account creation in the switch). Authorization and Accounting will be done in the TACACS+ server. Also X.509 SSH login is not supported with Radius protocol and t...

In the blog we will configure Cisco Nexus switch SSH login with YubiKey smartcards and X.509 certificates. The implementation has a limitation on the SSH client side. We must use a proprietary SSH-client. As of my knowledge; only two commercial/proprietary SSH-client support the functionality - SecureCRT and  Pragma Fortress SSH Client .  It will be two part series - in Part-I - AAA for SSH will be implemented locally in the switch and in Part-II - AAA will be implemented in a remote AAA server with TACACS+ protocol (Cisco ISE). We will use below simple topology -  01 - Network Topology We have already configured a YubiKey with user certificate/key (user's public/private key). Certificate related configuration like - configuring CA, issuing user certificates from the CA and transferring the user's certificates to YubiKey; will not be covered in this blog. One can easily find those by using simple Google search. This method of X.509 certificate based SSH-Login works sole...

The other day; I was testing how my ISP is protecting itself from customer exploitation. Normally I directly connect my router to the network cable provided by ISP. This time around I have connected a switch to the network cable from the  ISP. Then I have configured the switch port (ISP connection) to an access VLAN and also configured 2 other switch ports to the same vlan. Then I have connected 2 routers and expecting they will be assigned 2 IP addresses (1 for each router). To my surprise only one of the router was getting dynamically assigned IP adress from the ISP. The second router was not getting any IP adress at all. I even went further to set an static IP adress (from ISP network) to the second router. Another surprise - even with static IP assignment, that router could not even ping the ISP's gateway. That got me thinking - how the ISP is protecting itself from such customer exploitation in the first place. Disclaimer - This is just a story to show the readers how th...