Difference between pages "IPv6 Networking" and "OpenSSH Key Management, Part 3"

(Difference between pages)
(Stateful vs stateless)
 
(Created page with "{{Article |Subtitle=Agent Forwarding |Summary=In this third article in a series, Daniel Robbins shows you how to take advantage of OpenSSH agent connection forwarding to enhan...")
 
Line 1: Line 1:
= Introduction =
+
{{Article
 +
|Subtitle=Agent Forwarding
 +
|Summary=In this third article in a series, Daniel Robbins shows you how to take advantage of OpenSSH agent connection forwarding to enhance security. He also shares recent improvements to the keychain shell script.
 +
|Author=Drobbins
 +
|Previous in Series=OpenSSH Key Management, Part 2
 +
}}
 +
Many of us use the excellent OpenSSH as a secure, encrypted replacement for the venerable telnet and rsh commands. One of OpenSSH's more intriguing features is its ability to authenticate users using the RSA and DSA authentication protocols, which are based on a pair of complementary numerical "keys." One of the main appeals of RSA and DSA authentication is the promise of being able to establish connections to remote systems without supplying a password. For more background, see the previous installments of this series on OpenSSH key management, which cover RSA/DSA authentication (Part 1) and ssh-agent and keychain (Part 2), respectively.
  
[[wikipedia:IPv6|IPv6]] is an redesigned and improved version of the IPv4 protocol, and is intended to start replacing IPv4 in 2011 and beyond as the [[wikipedia:IPv4_address_exhaustion|IPv4 global address space becomes exhausted]]. IPv6 includes a number of improvements over IPv4, including most notably 128-bit addressing, simplified protocol header, integrated IPSec and Multicast implementations, improved discovery, flexibility and router interaction, and improved facilities for auto-configuration. IPv6 also marks the end of [[wikipedia:Network_address_translation|Network Address Translation]] (NAT), which is not recommended or necessary with IPv6. While it's possible to use non-routable addresses with IPv6, this is not a requirement and it is possible for any IPv6 device to have its own globally routable IP address if desired.
+
Since Part 2 was published on developerWorks in September 2001, and later referenced on Slashdot and Freshmeat (see Resources later in this article for links to these sites), a lot of people have started using keychain, and it's undergone a lot of changes. I've received approximately 20 or so high-quality patches from developers around the world. I've incorporated many of these patches into the keychain source, which is now at version 1.8 (see Resources). I send my sincere thanks to all those who submitted patches, bug reports, feature requests, and notes of appreciation.
  
== Addressing ==
+
=== Tightening ssh security ===
  
IPv6 addresses consist of 128 bits. The first 64 bits are used for the network and subnet portion of the address, while the remaining 64 bits are used for the host portion of the address. For more information on how to represent IPv6 addresses, please see the Presentation section of the [[wikipedia:IPv6_address|IPv6 address]] page on Wikipedia.  
+
In my last article, I've spent some time discussing the security benefits and tradeoffs of running ssh-agent. A few days after the second article appeared on developerWorks, I received an e-mail from Charles Karney of Sarnoff Corporation, who politely informed me of OpenSSH's new authentication agent forwarding abilities, which we'll take a look at in a bit. In addition, Charles emphasized that running ssh-agent on untrusted machines is quite dangerous: if someone manages to get root access on the system, then your decrypted keys can be extracted from ssh-agent. Even though extracting the keys would be somewhat difficult, it is within the skill of professional crackers. And the mere fact that private key theft is possible means that we should take steps to guard against it happening in the first place.
  
=== Network Masks ===
+
To formulate a strategy to protect our private keys, we must first put the machines we access into one of two categories. If a particular host is well-secured or isolated -- making successful root exploit against it quite unlikely -- then that machine should be considered a trusted host. If, however, a machine is used by many other people or you have some doubts about the security of the system, then the machine should be considered an untrusted host. To guard your private keys against extraction, ssh-agent (and thus keychain) should never be run on an untrusted host. That way, even if the system's security is compromised, there will be no ssh-agent around for the intruder to extract keys from in the first place.
  
IPv6 addresses also have an associated network mask, which is typically written as a trailing "/64" or "/48" at the end of the address, which specifies what bits of the address are used for network and subnet parts. For example, a "/48" mask specifies that addresses use a 48-bit network part, followed by a 16-bit subnet part (allowing for 2^16 subnets), followed by a 64-bit host part (allowing for up to 2<sup>64</sup> hosts for each of the 2<sup>16</sup> subnets to be specified.) In contrast, a "/64" mask specifies that addresses use a 64-bit network part, no subnet part, and a 64-bit host part (allowing up to 2<sup>64</sup> hosts total to be specified.) This means that if you are issued a "/64" set of addresses, you will not be able to define any subnets, but if you are issued a "/48" set of addresses, you will be able to define up to 2<sup>16</sup> subnets.
+
However, this creates a problem. If you can't run ssh-agent on untrusted hosts, then how do you establish secure, passwordless ssh connections from these systems? The answer is to only use ssh-agent and keychain on trusted hosts, and to use OpenSSH's new authentication forwarding abilities to extend passwordless authentication to any untrusted hosts. In a nutshell, authentication forwarding works by allowing remote ssh sessions to contact an ssh-agent running on a trusted system.
  
=== Address Space and Security ===
+
=== Authentication agent forwarding ===
  
IPv6 also uses a global, flat address space. IPv6 is designed so that any device that needs to communicate on the Internet is able to have a unique globally-routable address. With IPv6, there is no need for using [[wikipedia:Network_address_translation|Network Address Translation]] (NAT). With IPv4, NAT is often used as a means of protecting systems from being accessed by malicious users. With IPv6, firewalls are typically used instead of NAT for restricting access to systems. With IPv6, it is normal for all machines on your home network to have "globally routable" addresses, the equivalent of a "public IP" in the world of IPv4. It is important to understand that this is the way that IPv6 is intended to be used for the majority of users, and that an IPv6-enabled router will no longer be performing NAT for you.
+
To get an idea of how authentication forwarding works, let's first take a look at a hypothetical situation where user drobbins has a trusted laptop called lappy, a trusted server called trustbox, and two other untrusted systems that he must access, called notrust1 and notrust2, respectively. Currently, he uses ssh-agent along with keychain on all four machines, as follows:
  
=== Using IPv6 ===
+
[[FIle:l-ssh-3.jpg|center|frame|ssh-agent running on trusted and untrusted machines]]
  
There are several ways to use IPv6 with Funtoo Linux. Here are some possibilities:
+
The problem with this approach is that if someone gains root access on notrust1 or notrust2, then it is of course possible for this person to extract keys from the now vulnerable ssh-agent process. To fix this, drobbins stops running ssh-agent and keychain on untrusted hosts notrust1 and notrust2. In fact, to be even more careful, drobbins decides to only use ssh-agent and keychain on lappy. This limits exposure of his decrypted private keys, protecting him against private key theft:
  
* Participating in an existing IPv6 network
+
[[File:l-ssh-4.jpg|center|frame|ssh-agent running only on lappy; a more secure configuration]]
* Creating a local IPv6 over IPv4 tunnel
+
* Enabling IPv6 on your router, possibly via a tunnel (several ISP uses '''6rd'''...)
+
* Unique Local IPv6 Unicast Addresses (site local)
+
  
==== Participating in IPv6 Network ====
+
Of course, the problem with this approach is that drobbins can now only establish passwordless connections from lappy. Let's see how to enable authentication forwarding and get around this problem.
  
The first approach is an option if your Funtoo Linux system happens to be on an IPv6 network, or you desire to set up an IPv6 network. In this case, the Funtoo Linux system simply needs to be configured to participate in this IPv6 network -- and can also participate in an IPv4 network simultaneously. If you will be configuring an IPv6-compatible router, then you will simply configure your Funtoo Linux system to participate in this network.
+
Assuming that all machines are running recent versions of OpenSSH, we can get around this problem by using authentication forwarding. Authentication forwarding allows remote ssh processes to contact the ssh-agent that is running on your local trusted machine -- rather than requiring a version of ssh-agent to be running on the same machine that you are sshing out from. This usually allows you to run ssh-agent (and keychain) on a single machine, and means that all ssh connections that originate (either directly or indirectly) from this machine will use your local ssh-agent.
  
==== Local IPv6 over IPv4 Tunnel ====
+
To enable authentication forwarding, we add the following line to lappy and trustbox's /etc/ssh/ssh_config. Note that this is the config file for ssh (ssh_config), not the ssh daemon sshd (sshd_config):
  
Another approach for using IPv6 is to configure an IPv6 over IPv4 tunnel locally on your Funtoo Linux system, in cooperation with a tunnel provider. This will allow you to use an existing IPv4 network to connect a single Funtoo Linux system to IPv6. It is also possible to configure this system to serve as an IPv6 router.
+
{{file|name=ssh_config|body=
 +
ForwardAgent Yes
 +
}}
  
==== Enabling IPv6 on Your Router ====
+
Now, to take advantage of authentication forwarding, drobbins can connect from lappy to trustbox, and then from trustbox to notrust1 without supplying passphrases for any of the connections. Both ssh processes "tap in" to the ssh-agent running on lappy:
  
If you have a router that is capable of supporting IPv6, then it is possible to configure your router so that an IPv6 network is available, at which point you can simply configure your Funtoo Linux system to participate in it. Note that many popular home/office routers can be configured to use an IPv6 over IPv4 tunnel, which provides a convenient option for home networks or smaller organizations to participate in IPv6. Using this approach, your computer systems behind the router are simply configured to participate in an IPv6 network, and your router handles tunneling the IPv6 traffic back and forth between your tunnel provider. This is typically the most flexible option for exploring IPv6 as it allows you to have multiple computer systems in your home or office to participate in an IPv6 network while your router takes care of everything transparently.
 
 
==== Using Unique Local IPv6 Unicast Addresses ====
 
 
If you don't have public IPv6 connectivity or you don't wish to open an IPv6 tunnel over an IPv4 network, you can use a mechanism similar to IPv4 private addresses ranges. This mechanism consists of concatenating the prefix FC00::/7 with a globally unique identifier and a subnet identifier to form the upper 64 bits of the IPv6 address. Details of the mechanisms to forge a unique local IPv6 unicast address are documented in [http://tools.ietf.org/html/rfc4193 RFC 4193], however unique local IPv6 unicast addresses are made of the following components:
 
 
<pre>
 
      | 7 bits |1|  40 bits  |  16 bits  |          64 bits          |
 
      +--------+-+------------+-----------+----------------------------+
 
      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
 
      +--------+-+------------+-----------+----------------------------+
 
</pre>
 
 
* Prefix (7 bits): always FC00::/7
 
* L (1 bits): must be set to 1 (1 = prefix is locally assigned, 0 is undefined so far and must not be used)
 
* Global ID: A random identifier (see [http://tools.ietf.org/html/rfc4193 RFC 4193] for details about the generation algorithm
 
* Interface ID: Host interface ID as defined in [http://tools.ietf.org/html/rfc3513 RFC 3513]
 
 
{{fancynote|Just like with private IPv4 addresses, an IPv6 router must not route a unique local IPv6 unicast address outside the organization local network.}}
 
 
==== ICMPv6 ====
 
 
Some network administrators are pretty aggressive with ICMP filtering on their networks. Don't misunderstand us: ICMP is an integral part of the TCP/IP protocol stack and a necessary gear for its correct operation. ICMP messages are even more fundamental in IPv6 because some TCP/IP core mechanisms like have been replaced by ICMPv6 messages: ARP is no longer in use in an IPv6 world, instead a set of of ICMPv6 messages have been created to assume the same functionality (''Neighbor Discovery Protocol'' or ''NDP'').  Also no fragmentation can be done in IPv6 and blocking ICMPv6 messages like ''Packet too big'' is not a good idea. In general: '''do not block any other ICMPv6 messages than ''echo request'' and ''echo reply'' '''.
 
 
=== Stateful vs stateless ===
 
 
There are several ways to assign IPv6 addresses on a network :
 
* Stateful: a DHCPv6 server is responsible of leasing and following all assigned IPv6 addresses. It works the same way of the well known traditional DHCP with some minor variations but the idea beneath is exactly the same.
 
* Stateless: Nothing leases or tracks assigned IPv6 addresses on the network. Instead, machines use either an IPv6 address manually entered by the network administrator either a combo of Router Advertisement messages with a magic calculation of their network adapter's MAC address (EUI-64).
 
 
= Requirements =
 
 
IPv6 requires CONFIG_IPV6 to be enabled in your kernel (either compiled in or as a module). If compiled as a module (e.g. if your kernel was compiled by genkernel), ensure the module is loaded.
 
 
<console>
 
<console>
###i## lsmod | grep ipv6
+
$ ##i##ssh drobbins@trustbox
</console>
+
Last login: Wed Sep 26 13:42:08 2001 from lappy
  
If this returns nothing, load the module with:
+
Welcome to trustbox!
<console>
+
$ ##i##ssh drobbins@notrust1
###i## modprobe ipv6
+
Last login: Tue Sep 25 12:03:40 2001 from trustbox
</console>
+
  
= Commands =
+
Welcome to notrust1!
 
+
$
; ping6
+
: IPv6 ping command
+
; route -6
+
: show IPv6 routes
+
; ip -6 neigh show
+
: show all IPv6 neighbors on the local LAN
+
 
+
= Configuration =
+
 
+
== Participating in an Existing IPv6 Network ==
+
 
+
If your local network already supports IPv6, then you can simply configure Funtoo Linux to participate in this IPv6 network. Here is a sample configuration that might be used to configure an ethernet interface (netif.eth0) to participate in both an IPv4 and IPv6 network:
+
 
+
{{File
+
|/etc/netif.d/netif.eth0|<pre>
+
template="interface"
+
ipaddr="10.0.1.200/24 2001:470:d:c2c:218:51ff:feea:ee21/64"
+
gateway="10.0.1.1"
+
nameservers="10.0.1.1 2001:470:20::2"
+
domain="funtoo.org"
+
multicast="yes"
+
routes="2000::/3 via fe80::daa2:5eff:fe7a:83de dev eth0"
+
</pre>}}
+
 
+
Above, we use the <tt>interface</tt> template, and specify both an IPv4 and IPv6 address (with network mask) for <tt>ipaddr</tt>. In addition, an IPv4 and IPv6 nameserver is specified. For routing, we use the <tt>gateway</tt> command to specify an IPv4 gateway, while we use the <tt>routes</tt> command to specify a route to our router, which in this case has address <tt>fe80::daa2:5eff:fe7a:83de</tt> and is reachable on device eth0.
+
 
+
Note that we specify a route for "2000::/3" rather than "::/0" or "default", and this is a bit unusual. This is to work around a bug in many Linux kernels that prevents the default route from being handled properly. "2000::/3" maps to all routable IP addresses and has the benefit of being compatible with all Linux kernels.
+
 
+
=== Many Addresses and Stateless Autoconfiguration ===
+
 
+
Also note that if we did not specify an IPv6 address in the <tt>ipaddr</tt> variable, then eth0 would still get at least one IPv6 address anyway. First, it would get a link-local address, starting in <tt>fe80::/16</tt>, and it would also automatically use ''stateless autoconfiguration'' to grab an unused IPv6 address from the range used by your IPv6 router. This works similarly to the way a DHCP client works with IPv4, but is built-in to the IPv6 protocol and does not require a DHCP server to function. It works because with IPv6, routers send out ICMP packets to advertise themselves to systems on your network, and your Funtoo Linux system can use this information to automatically grab an unused address. It is important to understand this behavior because it means that by default, your Funtoo Linux system will grab a globally-routable ("public") IPv6 address from your router with no steps necessary on your part and thus may be accessible from the Internet if no firewall is in place. However, in most cases the default IPv6 route must be specified in the <tt>routes</tt> variable for IPv6 to function properly, so this auto-configuration isn't completely automatic at this time.
+
 
+
== Local IPv6 over IPv4 Tunnelling ==
+
 
+
Tunnelling is the process of encapsulating IPv6 packets within an IPv4 packet so that it can be transmitted over an IPv4 network. This process happens at a local ''tunnel entry point'', which can be a Linux machine or a router, such as an Apple AirPort. The packet then traverses the IPv4 network, until reaches the ''tunnel endpoint'', which ''de-encapsulates'' the packet and places it on an IPv6 network. There are several different types of IPv6 tunnels. There are also several IPv6 tunnel providers that offer free tunnelling services, making it convenient to start using IPv6, even on your home network.
+
 
+
Note that if you want configure an IPv6 over IPv4 tunnel on your router, such as an Apple AirPort, then you will simply need to sign up with one of the tunnel providers and use their instructions to configure your router. At this point, your router will be IPv6 enabled and you can then configure your Funtoo Linux system to participate in an existing IPv6 network using the instructions in the previous section. If this is not an option for you, then it is also possible to set up the IPv6 over IPv4 tunnel directly on your Funtoo Linux system. This means that only your Funtoo Linux system will be able to participate in IPv6, at least to start (later, you could configure your Funtoo Linux system to route IPv6 for other machines on your network) Follow the instructions in this section to set up local tunneling on your Funtoo Linux system.
+
 
+
=== Tunnel providers ===
+
; [http://gogonet.gogo6.com/page/freenet6-tunnelbroker freenet6]
+
: Supports anonymous tunnels and works behind NAT. You can connect to with your login or as anonymous from anywhere. This can be configured under Funtoo Linux by emerging the '''net-misc/gogoc''' ebuild.
+
; [http://tunnelbroker.net/ Hurricane Electric]
+
: Configured '''6in4''' tunnel, with support for dynamic IPv4 addresses, and Apple AirPorts can be configured to use this tunnel - see [http://www.nedprod.com/Niall_stuff/addingIPv6toyourhome.html this link]. Also see [http://ipv6.he.net/certification/faq.php ipv6.he.net FAQ] You can setup this tunnel with ifconfig and iproute2, or configure your router to be the tunnel entry point  -- the point at which IPv6 traffic is encapsulated/de-encapsulated.
+
; [http://en.wikipedia.org/wiki/Teredo_tunneling Teredo]/[http://www.remlab.net/miredo/ Miredo]
+
: [http://tools.ietf.org/html/rfc4380 RFC4380] mandated transition mechanism. Works behind NAT. Assigns one "/128" per host.
+
 
+
=== Getting Started with gogoc ===
+
 
+
Freenet6 is a free IPv6 access service provided by gogo6 via the [http://en.wikipedia.org/wiki/Tunnel_Setup_Protocol TSP tunnelling protocol].
+
<code>gogoc</code> supports any TSP tunnel; perhaps one is provided by your ISP. We will focus on an anonymous tunnel via freenet6.
+
 
+
You need ipv6 to be enabled in your kernel as well as the TUN module.
+
 
+
You can quickly get started by emerging {{Package|net-misc/gogoc}}, adding <code>gogoc</code> to your startup scripts and starting it.
+
{{Package|net-misc/gogoc}} is currently keyworded unstable (on some architectures, see [https://bugs.gentoo.org/362549 gentoo bug #362549]). If you are running stable Funtoo, you may want to put an entry into your package.keywords/package.accept_keywords file.
+
<console>
+
###i## emerge gogoc
+
###i## bzcat /usr/share/doc/gogoc-*/gogoc.conf.sample.bz2 >/etc/gogoc/gogoc.conf
+
###i## rc-update add gogoc default
+
###i## /etc/init.d/gogoc start
+
 
</console>
 
</console>
  
{{Note}}By default, <code>gogoc</code> will use an anonymous tunnel. If you wish to authenticate yourself, read and edit <code>/etc/gogoc/gogoc.conf</code>.
+
If you try a similar configuration and find that agent forwarding isn't working, try using ssh -A instead of plain old ssh to explicitly enable authentication forwarding. Here's a diagram of what went on behind the scenes when we logged in to trustbox and notrust1 using authentication forwarding, above:
 
+
=== Getting started with Teredo ===
+
 
+
While this mechanism is officially called Teredo, the implementation of the Teredo service we will be using is called Miredo.
+
{{Note}}{{Package|net-misc/miredo}} is currently keyworded unstable. If you are running stable Funtoo, you may want to put an entry into your package.keywords/package.accept_keywords file.}}
+
 
+
Emerge <tt>net-misc/miredo</tt> and start it up (you can add it to your default runlevel if you wish):
+
<console>
+
###i## emerge net-misc/miredo
+
###i## /etc/init.d/miredo start
+
</console>
+
 
+
{{Note}}Miredo requires <code>CONFIG_TUN</code> enabled in your kernel. If it is compiled as a module, ensure the <tt>tun</tt> module is loaded.
+
 
+
If all goes well, you can check the assignment of an IPv6 address using <tt>/sbin/ip</tt>, for example:
+
<console>
+
###i## /sbin/ip addr show dev teredo
+
4: teredo: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
+
    link/none
+
    inet6 2001:0:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/32 scope global
+
      valid_lft forever preferred_lft forever
+
    inet6 fe80::ffff:ffff:ffff/64 scope link
+
      valid_lft forever preferred_lft forever
+
</console>
+
 
+
=== Tunnelling 6to4 ===
+
 
+
6to4 is an Internet transition mechanism for migrating from IPv4 to IPv6, a system that allows IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet) without the need to configure explicit tunnels.
+
When using 6to4 your IPv6 golablly addressable IP is generated from you IPv4 IP address.
+
 
+
The anycast address of 192.88.99.1 has been allocated for the purpose of sending packets to a 6to4 relay router. Note that when converted to a 6to4 IPv6 address with the subnet and hosts fields set to zero this IPv4 address (192.88.99.1) becomes the IPv6 address 2002:c058:6301::.
+
 
+
To use the funtoo network template method, write the config file for the interface /etc/conf.d/netif.6to4 (which will also handle the converting of your IPv4 address to your IPv6 address). Make sure you change "WAN" to your correct internet facing interface.
+
<pre>
+
template=ipv6-tunnel
+
WAN="eth0"
+
MTU="1280"
+
ipv4=`ifconfig $WAN | sed -ne 's/[[:space:]]*inet addr:\([0-9.]*\).*/\1/p'`
+
ipv6=`printf "2002:%02x%02x:%02x%02x::1" \`echo $ipv4 | tr "." " "\``
+
remote=192.88.99.1
+
local="$ipv4/24"
+
ipaddr="$ipv6/48"
+
routes="2000::/3 via 2002:c058:6301:: dev $WAN"
+
</pre>
+
 
+
Then create the netif.6to4 symlink and add it to the default runlevel
+
<console>
+
###i## ln -s /etc/init.d/netif.tmpl /etc/init.d/netif.6to4
+
###i## rc-update add netif.6to4 default
+
###i## /etc/init.d/netif.6to4 start
+
</console>
+
 
+
You should now be capable of connecting via IPv6:
+
<console>
+
###i## ping6 ipv6.google.com
+
</console>
+
 
+
To allow this host to be a router, a modified template is required:
+
{{File
+
|/etc/netif.d/ipv6-tunnel|<pre>
+
#!/bin/sh
+
 
+
netif_pre_up() {
+
        require local remote
+
        try ip tunnel add $interface mode sit remote $remote local $local ttl 255
+
        try ip addr add $ipaddr dev $interface
+
        try ip addr add $ipaddr4 dev $interface
+
}
+
 
+
netif_post_up() {
+
        try ip route add ::/0 dev $interface
+
}
+
 
+
netif_pre_down() {
+
        ip route del ::/0 dev $interface
+
}
+
 
+
netif_post_down() {
+
        ip tunnel del $interface
+
}
+
</pre>}}
+
 
+
Then add the following line to <tt>/etc/conf.d/netif.6to4</tt>:
+
{{File
+
|/etc/conf.d/netif.6to4|<pre>
+
ipaddr4="$ipv4/24"
+
</pre>}}
+
 
+
After restarting the 6to4 interface radvd can be started:
+
<console>
+
###i## /etc/init.d/netif.6to4 restart
+
###i## /etc/init.d/radvd start
+
</console>
+
 
+
== Optimization ==
+
 
+
=== Prefer IPv4 over IPv6 ===
+
  
Generally if your IPv6 connection is through a tunnel, it will be slower than an IPv4 connection. For this reason, if you are using an IPv6 tunnel, it can be best to configure your systems to ''prefer'' IPv4 if an IPv4 version of the site is available, and use IPv6 only when necessary. This way, you will avoid unnecessary encapsulation and de-encapsulation of IPv4 traffic. Here's how to do this for a number of operating systems:
+
[[File:l-ssh-5.jpg|frame|center|Agent forwarding in action]]
  
==== Linux ====
+
As you can see, when ssh connected to trustbox, it maintained a connection to the ssh-agent running on lappy. When an ssh connection was made from trustbox to notrust1, this new ssh process maintained the authentication connection to the previous ssh, effectively extending the chain. Whether this authentication chain can be extended beyond notrust1 to other hosts depends on how notrust1's /etc/ssh/ssh_config is configured. As long as agent forwarding is enabled, all parts of the chain will be able to authenticate using the ssh-agent running on the trusted lappy.
  
Linux will prefer IPv6 if IPv6 support is enabled in the kernel. To prefer IPv4, edit <tt>/etc/gai.conf</tt> and add this line:
+
=== Advantages of agent connection forwarding ===
{{File
+
|/etc/gai.conf|<pre>
+
precedence ::ffff:0:0/96 100
+
</pre>}}
+
  
==== Windows 7, Server 2008, Vista ====
+
Authentication forwarding offers a number of security advantages not touched on here. To convince me of the importance of agent connection forwarding, Charles Karney shared with me these three security advantages:
  
These operating systems prefer IPv6 by default. See [http://msdn.microsoft.com/en-us/library/bb756941.aspx this link]. To prefer IPv4, use the following steps:
+
The private key is stored only on the trusted machine. This prevents malicious users from grabbing your encrypted key from disk and attempting to crack the encryption.
 +
ssh-agent runs only on the trusted machine. This prevents an intruder from doing a memory dump of a remote ssh-agent process and then extracting your decrypted private keys from the dump.
  
# Start <tt>regedit</tt>.
+
Since you only need to type in the passphrase on your trusted machine, you prevent any keystroke loggers from stealthily grabbing your passphrase as it is entered.
# Navigate to <tt>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP6\Parameters</tt>.
+
The one drawback to relying on authentication agent connection forwarding is that it doesn't solve the problem of allowing cron jobs to take advantage of RSA/DSA authentication. One solution to this problem is to set up all cron jobs that need RSA/DSA authentication so that they execute from a trusted machine on your LAN. If necessary, these cron jobs can use ssh to connect to remote systems to automate backups, synchronize files, and so on.
# Create a new DWORD named <tt>DisabledComponents</tt>. Edit this new DWORD and set it to HEX value of <tt>20</tt> or a DECIMAL value of <tt>32</tt>.
+
# Restart your computer.
+
  
== ISPs who currently have IPv6 enabled for residential customers ==
+
Now that we've looked at authentication agent connection forwarding, let's turn to recent improvements made to the keychain script itself.
  
* Canada:
+
=== Keychain functionality improvements ===
** '''Videotron''': Videotron has a [http://support.videotron.com/residential/internet/ipv6/videotron-ipv6 beta-program] for residential customers who want to test IPv6 (no official technical support, it is possible they don't have enabled it in your area so check first before investing in new hardware). Although  at date of writing, a large part of their networks are IPv6, '''you must go through a 6rd tunnel''' because they still need to upgrade some of their equipments and '''your router must support the 6rd protocol''' (this requirement is documented). Videotron sells you a D-Link DIR-825 with a modified firmware however this model has a weird gotcha: it does not support IPv6 firewalling.''' This is not a Videotron specific issue''' (even the genuine firmwares coming  from the manufacturer has no support for IPv6 firewalling as of June 2011). A good alternative to recommend is the CISCO/LinkSYS E4200, more expensive (MSRP ~$180 US/CDN) but has IPv6 firewalling support.  Once the E4200 firmware has been upgraded go in Setup/IPv6 Setup disable "IPv6 - Automatic" (you should then see an IPv6 address in the DUID field) and leave "automatic" for the 6rd configuration. You should be in business and see all of the hosts on your network with an IPv6 stack enabled being assigned a public IPv6 address starting with 2607:f048.
+
** '''Teksavvy''' : TekSavvy has a [http://teksavvy.com/ipv6 IPv6 beta-program] for residential customers who use their DSL service (no statement found for cable connections). Just ask them to enable IPv6 to your subscription and it should be available within the next 24 hours. Their IPv6 connectivity is native so you don't need to setup a tunnel.
+
** '''Shaw''' (?)
+
** '''Cogeco cable''' (?)
+
** '''Telus''' (?)
+
** '''Bell''' : Bell appears to have an official IPv6 support especially for its business subscribers (See http://ipv6.bell.ca) via a toolkit and various web pages on the subject.
+
  
* France
+
Since the time this article was originally written in 2001, Keychain has become a successful Open Source project, and now supports nearly every version of UNIX (including Linux, BSD, Solaris, IRIX, and AIX as well as other UNIX platforms,) and has lots of advanced features. These features include support for gpg-agent, as well as a number of new command-line options, which you can learn about by typing {{c|keychain --help}} or reading the keychain man page ({{c|man keychain}}).
** '''Free'''
+
** '''Nerim'''
+
** '''the French Data Network (FDN)'''
+
* United States:
+
** '''Comcast''' (limited pilot in some areas only)
+
  
== Home routers compatible with IPv6 ==
+
The official home for Keychain is on the [[Keychain]] page on the Funtoo wiki. Check there for updates and more information on this useful tool.
  
A few residential routers have support for IPv6 at date of writing and many more home networking devices will have robust IPv6 support in a more or less near futures. The following does not pretend to be exhaustive:
+
=== Conclusion ===
* '''D-Link DIR-825 rev. 1B''' (June 2011): Has IPv6 support out of the box, however for somewhat reason the router has no support for IPv6 firewalling even with teh 2.05N revision of the firmware. Consequence for you is you have to deploy an IPv6 firewall on each of hosts concerned with a public IPv6 connectivity. The canadian ISP Videotron is selling a DIR-825 with a customized firmware as unfortunately, like with the genuine manufacturer firmware, no IPv6 firewalling possible :( .
+
* '''CISCO/LinkSys E4200''' (June 2011): Advertised as being IPv6 compatible with a firmware update (available as of June 14th 2011 -> check for the version tagged 1.0.02 build 13 or later on the manufacturer website). The device supports native IPv6 and IPv6 through a 6rd tunnel (no support for any other tunneling protocol).
+
  
== Resources ==
+
This column concludes my coverage of OpenSSH. Hopefully, you've learned enough about it to start using OpenSSH in an effective way to secure your systems.  
*[http://ipv6.he.net/certification/cert-main.php free ipv6 certification program]
+
{{ArticleFooter}}
*[http://ipv6-test.com/ Test ipv6 (ipv6-test.com)]
+
*[http://test-ipv6.com/ Test ipv6 (test-ipv6.com)]
+
*[http://www.comcast6.net/ Comcast's IPv6 page]
+
*[http://tunnelbroker.net/ Hurricane Electric Tunnel Broker ]
+
*[http://www.gentoo-wiki.info/HOWTO_IPv6 Gentoo Wiki IPv6 ]
+
*[http://www.gentoo.org/doc/en/ipv6.xml Gentoo IPv6 Guide]
+
with Apple airport extreme, etc:
+
*[http://www.tunnelbroker.net/forums/index.php?topic=680.0 tunnelbroker.net forums post - airport config ]
+
*[http://www.nedprod.com/Niall_stuff/addingIPv6toyourhome.html Adding IPv6 Support To Your Home]
+
*[http://www.tunnelbroker.net/forums/index.php?topic=273.0 tunnelbroker.net forums post - Gentoo config (won't work in Funtoo)]
+
Nice Overview over IPv6
+
* [http://www.linux.com/learn/tutorials/428331-ipv6-crash-course-for-linux IPv6 Crash Course for Linux] and page 2 [http://www.linux.com/learn/tutorials/432537:another-ipv6-crash-course-for-linux-real-ipv6-addresses-routing-name-services IPv6 Crash Course for routing name services]
+
* [http://livre.g6.asso.fr/index.php/Accueil IPv6 Théorie et Pratique (in french only)] revised online version of the O'Reilly book published in 2005 by a collective researchers and IT actors.
+
[[Category:HOWTO]]
+
[[Category:Networking]]
+
[[Category:Featured]]
+

Revision as of 01:00, January 2, 2015

Agent Forwarding

In this third article in a series, Daniel Robbins shows you how to take advantage of OpenSSH agent connection forwarding to enhance security. He also shares recent improvements to the keychain shell script.


Previous in series: OpenSSH Key Management, Part 2

Support Funtoo and help us grow! Donate $15 per month and get a free SSD-based Funtoo Virtual Container. 5 spots left.

Many of us use the excellent OpenSSH as a secure, encrypted replacement for the venerable telnet and rsh commands. One of OpenSSH's more intriguing features is its ability to authenticate users using the RSA and DSA authentication protocols, which are based on a pair of complementary numerical "keys." One of the main appeals of RSA and DSA authentication is the promise of being able to establish connections to remote systems without supplying a password. For more background, see the previous installments of this series on OpenSSH key management, which cover RSA/DSA authentication (Part 1) and ssh-agent and keychain (Part 2), respectively.

Since Part 2 was published on developerWorks in September 2001, and later referenced on Slashdot and Freshmeat (see Resources later in this article for links to these sites), a lot of people have started using keychain, and it's undergone a lot of changes. I've received approximately 20 or so high-quality patches from developers around the world. I've incorporated many of these patches into the keychain source, which is now at version 1.8 (see Resources). I send my sincere thanks to all those who submitted patches, bug reports, feature requests, and notes of appreciation.

Tightening ssh security

In my last article, I've spent some time discussing the security benefits and tradeoffs of running ssh-agent. A few days after the second article appeared on developerWorks, I received an e-mail from Charles Karney of Sarnoff Corporation, who politely informed me of OpenSSH's new authentication agent forwarding abilities, which we'll take a look at in a bit. In addition, Charles emphasized that running ssh-agent on untrusted machines is quite dangerous: if someone manages to get root access on the system, then your decrypted keys can be extracted from ssh-agent. Even though extracting the keys would be somewhat difficult, it is within the skill of professional crackers. And the mere fact that private key theft is possible means that we should take steps to guard against it happening in the first place.

To formulate a strategy to protect our private keys, we must first put the machines we access into one of two categories. If a particular host is well-secured or isolated -- making successful root exploit against it quite unlikely -- then that machine should be considered a trusted host. If, however, a machine is used by many other people or you have some doubts about the security of the system, then the machine should be considered an untrusted host. To guard your private keys against extraction, ssh-agent (and thus keychain) should never be run on an untrusted host. That way, even if the system's security is compromised, there will be no ssh-agent around for the intruder to extract keys from in the first place.

However, this creates a problem. If you can't run ssh-agent on untrusted hosts, then how do you establish secure, passwordless ssh connections from these systems? The answer is to only use ssh-agent and keychain on trusted hosts, and to use OpenSSH's new authentication forwarding abilities to extend passwordless authentication to any untrusted hosts. In a nutshell, authentication forwarding works by allowing remote ssh sessions to contact an ssh-agent running on a trusted system.

Authentication agent forwarding

To get an idea of how authentication forwarding works, let's first take a look at a hypothetical situation where user drobbins has a trusted laptop called lappy, a trusted server called trustbox, and two other untrusted systems that he must access, called notrust1 and notrust2, respectively. Currently, he uses ssh-agent along with keychain on all four machines, as follows:

ssh-agent running on trusted and untrusted machines

The problem with this approach is that if someone gains root access on notrust1 or notrust2, then it is of course possible for this person to extract keys from the now vulnerable ssh-agent process. To fix this, drobbins stops running ssh-agent and keychain on untrusted hosts notrust1 and notrust2. In fact, to be even more careful, drobbins decides to only use ssh-agent and keychain on lappy. This limits exposure of his decrypted private keys, protecting him against private key theft:

ssh-agent running only on lappy; a more secure configuration

Of course, the problem with this approach is that drobbins can now only establish passwordless connections from lappy. Let's see how to enable authentication forwarding and get around this problem.

Assuming that all machines are running recent versions of OpenSSH, we can get around this problem by using authentication forwarding. Authentication forwarding allows remote ssh processes to contact the ssh-agent that is running on your local trusted machine -- rather than requiring a version of ssh-agent to be running on the same machine that you are sshing out from. This usually allows you to run ssh-agent (and keychain) on a single machine, and means that all ssh connections that originate (either directly or indirectly) from this machine will use your local ssh-agent.

To enable authentication forwarding, we add the following line to lappy and trustbox's /etc/ssh/ssh_config. Note that this is the config file for ssh (ssh_config), not the ssh daemon sshd (sshd_config):

ssh_config
ForwardAgent Yes

Now, to take advantage of authentication forwarding, drobbins can connect from lappy to trustbox, and then from trustbox to notrust1 without supplying passphrases for any of the connections. Both ssh processes "tap in" to the ssh-agent running on lappy:

$ ssh drobbins@trustbox
Last login: Wed Sep 26 13:42:08 2001 from lappy

Welcome to trustbox!
$ ssh drobbins@notrust1
Last login: Tue Sep 25 12:03:40 2001 from trustbox

Welcome to notrust1!
$

If you try a similar configuration and find that agent forwarding isn't working, try using ssh -A instead of plain old ssh to explicitly enable authentication forwarding. Here's a diagram of what went on behind the scenes when we logged in to trustbox and notrust1 using authentication forwarding, above:

Agent forwarding in action

As you can see, when ssh connected to trustbox, it maintained a connection to the ssh-agent running on lappy. When an ssh connection was made from trustbox to notrust1, this new ssh process maintained the authentication connection to the previous ssh, effectively extending the chain. Whether this authentication chain can be extended beyond notrust1 to other hosts depends on how notrust1's /etc/ssh/ssh_config is configured. As long as agent forwarding is enabled, all parts of the chain will be able to authenticate using the ssh-agent running on the trusted lappy.

Advantages of agent connection forwarding

Authentication forwarding offers a number of security advantages not touched on here. To convince me of the importance of agent connection forwarding, Charles Karney shared with me these three security advantages:

The private key is stored only on the trusted machine. This prevents malicious users from grabbing your encrypted key from disk and attempting to crack the encryption. ssh-agent runs only on the trusted machine. This prevents an intruder from doing a memory dump of a remote ssh-agent process and then extracting your decrypted private keys from the dump.

Since you only need to type in the passphrase on your trusted machine, you prevent any keystroke loggers from stealthily grabbing your passphrase as it is entered. The one drawback to relying on authentication agent connection forwarding is that it doesn't solve the problem of allowing cron jobs to take advantage of RSA/DSA authentication. One solution to this problem is to set up all cron jobs that need RSA/DSA authentication so that they execute from a trusted machine on your LAN. If necessary, these cron jobs can use ssh to connect to remote systems to automate backups, synchronize files, and so on.

Now that we've looked at authentication agent connection forwarding, let's turn to recent improvements made to the keychain script itself.

Keychain functionality improvements

Since the time this article was originally written in 2001, Keychain has become a successful Open Source project, and now supports nearly every version of UNIX (including Linux, BSD, Solaris, IRIX, and AIX as well as other UNIX platforms,) and has lots of advanced features. These features include support for gpg-agent, as well as a number of new command-line options, which you can learn about by typing keychain --help or reading the keychain man page (man keychain).

The official home for Keychain is on the Keychain page on the Funtoo wiki. Check there for updates and more information on this useful tool.

Conclusion

This column concludes my coverage of OpenSSH. Hopefully, you've learned enough about it to start using OpenSSH in an effective way to secure your systems.


Support Funtoo and help us grow! Donate $15 per month and get a free SSD-based Funtoo Virtual Container. 5 spots left.

About the Author

Daniel Robbins is best known as the creator of Gentoo Linux and author of many IBM developerWorks articles about Linux. Daniel currently serves as Benevolent Dictator for Life (BDFL) of Funtoo Linux. Funtoo Linux is a Gentoo-based distribution and continuation of Daniel's original Gentoo vision.

Got Funtoo?

Have you installed Funtoo Linux yet? Discover the power of a from-source meta-distribution optimized for your hardware! See our installation instructions and browse our CPU-optimized builds.

Funtoo News

Drobbins

RSS/Atom Support

You can now follow this news feed at http://www.funtoo.org/news/atom.xml .
10 February 2015 by Drobbins
Drobbins

Creating a Friendly Funtoo Culture

This news item details some recent steps that have been taken to help ensure that Funtoo is a friendly and welcoming place for our users.
2 February 2015 by Drobbins
Mgorny

CPU FLAGS X86

CPU_FLAGS_X86 are being introduced to group together USE flags managing CPU instruction sets.
31 January 2015 by Mgorny
View More News...

More Articles

Browse all our Linux-related articles, below:

A

B

F

G

K

L

M

O

P

S

T

W

X

Z