I have a bunch of Linux machines that I wish to administer over the Internet. I currently use SSH keys, but have been advised to use 2-factor authentication. SSH Keys are something you know. Is an IP address something you have? (Yes, IP can be spoofed, but so can biometrics and so can atm cards).

Could I lock down SSH to only allow connections from my IP range and would that be considered 2-factor in conjunction with SSH keys?

  • 3
    Can it be? Sure. Should it be? That's another question.
    – Iszi
    Commented Mar 14, 2012 at 14:07
  • 5
  • 3
    This is a great question with PCI compliance implications since many organizations host their production environment elsewhere and would like to create a site-to-site IPSEC VPN between them. PCI requires two-factor for remote network access but if you accept the public IP address as a factor then the requirement is met.
    – freb
    Commented May 30, 2012 at 19:49
  • I use Google Authenticator PAM module for 2FA. It works nicely and it's very easy to setup.
    – ThoriumBR
    Commented Nov 26, 2015 at 11:20

10 Answers 10


I would think of an IP address as being "somewhere you are" rather than any of the traditional "something you know", "something you have" and "something you are" that are part of 3-factor authentication.

Although IP addresses are trivial to spoof, TCP connections are not and SSH is a protocol built on top of TCP. The IP address of a TCP connection is a reliable indicator of who you are directly connected to.

Let's say I limit SSH connections to just my office IP address, an attacker is going to have to do one of:

  1. Be in or near (if he cracks the wireless) my office
  2. Be on the path between my office and my server (say inside our ISP).
  3. Control a machine within my office.

Point 3. allows the attacker to be anywhere in the world but it increases the difficulty of an attack.

Points 1. and 2. significantly reduce the number of people who can successfully use the other factors (such as your SSH key or password) if they manage to acquire them and hence I see it as being worthwhile.

The quality of the IP address is a big factor here. I used my office as the example above but if you have a dynamic IP address, do you trust the entire range your ISP owns? How does that affect how easy it is for an attacker to get one of those IP addresses? Does the trustworthiness of an IP address change when you know there are 10 machines hidden by NAT behind it? What if there are 2,000 machines and 100 wireless access points?

I would not consider an IP address to be a factor on its own.

  • 4
    Great answer. However, be very careful how about where you take the origin of the IP address in say a web app (not ssh). E.g., if you read it from the X-Forwarded-For HTTP header in a web app (which is trivial header to forge even on a handshaked TCP connection) you have removed security.
    – dr jimbob
    Commented Mar 14, 2012 at 14:33

If done properly, it could be a somewhat useful addition to your security protocol. However, I'd be very hesitant about using it to replace a pre-existing factor in your authentication, as IP addresses are not secret information (you give it away to every website you visit) and depending on how/where you grab the IP address from, could be trivial to spoof. But if you use the IP address from a TCP connection in conjunction with say a stored secure http-only cookie, you could add some security. Specifically you'd invalidate the cookie whenever the IP address changes (which may change for benign reasons such as your ISP reassigning your IP) as well as malicious reasons (attacker got hold of your cookie).

As Ladadadada said, IP addresses in TCP connections aren't easily spoofed anymore. TCP requires a handshaking procedure to get a random 32-bit sequence number from the server before you can exchange information. If you forge a completely phony random IP address when starting the handshaking procedure, then the packets won't be routed to your computer through the internet, so you can't complete the handshake. Unless, that is you control intermediate routers at the ISP or a computer on one of the same local networks that could capture the packets routed to elsewhere, in which case you could forge random IP addresses.

However, if you design a web app and record the IP address, you have to be careful. Say you have a web app with two web servers (e.g., one for dynamic content/one for static), behind a load balancer, or other proxy. You may see by trial and error that the client's IP address is only present in the HTTP header X-Forwarded-For. However, this field is easy to change. For example, telnet www.whatismyip.org 80 and type the following with/without X-Forwarded-For the line (remember to press enter twice after the last line to indicate the end of your HTTP request).

GET / HTTP/1.1
Host: www.whatismyip.org

and you'll see that this web app thinks your IP address has changed to So be sure to test thoroughly. Overall, I think doing this yourself is more work than its worth, especially as it may frustrate users whose IP addresses change quite frequently.

EDIT: I realized after writing this that while I answered the title question ('can IP address be a component of 2 factor auth?"), but not the specific part referring to ssh management. I'd say ssh passphrase protected key is essentially two-factor auth: something you have (the ssh key), and something you know (the passphrase's key).


Typically 2 factor authentication refers to something you "know" and something you "have". The "know" is a password and "have" is ssh keys. These could be used the way you're using them now or on some sort of smart card or dongle (which sshd then accesses using the GSSAPI; see man sshd_config).

I think the person who asked you to use 2-factor authentication wants you to use keys and passwords (if someone steals your key it doesn't matter as they don't know the password either).

An IP address isn't really something you "own" because, as you've said, it can be spoofed. Same with MAC addresses. However, you can lock down sshd access to certain IP addresses/ranges anyway as a means of making harassing the ssh server more difficult. For example, running sshd on the default port on the internet will lead to lots of people attempting to brute force passwords etc.; restricting to IP addresses should aid with this as it requires more persistence and configuration to spoof the IP. Put a line similar to the following in /etc/hosts.deny


and this in /etc/hosts.allow


(the IP address/subnet mask above defines a range of addresses; it is just an example).

Always double check when making these sort of alterations as you don't want to accidentally lock yourself out of your server. Always leave a session logged in while you're testing (as these changes only affect new logins).

  • Maybe this should be a separate question - but isn't a SSH key and a SSH password both "something you know"? A physical key/token/fob would be "something you have", which as you mentioned could work by moving the key onto a card and using GSSAPI.
    – Mike
    Commented Mar 14, 2012 at 14:19
  • You can set ssh to allow you access only if you have the key and type in the password. You "have" the key on your computer and you are presenting it to the other side when authenticating. Smartcards et al. simply embed the key into an external device.
    – webtoe
    Commented Mar 14, 2012 at 14:26
  • 2
    You forgot to mention "something you are". Arguably, the IP address falls into this category.
    – Iszi
    Commented Mar 14, 2012 at 15:58
  • 3
    The aspect that makes the SSH key "something you know" and not "something you have" is that both you and the attacker can have it at the same time.
    – Ladadadada
    Commented Mar 14, 2012 at 17:45
  • The thing you "have" is the private key (the public key is put onto the server you're logging into). The attacker shouldn't have this part of the key pair; hence something you "have". It is the private key that would be on a dongle/card. Only the private key can sign things that can then be decoded using the public part of the pair (thus proving you are who you say you are). I believe I haven't got myself muddled here though I always have to think hard about the details of PKI.
    – webtoe
    Commented Mar 14, 2012 at 21:23

Technically yes, but adding a second factor that's trivial to forge doesn't increase your security by very much.

Assuming that you've been advised to use 2-factor because some sort of risk assessment suggested you needed stronger authentication, then you should be looking at better controls.

(Do the IP whitelisting too, though - it's not very strong but it'll only take a minute or two to do, so why not?)

The key thing is to remember that "2-factor" isn't a magic phrase that makes you secure. You need to understand the risk and implement appropriately strong controls.

  • 5
    You imply that an IP address is "trivial to forge". Are you referring to the risk of another computer on the same network having the ability, or the ability for someone at another location to forge? Commented Mar 14, 2012 at 14:25
  • @GeorgeBailey - Both...
    – Ramhound
    Commented Mar 14, 2012 at 17:59

Are the semantics relevant here? That you "have been advised to use 2-factor authentication" suggests that someone is expecting this from you - so doesn't it make more sense to find out from the person with the expectation what would be deemed acceptable?


No. You should not rely upon the IP address to provide much security. If someone connects over an open wireless network (say, from their smartphone, or from their laptop in a public coffee shop), then it is trivial to mount a man-in-the-middle attack or spoof their IP address. For those users, the IP address is not adding any security.

Therefore, if you were advised that you should use 2-factor authentication, you should not treat the client's IP address as a second factor. For some of your users, this will be basically useless.

I would say that it is fine to filter SSH connections to only allow those from a limited IP address range. This might increase somewhat. However, don't count it as a second factor! If you need two-factor authentication, use two real factors. Don't try to "pull a fast one" with a fake second factor.

Let me tell you a little story about another industry segment which pulled a fast one with 2-factor authentication. Several years ago, US banking regulators passed a regulation requiring all US banks to use two-factor authentication for online banking. A plausible requirement, especially if you're concerned about phishing attacks to steal people's banking passwords. But then banks went and got "clever" (and I don't mean that in a good way) about how they implemented the requirement. They decided that your online banking password would be the first factor (fine so far) and a persistent cookie on your machine would be the second factor (well, plausible). But how did they get the persistent cookie on your machine? Well, if you don't have the cookie, they ask you your challenge question, and if you can provide the correct answer, they give you the cookie. So in the end their two factors are: (1) a password, and (2) another password (the answer to your challenge question). This defeats the purpose of two-factor authentication. For instance, a phisher can just ask for both passwords. And indeed, some studies have found that this form of two-password authentication is no more secure against phishing than one-password authentication. So don't be like the banks. Don't treat 2-factor authentication as something you can game, because then you will negate its security benefits.


In a sense, yes. But it's more a matter of semantics rather than security.

In a certain sense, an IP address could be considered "something you are" or "something you have"; that is, if access is restricted to only a limited set of IP addresses, then an attacker would have to "be" or "have" one of those IP addresses in order to perpetrate an attack -- how that would happen depends on the scenario and technology, but it certainly will dramatically decrease your attack surface.

The semantics comes as part of the argument as to whether this counts as a second factor, or whether it's just a really good additional piece of security. Technically you are not your IP address nor it it really yours; someone else can assume control of it depending on network structure. But the same goes for any other piece of authentication technology -- it's all up to the implementation.

The only time it really matters whether or not it counts as a second factor is in the context of some sort of process audit or larger framework, in which case qualifying factors should be listed. Otherwise, it's just nerds arguing.

I would say that requiring a password plus imposing an IP restriction is very reasonable security, as long as the appropriate policies are strictly followed. It's certainly better than just the password alone.


You shouldn't use IP address as an authentication factor. It's easy to spoof an IP address instead of cracking other means like biometric. A script kiddie can do it easily.

How can you deal with IP address changes unintentionally like using VPN? There are a lot of solutions for using SSH two factor authentication. You can just Google them.

  • 4
    How easy are we talking here? If it is TCP, they still have to have the response packets routed back to them and not the real IP address holder. Commented Mar 14, 2012 at 15:56
  • @rox0r - its a trival task to spoof an ip address.
    – Ramhound
    Commented Mar 14, 2012 at 18:00
  • 2
    @Ramhound: its not trivial to spoof an arbitrary IP address and establish TCP connection (esp for ssh with IP address based firewall). You'd need to be able to intercept/reroute packets between the two IP addresses somehow to complete a TCP handshake to your machine. If you control machines at the ISP of legitimate IP/server or are on the legitimate IP/server's local network, its doable (I wouldn't say trivial though).
    – dr jimbob
    Commented Mar 14, 2012 at 19:29
  • 3
    @Ramhound it's trivial to spoof an IP if you're just broadcasting traffic outbound, but if you're going to establish two-way communication, then it falls apart. The return traffic needs to find its way back to you, and that can't happen if you're spoofing an IP that's routed to somewhere else.
    – tylerl
    Commented Mar 16, 2012 at 8:40
  • 1
    I think you need to backup your claim that it is easy to spoof an IP.
    – schroeder
    Commented Nov 26, 2015 at 16:04

IP would just be way too easy to spoof or even guess based on a subnet. Only so many options there. I wouldn't consider it useful. There are a lot of other 2-factor systems you can use that are simple and work. Look at LinOTP and OpenOTP.

Another option is to restrict access to only machines that use a smart card or have another form of 2-factor already enabled.

  • 3
    It's not trivial to spoof a TCP connection, as TCP handshake forces you to have ownership of the IP in question. If you somehow could usurp ownership of the IP (e.g. manipulate routing tables in the ISP or any intermediary) then it could be possible, but very unlikely.
    – Mike
    Commented Apr 29, 2014 at 7:15

Some practical answer that you may, or may not believe.

I once worked for a company that made a minor site for MasterCard. Mind you, it was not anything very security related, no CC numbers, no transactions. A small contest with small prices. But this means the site had a log-on mechanism and some personal information (login, email, maybe even postal address). The MC procedures mandated some form of 2FA for the production servers' management and IP based filtering, limited to 1 IP address (gateway from the building) was considered enough. On the other hand the site was such a low-value one they haven't bothered to actually verify what we said, they've taken our word for it. But including the IP filter as 2FA was their idea, they've explicitly asked for it, we haven't really thought then to include is as part of 2FA.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .