Difference between pages "Mitigating Systemd" and "OpenSSH Key Management, Part 3"

(Difference between pages)
m (resolved: Added info.)
 
(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:
Funtoo currently has no plans to migrate or adopt systemd as it's default init system. This does '''not''' prevent you from using systemd on your system. [https://coreos.com/ CoreOS], for example, is a systemd based system build on Gentoo.  
+
{{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.
  
For users not seeking to use systemd, that is, most Funtoo users, this page will serve both as the Funtoo development team's planning for the future, and information on how to avoid systemd in your system.
+
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.
  
== Components of systemd ==
+
=== Tightening ssh security ===
  
=== systemd ===
+
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.
  
Provides replacements for the following daemons or utilities:
+
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.
  
* {{Package|sys-apps/sysvinit}}
+
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.
* {{Package|sys-power/pm-utils}}
+
* {{Package|virtual/inetd}}
+
* {{Package|sys-power/acpid}}
+
* [[Installing a Logger|syslog]]
+
* {{Package|sys-apps/watchdog}}
+
* [[Installing a Cron Daemon|cron]]
+
* atd
+
  
=== consoled ===
+
=== Authentication agent forwarding ===
  
Provides a user console daemon and handles Linux Virtual terminal support.
+
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:
  
=== [http://www.freedesktop.org/wiki/Software/systemd/hostnamed/ hostnamed] ===
+
[[FIle:l-ssh-3.jpg|center|frame|ssh-agent running on trusted and untrusted machines]]
  
This is a tiny daemon that can be used to control the host name and related machine meta data from user programs. It currently offers access to five variables:
+
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:
  
* The current host name (Example: dhcp-192-168-47-11)
+
[[File:l-ssh-4.jpg|center|frame|ssh-agent running only on lappy; a more secure configuration]]
* The static (configured) host name (Example: lennarts-computer)
+
* The pretty host name (Example: Lennart's Computer)
+
* A suitable icon name for the local host (Example: computer-laptop)
+
* A chassis type (Example: "tablet")
+
  
=== journald ===
+
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.
  
Provides logging functionality.
+
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.
  
Provides replacement for the [[Installing a Logger|system logger]].
+
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):
  
=== [http://www.freedesktop.org/wiki/Software/systemd/machined/ machined] ===
+
{{file|name=ssh_config|body=
 +
ForwardAgent Yes
 +
}}
  
The daemon provides both a C library interface (which is shared with logind) as well as a D-Bus interface. The library interface may be used to introspect and watch the state of virtual machines/containers. The bus interface provides the same but in addition may also be used to register or terminate machines.
+
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:
  
=== [http://www.freedesktop.org/wiki/Software/systemd/localed/ localed] ===
+
<console>
 +
$ ##i##ssh drobbins@trustbox
 +
Last login: Wed Sep 26 13:42:08 2001 from lappy
  
This is a tiny daemon that can be used to control the system locale and keyboard mapping from user programs.
+
Welcome to trustbox!
 +
$ ##i##ssh drobbins@notrust1
 +
Last login: Tue Sep 25 12:03:40 2001 from trustbox
  
=== [http://www.freedesktop.org/wiki/Software/systemd/logind/ logind] ===
+
Welcome to notrust1!
 +
$
 +
</console>
  
Manages user logins and seats. Replaces {{Package|sys-auth/consolekit}}.
+
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:
  
=== [http://www.freedesktop.org/software/systemd/man/systemd-networkd.html networkd] ===
+
[[File:l-ssh-5.jpg|frame|center|Agent forwarding in action]]
  
A system service that manages networks. It detects and configures network devices as they appear, as well as creating virtual network devices.
+
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.
  
=== [http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html resolved] ===
+
=== Advantages of agent connection forwarding ===
  
A system service that manages network name resolution. It implements a caching DNS stub resolver and an LLMNR resolver and responder. It also generates /run/systemd/resolve/resolv.conf for compatibility which may be symlinked from /etc/resolv.conf.
+
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:
  
=== [http://www.freedesktop.org/software/systemd/man/systemd-halt.service.html systemd-shutdown] ===
+
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.
  
TODO.
+
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.
  
=== [http://www.freedesktop.org/wiki/Software/systemd/timedated/ timedated]  ===
+
Now that we've looked at authentication agent connection forwarding, let's turn to recent improvements made to the keychain script itself.
  
This is a tiny daemon that can be used to control the system time and related settings. It currently offers access to four settings:
+
=== Keychain functionality improvements ===
  
* The system time
+
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}}).
* The system timezone
+
* A boolean controlling whether the system RTC is in local or UTC timezone
+
* Whether the systemd-timesyncd.service (NTP) services is enabled/started or disabled/stopped.
+
  
=== [http://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html timesyncd] ===
+
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 system service that may be used to synchronize the local system clock with a remote Network Time Protocol server. It also saves the local time to disk every time the clock has been synchronized and uses this to possibly advance the system realtime clock on subsequent reboots to ensure it monotonically advances even if the system lacks a battery-buffered RTC chip.
+
=== Conclusion ===
  
Alternatives:
+
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.  
 
+
{{ArticleFooter}}
* {{Package|net-misc/ntp}}
+
* {{Package|net-misc/openntpd}}
+
* {{Package|net-misc/ntpclient}}
+
* {{Package| sys-libs/timezone-data}}
+
 
+
 
+
=== udevd & libudev  ===
+
 
+
{{Package|sys-fs/udev}} is a successor to <tt>hotplug</tt> and <tt>devfsd</tt>. It's primary task is to manage device nodes in <tt>/dev</tt>.
+
 
+
Alternatives:
+
* {{Package|sys-fs/eudev}}
+

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.

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

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.

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.
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

Perl Updates

Gentoo has bumped perl from 5.20 to 5.22. Be sure to run perl-cleaner --all after the upgrade.
2015-07-25 by Drobbins
Drobbins

ARM Rebuild

ARM systems will use new stage3's that are not compatible with earlier versions.
2015-06-27 by Drobbins
Drobbins

ABI X86 64 and 32

Funtoo Linux has new 32-bit compatibility libraries inherited from Gentoo. Learn about them here.
2015-06-18 by Drobbins
More...

More Articles

Browse all our Linux-related articles, below:

A

B

F

G

K

L

M

O

P

S

T

W

X