Difference between pages "Install/Partitioning" and "OpenSSH Key Management, Part 2"

< Install(Difference between pages)
(Introduction)
 
(Created page with "{{Article |Subtitle=Introducing ssh-agent and keychain |Summary=Many developers use the excellent OpenSSH as a secure, encrypted replacement for the venerable telnet and rsh c...")
 
Line 1: Line 1:
<noinclude>
+
{{Article
{{InstallPart|the process of partitioning and filesystem creation}}
+
|Subtitle=Introducing ssh-agent and keychain
</noinclude>
+
|Summary=Many developers 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 upon 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. In this second article, Daniel introduces ssh-agent (a private key cache) and keychain, a special bash script designed to make key-based authentication incredibly convenient and flexible.
=== Prepare Hard Disk ===
+
|Author=Drobbins
 
+
|Previous in Series=OpenSSH Key Management, Part 1
In this section, we'll learn about the different ways that Funtoo Linux can be installed on -- and boot from -- a hard disk.
+
|Next in Series=OpenSSH Key Management, Part 3
 
+
}}
==== Introduction ====
+
=== Introducing ssh-agent ===
 
+
In earlier times, there was only one way to boot a PC-compatible computer. All of our desktops and servers had a standard PC BIOS, all our hard drives used Master Boot Records to boot the system, and our hard drives were partitioned into different regions using the MBR partition scheme. That was just how it was done. And we liked it that way!
+
 
+
Then, along came EFI and UEFI, which are new-style firmware designed to boot systems, along with GPT partition tables to define disk partitions on disks larger than 2.2TB. All of the sudden, we had a variety of options for installing and booting Linux systems, turning what once was a one-method-fits-all approach into something a lot more complex.
+
 
+
Let's take a moment to review the options available to you for configuring a hard drive to boot Funtoo Linux. This Install Guide uses, and recommends, the old-school method of BIOS booting and using an MBR. It works and (except for rare cases) is universally supported. There's nothing wrong with it. If your system disk is 2TB or smaller in size, it won't prevent you from using all of your disk's capacity, either.
+
 
+
But, there are some situations where the old-school method isn't optimal. If you have a system disk >2TB in size, then MBR partitions won't allow you to access all your storage. So that's one reason. Another reason is that there are some so-called "PC" systems out there that don't support BIOS booting anymore, and force you to use UEFI to boot. So, out of compassion for people who fall into this predicament, this Install Guide documents UEFI booting too.
+
 
+
Our recommendation is still to go old-school unless you have reason not to. The boot loader we will be using to load the Linux kernel in this guide is called GRUB, so we call this method the '''BIOS + GRUB (MBR)''' method. It's the traditional method of setting up a PC-compatible system to boot Linux.
+
 
+
If you need to use UEFI to boot, we recommend not using the MBR at all for booting, as some systems support this, but others don't. Instead, we recommend using UEFI to boot GRUB, which in turn will load Linux. We refer to this method as the '''UEFI + GRUB (GPT)''' method.
+
 
+
And yes, there are even more methods, some of which are documented on the [[Boot Methods]] page. We used to recommend a '''BIOS + GRUB (GPT)''' method but it is not consistently supported across a wide variety of hardware.
+
 
+
'''The big question is -- which boot method should you use?''' Here's how to tell.
+
 
+
;Principle 1 - Old School: If you can reliably boot System Rescue CD and it shows you an initial light blue menu, you are booting the CD using the BIOS, and it's likely that you can thus boot Funtoo Linux using the BIOS. So, go old-school and use BIOS booting, ''unless'' you have some reason to use UEFI, such as having a >2.2TB system disk. In that case, see Principle 2, as your system may also support UEFI booting.
+
 
+
;Principle 2 - New School: If you can reliably boot System Rescue CD and it shows you an initial black and white menu -- congratulations, your system is configured to support UEFI booting. This means that you are ready to install Funtoo Linux to boot via UEFI. Your system may still support BIOS booting, but just be trying UEFI first. You can poke around in your BIOS boot configuration and play with this.
+
 
+
;What's the Big Difference between Old School and New School?: Here's the deal. If you go with old-school MBR partitions, your <code>/boot</code> partition will be an ext2 filesystem, and you'll use <code>fdisk</code> to create your MBR partitions. If you go with new-school GPT partitions and UEFI booting, your <code>/boot</code> partition will be a vfat filesystem, because this is what UEFI is able to read, and you will use <code>gdisk</code> to create your GPT partitions. And you'll install GRUB a bit differently. That's about all it comes down to, in case you were curious.
+
 
+
;Also Note: To install Funtoo Linux to boot via the New School UEFI method, you must boot System Rescue CD using UEFI -- and see an initial black and white screen. Otherwise, UEFI will not be active and you will not be able to set it up!
+
 
+
{{Note|'''Some motherboards may appear to support UEFI, but don't.''' Do your research. For example, the Award BIOS in my Gigabyte GA-990FXA-UD7 rev 1.1 has an option to enable UEFI boot for CD/DVD. '''This is not sufficient for enabling UEFI boot for hard drives and installing Funtoo Linux.''' UEFI must be supported for both removable media (so you can boot System Rescue CD using UEFI) as well as fixed media (so you can boot your new Funtoo Linux installation.) It turns out that later revisions of this board (rev 3.0) have a new BIOS that fully supports UEFI boot.  This may point to a third principle -- know thy hardware.}}
+
  
==== Old-School (BIOS/MBR) Method ====
+
ssh-agent, included with the OpenSSH distribution, is a special program designed to make dealing with RSA and DSA keys both pleasant and secure (see [[OpenSSH Key Management, Part 1|Part 1]] of this series for an introduction to RSA and DSA authentication.) ssh-agent, unlike ssh, is a long-running daemon designed for the sole purpose of caching your decrypted private keys.
  
{{Note|Use this method if you are booting using your BIOS, and if your System Rescue CD initial boot menu was light blue. If you're going to use the new-school method, [[#New-School (UEFI/GPT) Method|click here to jump down to UEFI/GPT.]]}}
+
ssh includes built-in support that allows it to communicate with ssh-agent, allowing ssh to acquire your decrypted private keys without prompting you for a password for every single new connection. With ssh-agent you simply use ssh-add to add your private keys to ssh-agent's cache. It's a one-time process; after using ssh-add, ssh will grab your private key from ssh-agent, rather than bugging you by prompting for a passphrase.
  
===== Preparation =====
+
=== Using ssh-agent ===
  
First, it's a good idea to make sure that you've found the correct hard disk to partition. Try this command and verify that <code>/dev/sda</code> is the disk that you want to partition:
+
Let's take a look at how this whole ssh-agent key caching system works. When ssh-agent starts up, it spits out a few important environment variables before detaching from the shell and continuing to run in the background. Here's some example output generated by ssh-agent when it begins:
  
 
<console>
 
<console>
# ##i##fdisk -l /dev/sda
+
$ ##i##ssh-agent
 
+
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK;
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
+
SSH_AGENT_PID=26917; export SSH_AGENT_PID;
Units = sectors of 1 * 512 = 512 bytes
+
echo Agent pid 26917;
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disk label type: gpt
+
 
+
 
+
#        Start          End    Size  Type            Name
+
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
+
 
</console>
 
</console>
  
Now, it's recommended that you erase any existing MBR or GPT partition tables on the disk, which could confuse the system's BIOS at boot time. We do this using <code>sgdisk</code>:
+
As you can see, ssh-agent's output is actually a series of bash commands; if executed, these commands would set a couple of environment variables, SSH_AUTH_SOCK and SSH_AGENT_PID. Due to the included export commands, these environment variables would be made available to any additional commands run later. Well, all that would happen if these lines were actually evaluated by the shell, but right now they're simply printed to stdout. To fix this, we can invoke ssh-agent in the following way:
{{fancywarning|This will make any existing partitions inaccessible! You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}
+
  
 
<console>
 
<console>
# ##i##sgdisk --zap-all /dev/sda
+
$ ##i##eval $(ssh-agent)
 
+
Creating new GPT entries.
+
GPT data structures destroyed! You may now partition the disk using fdisk or
+
other utilities.
+
 
</console>
 
</console>
 +
This command tells bash to run ssh-agent and then evaluate ssh-agent's output. Invoked this way, the SSH_AGENT_PID and SSH_AUTH_SOCK variables get set and exported by your shell, making these variables available to any new processes you may start during your login session.
  
This output is also nothing to worry about, as the command still succeded:
+
The best way to start ssh-agent is to add the above line to your ~/.bash_profile; that way, all programs started in your login shell will see the environment variables, be able to locate ssh-agent and query it for keys as needed. The environment variable of particular importance is SSH_AUTH_SOCK; the SSH_AUTH_SOCK contains a path to a UNIX domain socket that ssh and scp can use to establish a dialogue with ssh-agent.
  
<console>
+
=== Using ssh-add ===
***************************************************************
+
Found invalid GPT and valid MBR; converting MBR to GPT format
+
in memory.
+
***************************************************************
+
</console>
+
 
+
===== Partitioning =====
+
  
Now we will use <code>fdisk</code> to create the MBR partition table and partitions:
+
But of course, ssh-agent starts up with an empty cache of decrypted private keys. Before we can really use ssh-agent, we first need to add add our private key(s) to ssh-agent's cache using the ssh-add command. In the following example, I use ssh-add to add my ~/.ssh/id_rsa private RSA key to ssh-agent's cache:
  
 
<console>
 
<console>
# ##i##fdisk /dev/sda
+
$ ##i##ssh-add ~/.ssh/id_rsa
 +
Need passphrase for /home/drobbins/.ssh/id_rsa
 +
Enter passphrase for /home/drobbins/.ssh/id_rsa
 +
##i##(enter passphrase)
 
</console>
 
</console>
  
Within <code>fdisk</code>, follow these steps:
+
As you can see, ssh-add asked for my passphrase so that the private key can be decrypted and stored in ssh-agent's cache, ready for use. Once you've used ssh-add to add your private key (or keys) to ssh-agent's cache and SSH_AUTH_SOCK is defined in your current shell (which it should be, if you started ssh-agent from your ~/.bash_profile), then you can use scp and ssh to establish connections with remote systems without supplying your passphrase.
  
'''Empty the partition table''':
+
=== Limitations of ssh-agent ===
  
<console>
+
ssh-agent is really cool, but its default configuration still leaves us with a few minor inconveniences. Let's take a look at them.
Command (m for help): ##i##o ↵
+
</console>
+
  
'''Create Partition 1''' (boot):
+
For one, with {{c|eval $(ssh-agent)}} in ~/.bash_profile, a new copy of ssh-agent is launched for every login session; not only is this a tad bit wasteful, but it also means that you need to use ssh-add to add a private key to each new copy of ssh-agent. If you only open a single terminal or console on your system, this is no big deal, but most of us open quite a few terminals and need to type in our passphrase every single time we open a new console. Technically, there's no reason why we should need to do this since a single ssh-agent process really should suffice.
  
<console>
+
Another problem with the default ssh-agent setup is that it's not compatible with cron jobs. Since cron jobs are started by the cron process, they won't inherit the SSH_AUTH_SOCK variable from their environment, and thus won't know that a ssh-agent process is running or how to contact it. It turns out that this problem is also fixable.
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (1-4, default 1): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+128M ↵
+
</console>
+
  
'''Create Partition 2''' (swap):
+
=== Enter keychain ===
  
<console>
+
To solve these problems, I wrote a handy bash-based ssh-agent front-end called keychain. What makes keychain special is the fact that it allows you to use a single ssh-agent process per system, not just per login session. This means that you only need to do one ssh-add per private key, period. As we'll see in a bit, keychain even helps to optimize the ssh-add process by only trying to add private keys that aren't already in the running ssh-agent's cache.
Command (m for help): ##i##n ↵
+
Partition type (default p): ##i##↵
+
Partition number (2-4, default 2): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##+2G ↵
+
Command (m for help): ##i##t ↵
+
Partition number (1,2, default 2): ##i## ↵
+
Hex code (type L to list all codes): ##i##82 ↵
+
</console>
+
  
'''Create the root partition:'''
+
Here's a run-through of how keychain works. When started from your ~/.bash_profile, it will first check to see whether an ssh-agent is already running. If not, then it will start ssh-agent and record the important SSH_AUTH_SOCK and SSH_AGENT_PID variables in the ~/.ssh/.keychain/<hostname>-sh file for safe keeping and later use. Here's the best way to start keychain; like using plain old ssh-agent, we perform the necessary setup inside ~/.bash_profile:
  
<console>
+
{{file|name=~/.bash_profile|desc=Settings for ssh-agent in ~/.bash_profile|body=
Command (m for help): ##i##n ↵
+
eval $(keychain --eval --agents ssh id_rsa)
Partition type (default p): ##i##↵
+
}}
Partition number (3,4, default 3): ##i##↵
+
First sector: ##i##↵
+
Last sector: ##i##↵
+
</console>
+
  
'''Verify the partition table:'''
+
With keychain, we evaluate the output identically to how we did it with ssh-agent. Our ever-important SSH_AUTH_SOCK is defined, and ssh-agent is running and ready for use. And because SSH_AUTH_SOCK is recorded in ~/.ssh/.keychain/, our own shell scripts and cron jobs can easily connect with ssh-agent just by sourcing the ~/.ssh/.keychain/<hostname>-sh file. keychain itself also takes advantage of this file; you'll remember that when keychain starts up, it checks to see whether an existing ssh-agent is running. If so, it uses the appropriate file in ~/.ssh/.keychain/ to acquire the proper SSH_AUTH_SOCK setting, thus allowing it to use the existing agent rather than starting a new one. keychain will start a new ssh-agent process only if the ~/.ssh/.keychain/ file is stale (points to a non-existent ssh-agent) or if ~/.ssh/keychain/ itself does not exist.
  
<console>
+
=== Installing keychain ===
Command (m for help): ##i##p
+
  
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
+
Many Linux distributions and versions of UNIX provide a package for keychain, which can be installed using that operating system's package manager.
Units: sectors of 1 * 512 = 512 bytes
+
Sector size (logical/physical): 512 bytes / 512 bytes
+
I/O size (minimum/optimal): 512 bytes / 512 bytes
+
Disklabel type: dos
+
Disk identifier: 0x82abc9a6
+
 
+
Device    Boot    Start      End    Blocks  Id System
+
/dev/sda1          2048    264191    131072  83 Linux
+
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
+
/dev/sda3        4458496 625142447 310341976  83 Linux
+
</console>
+
  
'''Write the parition table to disk:'''
+
To install keychain from the source tarball, download the most recent tarball from the [[Keychain]] page. Extract the tarball, and copy keychain itself to /usr/sbin:
  
 
<console>
 
<console>
Command (m for help): ##i##w
+
# ##i##wget http://www.funtoo.org/distfiles/keychain/keychain-2.7.2_beta1.tar.bz2
 +
# ##i##cd keychain-2.7.2_beta1
 +
# ##i##cp keychain /usr/bin
 +
# ##i##cp keychain.1 /usr/share/man/man1
 
</console>
 
</console>
  
Your new MBR partition table will now be written to your system disk.
+
Now that keychain is in /usr/bin/, add it to your ~/.bash_profile, supplying paths to your private keys as arguments. Here's a good standard keychain-enabled ~/.bash_profile:
  
{{Note|You're done with partitioning! Now, jump over to [[#Creating filesystems|Creating filesystems]].}}
+
{{file|name=~/.bash_profile|body=
 +
eval $(keychain --eval --agents ssh id_rsa)
 +
# sourcing ~/.bashrc is a good thing:
 +
source ~/.bashrc
 +
}}
  
==== New-School (UEFI/GPT) Method ====
+
=== Keychain in action ===
  
{{Note|Use this method if you are booting using UEFI, and if your System Rescue CD initial boot menu was black and white. If it was light blue, this method will not work.}}
+
Once you've configured your ~/.bash_profile to call keychain at every login, log out and log back in. When you do, keychain will start ssh-agent, record the agent's environment variable settings in ~/.keychain/, and then prompt you for passphrases for any private keys specified on the keychain command-line in ~/.bash_profile:
  
The <tt>gdisk</tt> commands to create a GPT partition table are as follows. Adapt sizes as necessary, although these defaults will work for most users. Start <code>gdisk</code>:
+
[[File:l-ssh-1.gif|frame|center|Keychain starts for the first time]]
  
<console>
+
Once you enter your passphrases, you private keys will be cached, and keychain will exit. Then, ~/.keychain/<hostname>-sh will be sourced, initializing your login session for use with ssh-agent. Now, if you log out and log back in again, you'll find that keychain will find the existing ssh-agent process; it didn't terminate when you logged out. In addition, keychain will verify that the private key(s) you specified are already in ssh-agent's cache. If not, then you'll be prompted for the appropriate passphrases, but if all goes well, your existing ssh-agent will still contain the private key that you previously added; this means that you're not prompted for a password:
# ##i##gdisk
+
</console>
+
  
Within <tt>gdisk</tt>, follow these steps:
+
[[File:l-ssh-2.gif|frame|center|Keychain finds an existing ssh-agent]]
  
'''Create a new empty partition table''' (This ''will'' erase all data on the disk when saved):
+
Congratulations; you've just logged in and should be able to ssh and scp to remote systems; you didn't need to use ssh-add right after login, and ssh and scp won't prompt you for a passphrase either. In fact, as long as your initial ssh-agent process keeps running, you'll be able to log in and establish ssh connections without supplying a password. And it's very likely that your ssh-agent process will continue to run until the machine is rebooted; since you're most likely setting this up on a Linux system, it's possible that you may not need to enter your passphrase for several months! Welcome to the world of secure, passwordless connections using RSA and DSA authentication.
  
<console>
+
Go ahead and create several new login sessions, and you'll see that keychain will "hook in" to the exact same ssh-agent process each time. Don't forget that you can also get your cron jobs and scripts to "hook in" to the running ssh-agent process. To use ssh or scp commands from your shell scripts and cron jobs, just make sure that they call keychain, as you did in your .bash_profile.
Command: ##i##o ↵
+
This option deletes all partitions and creates a new protective MBR.
+
Proceed? (Y/N): ##i##y ↵
+
</console>
+
  
'''Create Partition 1''' (boot):
+
=== Keychain options ===
  
<console>
+
After you have keychain up and running, be sure to type keychain --help to familiarize yourself with all of keychain's command-line options. We're going to take a look at one in particular: the --clear option.
Command: ##i##n ↵
+
Partition Number: ##i##1 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+500M ↵
+
Hex Code: ##i##↵
+
</console>
+
  
'''Create Partition 2''' (swap):
+
You'll recall that in [[OpenSSH Key Management, Part 1|Part 1]], I explained that using unencrypted private keys is a dangerous practice, because it allows someone to steal your private key and use it to log in to your remote accounts from any other system without supplying a password. Well, while keychain isn't vulnerable to this kind of abuse (as long as you use encrypted private keys, that is), there is a potentially exploitable weakness directly related to the fact that keychain makes it so easy to "hook in" to a long-running ssh-agent process. What would happen, I thought, if some intruder were somehow able to figure out my password or passphrase and log into my local system? If they were somehow able to log in under my username, keychain would grant them instant access to my decrypted private keys, making it a no-brainer for them to access my other accounts.
  
<console>
+
Now, before I continue, let's put this security threat in perspective. If some malicious user were somehow able to log in as me, keychain would indeed allow them to access my remote accounts. Yet, even so, it would be very difficult for the intruder to steal my decrypted private keys since they are still encrypted on disk. Also, gaining access to my private keys would require a user to actually log in as me, not just read files in my directory. So, abusing ssh-agent would be a much more difficult task than simply stealing an unencrypted private key, which only requires that an intruder somehow gain access to my files in ~/.ssh, whether logged in as me or not. Nevertheless, if an intruder were successfully able to log in as me, they could do quite a bit of additional damage by using my decrypted private keys. So, if you happen to be using keychain on a server that you don't log into very often or don't actively monitor for security breaches, then consider using the --clear option to provide an additional layer of security.
Command: ##i##n ↵
+
Partition Number: ##i##2 ↵
+
First sector: ##i##↵
+
Last sector: ##i##+4G ↵
+
Hex Code: ##i##8200 ↵
+
</console>
+
  
'''Create Partition 3''' (root):
+
The --clear option allows you to tell keychain to assume that every new login to your account should be considered a potential security breach until proven otherwise. When you start keychain with the --clear option, keychain immediately flushes all your private keys from ssh-agent's cache when you log in, before performing its normal duties. Thus, if you're an intruder, keychain will prompt you for passphrases rather than giving you access to your existing set of cached keys. However, even though this enhances security, it does make things a bit more inconvenient and very similar to running ssh-agent all by itself, without keychain. Here, as is often the case, one can opt for greater security or greater convenience, but not both.
  
<console>
+
Despite this, using keychain with --clear still has advantages over using ssh-agent all by itself; remember, when you use keychain --clear, your cron jobs and scripts will still be able to establish passwordless connections; this is because your private keys are flushed at login, not logout. Since a logout from the system does not constitute a potential security breach, there's no reason for keychain to respond by flushing ssh-agent's keys. Thus, the --clear option an ideal choice for infrequently accessed servers that need to perform occasional secure copying tasks, such as backup servers, firewalls, and routers.
Command: ##i##n ↵
+
Partition Number: ##i##3 ↵
+
First sector: ##i##↵
+
Last sector: ##i##↵##!i## (for rest of disk)
+
Hex Code: ##i##↵
+
</console>
+
  
Along the way, you can type "<tt>p</tt>" and hit Enter to view your current partition table. If you make a mistake, you can type "<tt>d</tt>" to delete an existing partition that you created. When you are satisfied with your partition setup, type "<tt>w</tt>" to write your configuration to disk:
+
=== We're done! ===
  
'''Write Partition Table To Disk''':
+
Now that the OpenSSH key management series is complete, you should be very familiar with RSA and DSA keys and know how to use them in a convenient yet secure way.  
 
+
{{ArticleFooter}}
<console>
+
Command: ##i##w ↵
+
Do you want to proceed? (Y/N): ##i##Y ↵
+
</console>
+
 
+
The partition table will now be written to disk and <tt>gdisk</tt> will close.
+
 
+
Now, your GPT/GUID partitions have been created, and will show up as the following ''block devices'' under Linux:
+
 
+
* <tt>/dev/sda1</tt>, which will be used to hold the <tt>/boot</tt> filesystem,
+
* <tt>/dev/sda2</tt>, which will be used for swap space, and
+
* <tt>/dev/sda3</tt>, which will hold your root filesystem.
+
 
+
==== Creating filesystems ====
+
 
+
{{Note|This section covers both BIOS ''and'' UEFI installs. Don't skip it!}}
+
 
+
Before your newly-created partitions can be used, the block devices need to be initialized with filesystem ''metadata''. This process is known as ''creating a filesystem'' on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.
+
 
+
Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:
+
 
+
<console>
+
# ##i##mkfs.ext2 /dev/sda1
+
</console>
+
 
+
If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:
+
 
+
<console>
+
# ##i##mkfs.vfat -F 32 /dev/sda1
+
</console>
+
 
+
Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.
+
 
+
You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the <code>mkswap</code> command. Then we'll run the <code>swapon</code> command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:
+
 
+
<console>
+
# ##i##mkswap /dev/sda2
+
# ##i##swapon /dev/sda2
+
</console>
+
 
+
Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:
+
 
+
<console>
+
# ##i##mkfs.ext4 /dev/sda3
+
</console>
+
 
+
...and here's how to create an XFS root filesystem, if you choose to use XFS:
+
 
+
<console>
+
# ##i##mkfs.xfs /dev/sda3
+
</console>
+
 
+
Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.
+
 
+
{{fancywarning|1=
+
When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of <code>openvz-rhel6-stable</code> are '''not''' compatible with XFS, and you may experience kernel bugs.
+
}}
+
 
+
==== Mounting filesystems ====
+
 
+
Mount the newly-created filesystems as follows, creating <code>/mnt/funtoo</code> as the installation mount point:
+
 
+
<console>
+
# ##i##mkdir /mnt/funtoo
+
# ##i##mount /dev/sda3 /mnt/funtoo
+
# ##i##mkdir /mnt/funtoo/boot
+
# ##i##mount /dev/sda1 /mnt/funtoo/boot
+
</console>
+
 
+
Optionally, if you have a separate filesystem for <code>/home</code> or anything else:
+
 
+
<console>
+
# ##i##mkdir /mnt/funtoo/home
+
# ##i##mount /dev/sda4 /mnt/funtoo/home
+
</console>
+
 
+
If you have <code>/tmp</code> or <code>/var/tmp</code> on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:
+
 
+
<console>
+
# ##i##chmod 1777 /mnt/funtoo/tmp
+
</console>
+

Revision as of 00:51, January 2, 2015

Introducing ssh-agent and keychain

Many developers 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 upon 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. In this second article, Daniel introduces ssh-agent (a private key cache) and keychain, a special bash script designed to make key-based authentication incredibly convenient and flexible.


Previous in series: OpenSSH Key Management, Part 1
Next in series: OpenSSH Key Management, Part 3

Support Funtoo and help us grow! Donate $15 per month and get a free SSD-based Funtoo Virtual Container.
Looking for people interested in testing and documenting Docker support! Contact Daniel Robbins for more info.

Introducing ssh-agent

ssh-agent, included with the OpenSSH distribution, is a special program designed to make dealing with RSA and DSA keys both pleasant and secure (see Part 1 of this series for an introduction to RSA and DSA authentication.) ssh-agent, unlike ssh, is a long-running daemon designed for the sole purpose of caching your decrypted private keys.

ssh includes built-in support that allows it to communicate with ssh-agent, allowing ssh to acquire your decrypted private keys without prompting you for a password for every single new connection. With ssh-agent you simply use ssh-add to add your private keys to ssh-agent's cache. It's a one-time process; after using ssh-add, ssh will grab your private key from ssh-agent, rather than bugging you by prompting for a passphrase.

Using ssh-agent

Let's take a look at how this whole ssh-agent key caching system works. When ssh-agent starts up, it spits out a few important environment variables before detaching from the shell and continuing to run in the background. Here's some example output generated by ssh-agent when it begins:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26917; export SSH_AGENT_PID;
echo Agent pid 26917;

As you can see, ssh-agent's output is actually a series of bash commands; if executed, these commands would set a couple of environment variables, SSH_AUTH_SOCK and SSH_AGENT_PID. Due to the included export commands, these environment variables would be made available to any additional commands run later. Well, all that would happen if these lines were actually evaluated by the shell, but right now they're simply printed to stdout. To fix this, we can invoke ssh-agent in the following way:

$ eval $(ssh-agent)

This command tells bash to run ssh-agent and then evaluate ssh-agent's output. Invoked this way, the SSH_AGENT_PID and SSH_AUTH_SOCK variables get set and exported by your shell, making these variables available to any new processes you may start during your login session.

The best way to start ssh-agent is to add the above line to your ~/.bash_profile; that way, all programs started in your login shell will see the environment variables, be able to locate ssh-agent and query it for keys as needed. The environment variable of particular importance is SSH_AUTH_SOCK; the SSH_AUTH_SOCK contains a path to a UNIX domain socket that ssh and scp can use to establish a dialogue with ssh-agent.

Using ssh-add

But of course, ssh-agent starts up with an empty cache of decrypted private keys. Before we can really use ssh-agent, we first need to add add our private key(s) to ssh-agent's cache using the ssh-add command. In the following example, I use ssh-add to add my ~/.ssh/id_rsa private RSA key to ssh-agent's cache:

$ ssh-add ~/.ssh/id_rsa
Need passphrase for /home/drobbins/.ssh/id_rsa
Enter passphrase for /home/drobbins/.ssh/id_rsa
(enter passphrase)

As you can see, ssh-add asked for my passphrase so that the private key can be decrypted and stored in ssh-agent's cache, ready for use. Once you've used ssh-add to add your private key (or keys) to ssh-agent's cache and SSH_AUTH_SOCK is defined in your current shell (which it should be, if you started ssh-agent from your ~/.bash_profile), then you can use scp and ssh to establish connections with remote systems without supplying your passphrase.

Limitations of ssh-agent

ssh-agent is really cool, but its default configuration still leaves us with a few minor inconveniences. Let's take a look at them.

For one, with eval $(ssh-agent) in ~/.bash_profile, a new copy of ssh-agent is launched for every login session; not only is this a tad bit wasteful, but it also means that you need to use ssh-add to add a private key to each new copy of ssh-agent. If you only open a single terminal or console on your system, this is no big deal, but most of us open quite a few terminals and need to type in our passphrase every single time we open a new console. Technically, there's no reason why we should need to do this since a single ssh-agent process really should suffice.

Another problem with the default ssh-agent setup is that it's not compatible with cron jobs. Since cron jobs are started by the cron process, they won't inherit the SSH_AUTH_SOCK variable from their environment, and thus won't know that a ssh-agent process is running or how to contact it. It turns out that this problem is also fixable.

Enter keychain

To solve these problems, I wrote a handy bash-based ssh-agent front-end called keychain. What makes keychain special is the fact that it allows you to use a single ssh-agent process per system, not just per login session. This means that you only need to do one ssh-add per private key, period. As we'll see in a bit, keychain even helps to optimize the ssh-add process by only trying to add private keys that aren't already in the running ssh-agent's cache.

Here's a run-through of how keychain works. When started from your ~/.bash_profile, it will first check to see whether an ssh-agent is already running. If not, then it will start ssh-agent and record the important SSH_AUTH_SOCK and SSH_AGENT_PID variables in the ~/.ssh/.keychain/<hostname>-sh file for safe keeping and later use. Here's the best way to start keychain; like using plain old ssh-agent, we perform the necessary setup inside ~/.bash_profile:

~/.bash_profile - Settings for ssh-agent in ~/.bash_profile
eval $(keychain --eval --agents ssh id_rsa)

With keychain, we evaluate the output identically to how we did it with ssh-agent. Our ever-important SSH_AUTH_SOCK is defined, and ssh-agent is running and ready for use. And because SSH_AUTH_SOCK is recorded in ~/.ssh/.keychain/, our own shell scripts and cron jobs can easily connect with ssh-agent just by sourcing the ~/.ssh/.keychain/<hostname>-sh file. keychain itself also takes advantage of this file; you'll remember that when keychain starts up, it checks to see whether an existing ssh-agent is running. If so, it uses the appropriate file in ~/.ssh/.keychain/ to acquire the proper SSH_AUTH_SOCK setting, thus allowing it to use the existing agent rather than starting a new one. keychain will start a new ssh-agent process only if the ~/.ssh/.keychain/ file is stale (points to a non-existent ssh-agent) or if ~/.ssh/keychain/ itself does not exist.

Installing keychain

Many Linux distributions and versions of UNIX provide a package for keychain, which can be installed using that operating system's package manager.

To install keychain from the source tarball, download the most recent tarball from the Keychain page. Extract the tarball, and copy keychain itself to /usr/sbin:

# wget http://www.funtoo.org/distfiles/keychain/keychain-2.7.2_beta1.tar.bz2
# cd keychain-2.7.2_beta1
# cp keychain /usr/bin
# cp keychain.1 /usr/share/man/man1

Now that keychain is in /usr/bin/, add it to your ~/.bash_profile, supplying paths to your private keys as arguments. Here's a good standard keychain-enabled ~/.bash_profile:

~/.bash_profile
eval $(keychain --eval --agents ssh id_rsa)
# sourcing ~/.bashrc is a good thing:
source ~/.bashrc

Keychain in action

Once you've configured your ~/.bash_profile to call keychain at every login, log out and log back in. When you do, keychain will start ssh-agent, record the agent's environment variable settings in ~/.keychain/, and then prompt you for passphrases for any private keys specified on the keychain command-line in ~/.bash_profile:

Keychain starts for the first time

Once you enter your passphrases, you private keys will be cached, and keychain will exit. Then, ~/.keychain/<hostname>-sh will be sourced, initializing your login session for use with ssh-agent. Now, if you log out and log back in again, you'll find that keychain will find the existing ssh-agent process; it didn't terminate when you logged out. In addition, keychain will verify that the private key(s) you specified are already in ssh-agent's cache. If not, then you'll be prompted for the appropriate passphrases, but if all goes well, your existing ssh-agent will still contain the private key that you previously added; this means that you're not prompted for a password:

Keychain finds an existing ssh-agent

Congratulations; you've just logged in and should be able to ssh and scp to remote systems; you didn't need to use ssh-add right after login, and ssh and scp won't prompt you for a passphrase either. In fact, as long as your initial ssh-agent process keeps running, you'll be able to log in and establish ssh connections without supplying a password. And it's very likely that your ssh-agent process will continue to run until the machine is rebooted; since you're most likely setting this up on a Linux system, it's possible that you may not need to enter your passphrase for several months! Welcome to the world of secure, passwordless connections using RSA and DSA authentication.

Go ahead and create several new login sessions, and you'll see that keychain will "hook in" to the exact same ssh-agent process each time. Don't forget that you can also get your cron jobs and scripts to "hook in" to the running ssh-agent process. To use ssh or scp commands from your shell scripts and cron jobs, just make sure that they call keychain, as you did in your .bash_profile.

Keychain options

After you have keychain up and running, be sure to type keychain --help to familiarize yourself with all of keychain's command-line options. We're going to take a look at one in particular: the --clear option.

You'll recall that in Part 1, I explained that using unencrypted private keys is a dangerous practice, because it allows someone to steal your private key and use it to log in to your remote accounts from any other system without supplying a password. Well, while keychain isn't vulnerable to this kind of abuse (as long as you use encrypted private keys, that is), there is a potentially exploitable weakness directly related to the fact that keychain makes it so easy to "hook in" to a long-running ssh-agent process. What would happen, I thought, if some intruder were somehow able to figure out my password or passphrase and log into my local system? If they were somehow able to log in under my username, keychain would grant them instant access to my decrypted private keys, making it a no-brainer for them to access my other accounts.

Now, before I continue, let's put this security threat in perspective. If some malicious user were somehow able to log in as me, keychain would indeed allow them to access my remote accounts. Yet, even so, it would be very difficult for the intruder to steal my decrypted private keys since they are still encrypted on disk. Also, gaining access to my private keys would require a user to actually log in as me, not just read files in my directory. So, abusing ssh-agent would be a much more difficult task than simply stealing an unencrypted private key, which only requires that an intruder somehow gain access to my files in ~/.ssh, whether logged in as me or not. Nevertheless, if an intruder were successfully able to log in as me, they could do quite a bit of additional damage by using my decrypted private keys. So, if you happen to be using keychain on a server that you don't log into very often or don't actively monitor for security breaches, then consider using the --clear option to provide an additional layer of security.

The --clear option allows you to tell keychain to assume that every new login to your account should be considered a potential security breach until proven otherwise. When you start keychain with the --clear option, keychain immediately flushes all your private keys from ssh-agent's cache when you log in, before performing its normal duties. Thus, if you're an intruder, keychain will prompt you for passphrases rather than giving you access to your existing set of cached keys. However, even though this enhances security, it does make things a bit more inconvenient and very similar to running ssh-agent all by itself, without keychain. Here, as is often the case, one can opt for greater security or greater convenience, but not both.

Despite this, using keychain with --clear still has advantages over using ssh-agent all by itself; remember, when you use keychain --clear, your cron jobs and scripts will still be able to establish passwordless connections; this is because your private keys are flushed at login, not logout. Since a logout from the system does not constitute a potential security breach, there's no reason for keychain to respond by flushing ssh-agent's keys. Thus, the --clear option an ideal choice for infrequently accessed servers that need to perform occasional secure copying tasks, such as backup servers, firewalls, and routers.

We're done!

Now that the OpenSSH key management series is complete, you should be very familiar with RSA and DSA keys and know how to use them in a convenient yet secure way.

Next >>>

Read the next article in this series: OpenSSH Key Management, Part 3

Support Funtoo and help us grow! Donate $15 per month and get a free SSD-based Funtoo Virtual Container.
Looking for people interested in testing and documenting Docker support! Contact Daniel Robbins for more info.

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

How We're Keeping You At the Center of the Funtoo Universe

Read about recent developments that keep you, our users, at the forefront of our focus as Funtoo moves forward.
10 April 2015 by Drobbins
Mgorny

New OpenGL management in Funtoo

Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and NVIDIA). The update may involve blockers and file collisions.
30 March 2015 by Mgorny
Drobbins

Subarch Profiles are coming...

Subarch profiles are on their way! Learn more here.
29 March 2015 by Drobbins
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