31 Keychain

[Karoline]

Keychain helps you to manage SSH and GPG keys in a convenient and secure manner. It acts as a frontend to ssh-agent and ssh-add, but allows you to easily have one long running ssh-agent process per system, rather than the norm of one ssh-agent per login session.

This dramatically reduces the number of times you need to enter your passphrase. With keychain, you only need to enter a passphrase once every time your local machine is rebooted. Keychain also makes it easy for remote cron jobs to securely "hook in" to a long-running ssh-agent process, allowing your scripts to take advantage of key-based logins.

Those who are new to OpenSSH and the use of public/private keys for authentication may want to check out the following articles by Daniel Robbins, which will provide a gentle introduction to the concepts used by Keychain:

Keychain development sources can be found on GitHub. Please feel free to use the GitHub issue tracker to report bugs. Alternatively, the Funtoo Linux bug tracker can be used. For support, you can visit us in the #funtoo irc channel or the Funtoo forums for keychain support questions.

On April 21, 2004, Aron Griffis committed a major rewrite of keychain which was released as 2.2.0. Aron continued to actively maintain and improve keychain through October 2006 and the keychain 2.6.8 release. He also made a few commits after that date, up through mid-July, 2007. At this point, keychain had reached a point of maturity.

In mid-July, 2009, Daniel Robbins migrated Aron's mercurial repository to git and set up a new project page on funtoo.org, and made a few bug fix commits to the git repo that had been collecting in bugs.gentoo.org. Daniel maintained keychain through September of 2017.

Typically, when one uses ssh to connect to a remote system, one supplies a secret passphrase to ssh, which is then passed in encrypted form over the network to the remote server. This passphrase is used by the remote sshd server to determine if you should be granted access to the system.

However, OpenSSH and nearly all other SSH clients and servers have the ability to perform another type of authentication, called asymmetric public key authentication, using the RSA or other authentication algorithms. They are very useful, but can also be complicated to use. keychain has been designed to make it easy to take advantage of the benefits of public key authentication.

To use public key authentication, first you use a program called ssh-keygen (included with OpenSSH) to generate a key pair -- two small files. One of the files is the public key. The other small file contains the private key. ssh-keygen will ask you for a passphrase, and this passphrase will be used to encrypt your private key. You will need to supply this passphrase to use your private key. If you wanted to generate a RSA key pair, you would do this:

Then, you are prompted for a passphrase. This passphrase is used to encrypt the private key on disk, so even if it is stolen, it will be difficult for someone else to use it to successfully authenticate as you with any accounts that have been configured to recognize your public key.

Note that conversely, if you do not provide a passphrase for your private key file, then your private key file will not be encrypted. This means that if someone steals your private key file, they will have the full ability to authenticate with any remote accounts that are set up with your public key.

Then, if you weren't going to use keychain, you'd perform the following steps. On your local client, you would start a program called ssh-agent, which runs in the background. Then you would use a program called ssh-add to tell ssh-agent about your secret private key. Then, if you've set up your environment properly, the next time you run ssh, it will find ssh-agent running, grab the private key that you added to ssh-agent using ssh-add, and use this key to authenticate with the remote server.

Note that when keychain runs for the first time after your local system has booted, you will be prompted for a passphrase for your private key file if it is encrypted. But here's the nice thing about using keychain -- even if you are using an encrypted private key file, you will only need to enter your passphrase when your system first boots (or in the case of a server, when you first log in.) After that, ssh-agent is already running and has your decrypted private key cached in memory. So if you open a new shell, you will see something like this:

You can also execute batch cron jobs and scripts that need to use ssh or scp, and they can take advantage of passwordless public key authentication as well. To do this, you would add the following line to the top of a bash script:

The extra --noask option tells keychain that it should not prompt for a passphrase if one is needed. Since it is not running interactively, it is better for the script to fail if the decrypted private key isn't cached in memory via ssh-agent.

I also recommend you read my original series of articles about OpenSSH that I wrote for IBM developerWorks, called OpenSSH Key Management. Please note that keychain 1.0 was released along with Part 2 of this article, which was written in 2001. keychain has changed quite a bit since then. In other words, read these articles for the conceptual and OpenSSH information, but consult the keychain man page for command-line options and usage instructions :)

As mentioned at the top of the page, keychain development sources can be found in the keychain git repository. Please use the Funtoo Forums and #funtoo irc channel for keychain support questions as well as bug reports.

Keychain is the password management system in macOS, developed by Apple. It was introduced with Mac OS 8.6, and has been included in all subsequent versions of the operating system, now known as macOS. A Keychain can contain various types of data: passwords (for websites, FTP servers, SSH accounts, network shares, wireless networks, groupware applications, encrypted disk images), private keys, certificates, and secure notes.

Keychains were initially developed for Apple's e-mail system, PowerTalk, in the early 1990s. Among its many features, PowerTalk used plug-ins that allowed mail to be retrieved from a wide variety of mail servers and online services. The keychain concept naturally "fell out" of this code, and was used in PowerTalk to manage all of a user's various login credentials for the various e-mail systems PowerTalk could connect to.

The passwords were not easily retrievable due to the encryption, yet the simplicity of the interface allowed the user to select a different password for every system without fear of forgetting them, as a single password would open the file and return them all. At the time, implementations of this concept were not available on other platforms. Keychain was one of the few parts of PowerTalk that was obviously useful "on its own", which suggested it should be promoted to become a part of the basic Mac OS. But due to internal politics, it was kept inside the PowerTalk system and, therefore, available to very few Mac users.[citation needed]

It was not until the return of Steve Jobs in 1997 that Keychain concept was revived from the now-discontinued PowerTalk. By this point in time the concept was no longer so unusual, but it was still rare to see a keychain system that was not associated with a particular piece of application software, typically a web browser. Keychain was later made a standard part of Mac OS 9, and was included in Mac OS X in the first commercial versions.

The keychain database is encrypted per-table and per-row with AES-256-GCM. The time at which each credential is decrypted, how long it will remain decrypted, and whether the encrypted credential will be synced to iCloud varies depending on the type of data stored, and is documented on the Apple support website.[4]

The default keychain file is the login keychain, typically unlocked on login by the user's login password, although the password for this keychain can instead be different from a user's login password, adding security at the expense of some convenience.[5] The Keychain Access application does not permit setting an empty password on a keychain.

There was a 3rd party software application developed, that enabled synchronization of personal keychains generated using keychain access in Mac OS X, these standard keychain access - generated users keychains could then be synchronised between devices (iPhones - desktop Apple computers), using a pair of keychain synchronization apps developed by Patrick Stein of Jinx Software, one for Mac OS X and another for iOS called Keychain2Go. Keychain2Go could not be successfully updated by the developer to account for restrictions that Apple made to Keychain and access to Keychain in Mac OS X Sierra 10.12.[7]

Keychain is distributed with both iOS and macOS. The iOS version is simpler because applications that run on mobile devices typically need only very basic Keychain features. For example, features such as ACLs (Access Control Lists) and sharing Keychain items between different apps are not present. Thus, iOS Keychain items are only accessible to the app that created them.

In 2019, 18-year-old German security researcher Linus Henze demonstrated his hack, dubbed KeySteal, that grabs passwords from the Keychain. Initially, he withheld details of the hack, demanding Apple set up a bug bounty for macOS. Apple had however not done so when Henze subsequently revealed the hack. It utilized Safari's access to security services, disguised as a utility in macOS that enables IT administrators to manipulate keychains.[8]

We have reoccurring issues where most users can't successfully update their keychain after their AD password has been updated. You've probably heard this one before, so let me explain a few twists in my circumstances.

Whenever a user changes their password, at some random point they will be prompted to update their keychain. I've instructed users to always, always, always select "update" and not "create new", however, it's very rare a user is able to update their keychain on their own successfully. Many users swear up and own that they had my instructions right in front of them as they attempted to update their keychain, but that selecting "update" instead of "create new" did not help. Although it's still possibly a user training issue, I've completely failed over the past several years to train anyone on how to avoid this problem, so I don't think more user training is the way forward.

c80f0f1006