» How to Secure SSH with Google Authenticator’s Two-Factor Authentication

Standard

http://www.howtogeek.com/121650/how-to-secure-ssh-with-google-authenticators-two-factor-authentication/

How to Secure SSH with Google Authenticator’s Two-Factor Authentication
Published on August 14th, 2012  |  Written by: Chris Hoffman

Want to secure your SSH server with easy-to-use two-factor authentication? Google provides the necessary software to integrate Google Authenticator’s time-based one-time password (TOTP) system with your SSH server. You’ll have to enter the code from your phone when you connect.

Google Authenticator doesn’t “phone home” to Google — all the work happens on your SSH server and your phone. In fact, Google Authenticator is completely open-source, so you can even examine its source code yourself.

Install Google Authenticator
To implement multifactor authentication with Google Authenticator, we’ll need the open-source Google Authenticator PAM module. PAM stands for “pluggable authentication module” – it’s a way to easily plug different forms of authentication into a Linux system.

Ubuntu’s software repositories contain an easy-to-install package for the Google Authenticator PAM module. If your Linux distribution doesn’t contain a package for this, you’ll have to download it from the Google Authenticator downloads page on Google Code and compile it yourself.

To install the package on Ubuntu, run the following command:

sudo apt-get install libpam-google-authenticator

(This will only install the PAM module on our system – we’ll have to activate it for SSH logins manually.)

Create an Authentication Key
Log in as the user you’ll be logging in with remotely and run the google-authenticator command to create a secret key for that user.

Allow the command to update your Google Authenticator file by typing y. You’ll then be prompted with several questions that will allow you to restrict uses of the same temporary security token, increase the time window that tokens can be used for, and limit allowed acces attempts to hinder brute-force cracking attempts. These choices all trade some security for some ease-of-use.

Google Authenticator will present you with a secret key and several “emergency scratch codes.” Write down the emergency scratch codes somewhere safe – they can only be used one time each, and they’re intended for use if you lose your phone.

Enter the secret key in the Google Authenticator app on your phone (official apps are available for Android, iOS, and Blackberry). You can also use the scan barcode feature – go to the URL located near the top of the command’s output and you can scan a QR code with your phone’s camera.

You’ll now have a constantly changing verification code on your phone.

If you want to log in remotely as multiple users, run this command for each user. Each user will have their own secret key and their own codes.

Activate Google Authenticator
Next you’ll have to require Google Authenticator for SSH logins. To do so, open the /etc/pam.d/sshd file on your system (for example, with the sudo nano /etc/pam.d/sshd command) and add the following line to the file:

auth required pam_google_authenticator.so

Next, open the /etc/ssh/sshd_config file, locate the ChallengeResponseAuthentication line, and change it to read as follows:

ChallengeResponseAuthentication yes

(If the ChallengeResponseAuthentication line doesn’t already exist, add the above line to the file.)

Finally, restart the SSH server so your changes will take effect:

sudo service ssh restart

You’ll be prompted for both your password and Google Authenticator code whenever you attempt to log in via SSH.

15 Responses

JEAN-FRANCOIS MESSIER
August 14, 2012 at 8:00 am
Excellent article. I use this authenticator for my main GMail account for a while now, and I really like the fact that I can have multiple secret keys and number generators on my phone. The trick is now to see whether I can replicate the secret key across multiple servers to have a single generated code to access multiple servers.

FOO
August 14, 2012 at 8:38 am
I’m in love with Google’s 2-factor auth. I use it for Google account(obviously), LastPass, SSH, and once implemented…dropbox =D

REKLAIMER
August 14, 2012 at 11:07 am
Tried this under my ubuntu 10.10 server. Even when adding a repo manually that I found it still could not find the libpam-google-authenticator package. Maybe it just doesn’t work for 10.10?

FOOBAR
August 14, 2012 at 12:53 pm
Someone needs to add this to Tomato/DD-WRT

TIM
August 14, 2012 at 3:42 pm
I had this on my SSH server for a little while… it worked really well… and then I went to connect with WinSCP… there isn’t a great implementation for connecting via SFTP.

CPRADIO
August 14, 2012 at 6:32 pm
I’m with Tim, I can’t really use this without WinSCP support…. sigh

DELTARAY
August 14, 2012 at 11:01 pm
It seems that you’re using a libvte based terminal (gnome-terminal) in your example screenshots, since you are concerned enough about security to implement two factor auth, you really should check out this document, which documents a major security flaw in that library:

http://climagic.org/bugreports/libvte-scrollback-written-to-disk.html

TOTO
August 16, 2012 at 3:19 am
Interesting article, the idea looks interesting.

Just a quick question, can you still have several way to connect to your ssh server at the same time?

Basically, I’m usually connecting to my ssh server from my laptop or tablet, so I created a public/private pair of key (DSA), because it’s faster, more secure etc…

I would like to use the google system but only if I’m not able to use my private key. Is there is a a way to do that?
Thanks,

REARDEN
August 16, 2012 at 2:16 pm
For those that are concerned about your smart phone not have battery charge on being in an area that has no coverage, there is a simpler alternative at: http://taferno.sourceforge.net

It uses simple USB flash drives and provides Two-Factor Authentication for:
1. OpenVPN
2. SSH
3. Web Single Sign On

DAVE
August 16, 2012 at 6:01 pm
To both Tim and cpradio, not sure what you’re on about here. I’ve had Google Authenticator set-up for some time now on my SSH server, WinSCP seems to work fine for me. Just make sure you’re running the latest version. Failing that, if you use SSH keys, two factor authentication is bypassed. WinSCP supports both Challenge Response and SSH keys.

BOBBY
August 17, 2012 at 12:21 am
A million thank-yous!

NANAKOS CHRYSOSTOMOS
August 17, 2012 at 3:07 pm
I think that the yubikey or softyubikey for gnome, kde, cinnamon and mate is a better solution. Please check them out. I solves all previous problems. Cheers!

ASELVAN
August 22, 2012 at 9:02 am
@Toto: if you don’t have your private key on a device you are trying to login from, and you have setup the two-factor authentication with google authenticator, sshd will do two factor authentication. You don’t have to do anything, it will work exactly like you want. I have the same need and it works correctly i.e. uses key based login where private keys are available and two factor when keys are not available.

TOTO
August 23, 2012 at 5:41 am
@aselvan : Thanks for your input, I actually tried that and it worked like a charm.

For those of you who are interested to do so, I recommend you to set the shared key as preferred login method.

ANDREW
September 13, 2012 at 12:30 am
Hi

I have two types of authentication on my server.
One is used just for my account to administer the server (not root) that has public/private keys
The second has just user and pass, but has shell access restricted, are locked in to using a shared ftp folder and are restricted from doing pretty much anything but ftp and http forwarding. (via a group policy in sshd)

I can see that above toto had asked if it was possible to use either public keys or authenticator if not available. is it possible to have the authenticator AND the pub/private key for the standard account, while leaving the accounts in my restricted group untouched.

its probably overkill, with what feels like 3 step protection, but i am curious if it is possible.

2,184 total views, no views today

Poor man’s VPN with SSH | Setting up an SSH tunnel with PuTTY

Standard

Article #1 From: http://fnord.no/sysadmin/security/vpn-with-ssh
Article #2 From: http://realprogrammers.com/how_to/set_up_an_ssh_tunnel_with_putty.html


Poor man’s VPN with SSH

SSH has port forwarding, dynamic forwarding, and now also IP forwarding. This allows you to create connections out through a firewall, and allow other connections in and out through your SSH-connection, originating at your SSH server. Read on for a few examples of use, and make sure you have the blessing of your security team.

Local forwarding

With local forwarding, you open a local port, and forward it to another host and port from the remote server.

Often used with forwarding to single webservers, proxies, Citrix ICA servers, VNC servers, and Windows Remote Desktop (RDP).

Example with local forwarding

Connect to a server at work, forwarding a connection from port 10080 on my laptop to important.server.example.org.

I can then open my browser to http://localhost:10080, and do my stuff. Some web applications, though, can be tricky enough to expect a hostname, and for that you need to edit /etc/hosts or equivalent, or you can read on for dynamic forwarding.

Remote forwarding

With remote forwarding, you open a listening port on the remote side, and forward it to another host and port from the local server.

Example with remote forwarding

One useful scenario is to help family members who have PC trouble. For instance: Mom has a problem, calls me, and wonders if I can help, and then clicks an icon on her desktop that does the following thing:

  • Starts Remote Desktop or VNC
  • Connects to my SSH server, with remote forwarding from <vncport1> on the SSH server, to localhost:<vncport1> on her PC.

What I do, is:

  • Connect to my SSH server, with local forwarding from <vncport1> on my laptop, to <vncport1> on the SSH server, which again connects through the remote forwarding to localhost:<vncport1> on mom’s PC.
  • Start a VNC client, and connect to my localhost:5801 on my laptop. This port is now connected through my ssh session, to mom’s ssh session, to her PC.

Dynamic forwarding with SOCKS

OpenSSH’s client has the ability to do dynamic forwarding to act as a local SOCKS server, both for SOCS4 and SOCS5.

Many programs have built-in SOCKS support, so if you enable this, and configure it to use localhost:<socksport> as a SOCKS proxy.

For programs with no built-in SOCKS support, you can use “tsocks”, to intercept networking calls, and work through the SOCKS server.

Example with dynamic forwarding

Then I configure Firefox, for instance, to use the SOCKS server at localhost port 1080, and all my web connections will go through the SSH connection, and appear to be initiated from myserver.example.com. Much easier than with local forwarding, and works great for remote administration of things from home where you use different hostnames and ports, and perhaps also unroutable IP addresses.

IP forwarding with TUN

Now we’re talking. This is the real thing, we get IP forwarding through a point-to-point interface. This exists only in newer versions of OpenSSH, and is not very well documented yet. Unfortunately, this also includes this document until I have more time to research further.

Example with IP forwarding

Where ‘0’ is the local device tun0, and ‘1’ refers to the remote device tun1. On each side, one needs to set an IP address for host-to-host contact, and add routing and perhaps also NAT for network access.

Beware, as careless use of IP forwarding between sites may have a serious impact on network security, and may make others very angry if used without permission.


realprogrammers.com

Setting up an SSH tunnel with PuTTY

What follow is how to set up as SSH tunnel using PuTTY with the MySQL port (3306) forwarded as an example. After completing this how-to you’ll have port 3306 on your local machine listening and forwarding to your remote server’s localhost on port 3306. Thus effectively you can connect to the remote server’s MySQL database as though it were running on your local box.

Prerequisites

This how-to assumes your MySQL installation has enabled listening to a TCP/IP connection. Only listening on 127.0.0.1 is required (and the default as of MySQL 4.1). Although beyond the scope of this how-to, you can verify the server’s listening by using

on the server. Look for

and

in your

. Also, a trouble-shooting guide.

To achieve the same with PostgreSQL simply use PostgreSQL’s default port, 5432.

to test;

and the manual as pointers for configuration.

Set up the tunnel

Create a session in PuTTY and then select the Tunnels tab in the SSH section. In the Source port text box enter 3306. This is the port PuTTY will listen on on your local machine. It can be any standard Windows-permitted port. In the Destination field immediately below Source port enter 127.0.0.1:3306. This means, from the server, forward the connection to IP 127.0.0.1 port 3306. MySQL by default listens on port 3306 and we’re connecting directly back to the server itself, i.e. 127.0.0.1. Another common scenario is to connect with PuTTY to an outward-facing firewall and then your Destination might be the private IP address of the database server.

Putty Tunnel

Add the tunnel

Click the Add button and the screen should look like this,

Putty Tunnel Added

Save the session

Unfortunately PuTTY does not provide a handy ubiquitous Save button on all tabs so you have to return to the Session tab and click Save,

Putty Session

Open the session

Click Open (or press Enter), login, and enjoy!

Here for reference is an example connection using MySQL Adminstrator going to localhost: note the Server Host address of 127.0.0.1 which will be transparently forwarded.

Mysql Administrator Login

2,117 total views, 1 views today