Tag Archives: ios

SSH login with 2-Factor Authentication

During the holiday time, I was discussing with a mate on ways I could make my server more secure and he said why don’t I have 2-Factor Authentication. Of course, I dismissed him as a crazy man saying you can do that on SSH! When I actually looked I saw it could be done and it is a common place to have it done as well. I found a super page that explains how 2-Factor Authentication all works! With this in mind, this post will show how you can enable a SSH server with 2-Factor Authentication.

As always, I’ll be using Ubuntu 14.04 LTS. Because I use Google Authenticator for other things, I was happy to see that you can install Google Authenticator’s time-based one-time password (TOTP) via the apt-get repository. To install 2-factor authentication with Google Authenticator, we’ll need the open-source Google Authenticator PAM module. PAM stands for Pluggable Authentication Modules (PAM) provide dynamic authentication support for applications and services in a Linux. Essentially, it’s a way to easily plug different forms of authentication into a Linux system.

Firstly you will need to have Google Authenticator or Authentication App installed on your phone before doing anything. Personally I use Google’s Authenticator, for iOS App Store, for Android Google Play. Microsoft has their own Authenticator App for Windows Phones.

With the Authenticator installed on your phone, next you will need to install the Google package. You will need to have root and/or sudo access to the server and apt-get libpam-google-authenticator

sudo apt-get install libpam-google-authenticator

With the Module installed, you can set up your users with their OTP token. Run the google-authenticator utility, once ran you will be asked a series of questions that you can answer however best for you environment.

[email protected]:~$ google-authenticator 

Do you want authentication tokens to be time-based (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/[email protected]%3Fsecret%3DXYC73MOQV7SMPOSJ
Your new secret key is: XYC73MOQV7SMPOSJ
Your verification code is 194186
Your emergency scratch codes are:

Do you want me to update your "/home/marquk01/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
[email protected]:~$ 
Important Notes
You will need to keep safe the Emergency Scratch codes, just in case you lose access or have an issue with your OTP token. Your secret key will be used on the Authenticator app to generate your verification code. You can either manual enter the code or you can use scan QR-code that is generated on the cli to your phone. This is what you should expect to see when you run the google-authenticator utility. Once that’s has been done you will you should get something like this on your app

Next we will need to activate Google Authenticator within the sshd daemon. Firstly you will need to edit /etc/pam.d/sshd file by adding following lines below:

[email protected]:~$ sudo nano /etc/pam.d/sshd 
# To allow Google Authenticator for 2 factor authentication 
auth required pam_google_authenticator.so

Then you will need to edit the /etc/ssh/sshd_config file. Look for the ChallengeResponseAuthentication and ensure that this is yes

[email protected]:~$ sudo nano /etc/ssh/sshd_config 
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes

The full files should look something like this sshd and sshd_config

Now we need to restart the sshd daemon.

[email protected]:~$ sudo service ssh restart

Now that the ssh daemon has been restarted when you try and ssh back onto the server, you will be asked for your password and the OTP verification code

[[email protected] ~]$ ssh
Verification code: 

It also worked with Secure Copy Protocol (SCP), which allows transfer files via Secure Shell (SSH)

[[email protected] ~]$ scp bird.conf.oringial [email protected]:/home/marquk01
Verification code: 
bird.conf.oringial                            100% 6222     6.1KB/s   00:00
ALL Users will need to be configured to have 2-factor authentication before editing the ssh daemon. When I tried this the first time, I assumed it was pre-user enabled the everything to find out my main account was locked out… #GenuisAtWork! In addition, if you have a key-based authentication, they will take supersede 2-Factor Authentication and this will be ignored
Share this:

VRRP Between Cisco and Juniper Switches

For one of the many projects that I’ve been assigned at work, I got the chance to join the InfoSec Team and help design and configure their second site for their expanding network. Of course, any network engineer always wants to design and provision a network, they can call his/her own! So we were put on a plane and off to Sunny Glasgow, with a plan of attack and 4 days to get this first phase done.

To say it was a busy few days would be the understatement of the year, long days and nights on the data floor stacking, racking, patching and configuring. We had hard deadline to get everything configured and remotely accessible, so making sure the network was sorted was key! But one good thing was that the data floor was in one of our office buildings and it had a window! Inserts shameless instagram plug!


For those who haven’t worked in a dedicated datacentre, you wouldn’t understand how great natural light and view can be after 10 hours of work haha
In the end, phase one was completed on time (just), with everything working as expected. Inserts another shameless instagram plug


Missing from that post above was a Cisco 3750X that was used for vendor redundancy as part of the network. The guys had a HP c7000 Blade Chassis with 2 HP Virtual Connects Chassis Switches which needed to be connected to the edge switches, a Juniper EX4300 and the Cisco. This meant that I would have to span a vlan across two switches and share a default gateway between them. With this being the case, I had use a First-hop Redundancy Protocol (FHRP) and as I was using a multiple vendor topology, the FHRP of choice would have to be VRRP (Virtual Router Redundancy Protocol).

VRRP is best defined in RFC3768:

The Virtual Router Redundancy Protocol (VRRP) is designed to eliminate the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable.

As VRRP is an open standard, it’s interoperable between both Cisco and Juniper devices. If it were just using Cisco devices, I would have had a choice between VRRP or HSRP (Hot Standby Router Protocol). HSRP works similar as VRRP but it’s a Cisco Proprietary Protocol, which means it’s only compatible between Cisco devices. You can see more detail on HSRP in RFC2281

Due to the upstream routing requirements and the EX4300 being higher specced switch, it was decided that the EX4300 was going to be the Master. The topology I was working with is shown below.

VRRP Topology
With that all explained, Let’s get cracking 😀

Juniper Configuration

Physical Interface ConfigurationIntegrated Routing & Bridging ConfigurationVlan Configuration
xe-0/2/3 {
    description "TRUNK to Edge Cisco";
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members reith;
irb {
    unit 100 {                          
        family inet {
            address {
                vrrp-group 1 {
                    priority 150;
vlans {
    reith {
        vlan-id 100;
        l3-interface irb.100;
With the irb configuration, under the vrrp-group stanza, I had to add the command accept-data. Adding this command it will enable the master router to accept all packets destined for the Virtual IP (VIP) address. If this isn’t enabled when the EX4300 is set/becomes master, it will not respond to any packets sent to the VIP address!

Cisco Configuration

Physical Interface t1/1/2Routed VLAN Interface
egde-cisco#show run int t1/1/2 
Building configuration...

Current configuration : 137 bytes
interface TenGigabitEthernet1/1/2
 description "TRUNK to Edge Juniper"
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100
 switchport mode trunk
egde-cisco#show run int vlan100
Building configuration...

Current configuration : 176 bytes
interface Vlan100
 ip address
 vrrp 1 description "TRUNK to Edge Juniper"
 vrrp 1 ip
 no vrrp 1 preempt
 vrrp 1 priority 145

Juniper Verification

Depending on the level of detail you want to go into, you can run of any of these commands show vrrp summary, show vrrp detail or show vrrp extensive. I mostly use show vrrp summary or show vrrp detail as ive found (most of time) that you get want you need from either useless you’ve had a big issue and extensive detail is needed!

Show VRRP SummaryShow VRRP Detail
[email protected]> show vrrp summary     
Interface     State       Group   VR state       VR Mode    Type   Address 
irb.100       up              1   master          Active    lcl         
[email protected]> show vrrp detail       
Physical interface: irb, Unit: 100, Address:
  Index: 547, SNMP ifIndex: 567, VRRP-Traps: disabled, VRRP-Version: 2
  Interface state: up, Group: 1, State: master, VRRP Mode: Active
  Priority: 150, Advertisement interval: 1, Authentication type: none
  Advertisement threshold: 3, Computed send rate: 0
  Preempt: no, Accept-data mode: yes, VIP count: 1, VIP:       
  Advertisement Timer: 0.064s, Master router:
  Virtual router uptime: 19:40:12, Master router uptime: 19:40:04
  Virtual Mac: 00:00:5e:00:01:01 
  Tracking: disabled

Cisco Verification

On a Cisco, you can check VRRP status by running the command show vrrp

egde-cisco#show vrrp 
Vlan100 - Group 1  
"TRUNK to Edge Juniper"
  State is Backup  
  Virtual IP address is
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption disabled
  Priority is 145 
  Master Router is, priority is 145 
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.433 sec

And with that we are done! Confirmed VRRP is working as expected! To be honest, before getting started I was a little worried that ill be running into plenty of issues running cross vendor but it was pretty straightforward, which is always good when you’re under the gun 🙂

Share this: