Category Archives: Tutorial

These are posts that include how-to’s that will educate, step by step, as to how to accomplish a given security goal.

Link

Now that we have enough details about how the >NSA eavesdrops on the Internet, including today\’s disclosures of the NSA\’s deliberate weakening of cryptographic systems, we can finally start to figure out how to protect ourselves.
For the past two weeks, I have been working with the Guardian on NSA stories, and have read hundreds of top-secret NSA documents provided by whistleblower Edward Snowden. I wasn\’t part of today\’s story — it was in process well before I showed up — but everything I read confirms what the Guardian is reporting.
At this point, I feel I can provide some advice for keeping secure against such an adversary.

via Schneier on Security: How to Remain Secure Against the NSA.

I’m split preparing for presenting at Madison, Wisconsin’s Nerd Nite on October 30, 2013. Schneier covers several important notes as to how to handle security in general against a state-level actor, but the lessons are useful to implement in general.

Lesson three in particular is valuable. If you assume someone CAN be listening to your activity, it is easier to avoid doing something stupid. Where you should be worried about being discovered, act on those fears. Air gaps or one-way network connections can protect confidential information better than any firewall.

Wireless Security

One of the weakest points of personal home security is in Wi-FI. There also have not been any new security standards released since 2004’s 802.11i. Unfortunately, routers sold today still make available security settings that are dangerously antiquated even compared to that. As with all things in security, attacks only get better.

The article on Wi-Fi security standards above lists most of the standards and defenses. For simplicity’s sake, we will quickly go through those that should not be used at all.

  • WEP-based encryption is so easily broken that at this point it should be considered only marginally better than having no protection at all. Here is an example of how to break WEP-based security, for instance.
  • WPA, while offering substantial improvement over WEP, is also considered insecure due to the algorithms involved.
  • Hiding your SSID (the name of your wireless network) is sometimes used. I personally turned it on for a short time, but it is problematic for two reasons. First, your network is still broadcasting the name in many packets, as is the client. Second, it violates the 802.11 standard, and any time that happens with technology there can be interoperability concerns.
  • Filtering based on MAC also offers minimal help. This is because changing your wireless device’s MAC is trivially easy. Given that, attackers can just listen to packets to see who is authenticating successfully, and then copy that MAC.

With those dealt with, we can look at options that should be considered.

  • WPA2 Personal should be used minimally for the network.
  • If you are creating a business network, you should be using WPA2 Enterprise. It offers the ability to create keys for individuals and know which users are on what devices, and if any suspicious activity is detected have a place to investigate from. It also allows you to terminate that user’s certificate without changing the password on several routers.
  • Hardware tokens, smart cards, and other similar tools (such as RSA) can be used in some environments with extensive work to add rotating, per-user encryption. If your needs justify this, however, you should have full-time staff working to implement and administer the solution.

Additional layers can and should be added to whatever choice is made above. Options for doing so include encryption technologies such as SSH or VPN access. This way, it adds one more compromise in order for traffic to be deciphered.

While all of these help, it does not guarantee safety. There is at least one known attack against WPA2, known as Hole196. This allows users of the same network to gain access to what should be secure traffic or create a denial-of-service condition. There are also tools for gaining illicit access to a Wi-Fi network. Cracking a WPA2 Wi-Fi password can take several hours or more, but given that passwords may remain for years an attacker can stand to wait.

In the event that your paranoia has been justifiably turned on (for instance you are concerned about state-level actors or targeted penetration attacks)…why are you even enabling Wi-Fi? While you could use RF shielding paint or Faraday cages to contain your broadcasts to a certain physical area with some level of certainty, going to only wired connections with other security measures enabled is your best choice.

Cryptolocker and Handling Malware Generally (This Means Backups!)

I received a request to discuss the cryptolocker family of malware, and will be talking about that today. If there are any other topics that are requested to be covered, please leave a comment below or contact me. This form of malware falls generally under the ransomware category, which installs itself and then demands money for one reason or another in exchange for removal. Sometimes it is because it claims you have violated the law, and it is a fine to remove it. In this case, it instead encrypts data off of your hard drive using a public-key cryptographic setup that appears to be well designed, and at least appears to legitimately offer a hope for decryption if it is paid.

Encryption is Hard™, and it is the mistakes in designing cryptographic software that is easier to break than the theory that is implemented. In this case, however, no obvious flaws have been found. This does not mean that I encourage payment of the ransom. Like all ransoms, you have no reason to trust whoever created the malware. Payment only encourages them to ask for more, and the key could be discarded as soon as the files are encrypted.

More realistically, if you see this malware appear on your system, you have two hopes. First, this is the “cheap” form, which will not actually encrypt your system but instead hide all your files and pretend to. Removing the malware will make your system function again. You can use your typical form of antivirus, or something like malwarebytes. Secondly, you of course have good backups, right? Many infestations come in large packages now, containing various malware to do different tasks such as keylogging or changing your DNS server to point you towards what they control for ad clicks or prevent you from obtaining software updates. When you discover malware on your system, at that point you do not know what else is wrong. A full system reinstall is the best solution, and the only way to guarantee things are fixed, assuming you also are sure your backups are clean as well.

Therefore, if you want to be sure about your security, be sure about your backups. For my system I use duplicity, and it ties in well with my previous instructions on personal encryption. I have it doing daily backups, which are incremental (so it only adds what is new from the previous day’s work), and then a full backup every week. My crontab and backup scripts are below:

# m h  dom mon dow   command
0 5 * * 2-7    /home/USER/.duplicity/duplicity_daily
0 5 * * 1    /home/USER/.duplicity/duplicity_weekly
#!/bin/sh
test -x $(which duplicity) || exit 0
$(which duplicity) --encrypt-key GPG_KEY --exclude /home/USER/.gvfs /home/USER file:///data/backups/USER
#!/bin/sh
test -x $(which duplicity) || exit 0
$(which duplicity) full --encrypt-key GPG_KEY --exclude /home/USER/.gvfs /home/<USER> file:///data/backups/USER
$(which duplicity) remove-all-but-n-full 3 --force file:///data/backups/USER

For each of the above, you would replace “<USER>” with your username, and “<GPG_KEY>” with your encryption public key.

Securing SSH

In the Linux world, SSH is the network protocol used for secure communication between machines. Through it, both remote access and individual commands can be sent. As a result, it is one of the most important parts of the infrastructure to secure.

For SSH, there are two system-wide configuration files. The first is in /etc/ssh/sshd_config, and handles the server, or incoming connections. The second is located at /etc/ssh/ssh_config and manages clients, or outgoing connections. Each of the following configuration settings are important to helping improve the security of a ssh server. This will be done by running the following command:

sudo vim /etc/ssh/sshd_config

First, we want to be sure we are only using version 2 of the ssh protocol. Version 1 has numerous known security problems and should be not used anywhere without very specific backwards compatibility needs, and even then only while working to migrate to version 2. To do so, you set the following settings in the configuration file.

Protocol 2

Second, you should disable root logins. This ensures that anyone connecting has to know a username to log in, and prevents anyone from having simple access to everything.

PermitRootLogin no

Third, we will increase the server key size. Generally, the more bits for the key the harder to compromise it later. This is done by changing the setting of

ServerKeyBits 758

to

ServerKeyBits 4096

Once that is complete, you will also need to run the following commands to regenerate the keys:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server

Fourth, you want to disable password-based login. You ONLY want to do this one you have set up and confirmed the functionality of your key-based login. Otherwise, you may find yourself unable to log in anymore. When you are ready to proceed, you will modify the following setting:

PasswordAuthentication no
ChallengeResponseAuthentication no

Fifth, unless you what sftp is, and plan to use it, you should disable it. You do so by finding and commenting out the line below.

#Subsystem sftp /usr/lib/openssh/sftp-server

Sixth, you will want to restrict which users can log in via SSH. You can list who is granted such ability either by username or by group. I personally go by the username option.

AllowUsers

Finally, you need to restart the SSH server in order for the configuration to be re-read. The method by which you do so varies from distribution to distribution, but on Debian you use the following command:

sudo service ssh restart

When all of those configurations are set, your configuration will look like this:

# What ports, IPs and protocols we listen for
Port 22
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 4096

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 30
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
ChallengeResponseAuthentication no

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
MaxStartups 10:30:60

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# Uncomment following line to enable sftp server
#Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

# Lock down to only allow certain users
AllowUsers

In addition to the changes above in SSHD configuration, there are other possibilities you can use. Some people suggest moving the port that the SSH server listens on from 22, but that does not particularly add much. It protects against some brute force scanners, but when you are no longer using password authentication your protection does not rely on hiding the server.

Other tools can also be used to add protection. I highly encourage installing denyhosts as well, as it will prevent rapid attacks. You can also configure it to download lists of addresses that attacks are being detected from. The system firewall as well as TCP Wrappers can be used to only allow specific computers to be valid to use the SSH server.

With these modifications, a SSH server is much more secure against attack. The configuration above should be a bare-minimum, and additional protections should be added as specifics require.

Basic Technology Security

For many people, there are simple tricks that can dramatically improve their security posture. These either remove the common entry points for attackers, or add additional barriers against their attackers. Combined, they are the easiest technical methods available.

The first, and most basic of options, is to ALWAYS have the current version of all software you use installed. If you are on Windows, Microsoft has a  regular schedule for releasing updates. You should even have automatic updates enabled if possible. Adobe also follows this schedule, and Reader updates should be just as important as those Microsoft patches. Same goes for Apple and OSX updates, and the maintainers of various Linux distributions, although the tools to do these updates vary. Check in your system documentation.

Secondly, remove the software you do not use. If you cannot name the reason why you have Java installed, for instance, uninstall it. All it does is add a  major vector for attacks. This goes for any software. If you’re not using it, remove it.

Thirdly, be sure to install and configure a firewall. This is the last barrier against outside attackers, and you want to be sure you are only letting in what you intend to. Create as narrow of exceptions as possible, and look for configuration suggestions for your use case. Remember you don’t need to open ports to browse the internet, unless you are blocking inbound and outbound traffic.

Forth, have good antivirus installed. I honestly find this less important than the first three, just because reducing your exposed surface ends up being far more useful. While anti-malware software and firewalls definitely should be exposed, they can and will miss things. There are plenty of free options for antivirus, although I usually direct people to  AVG on Windows. Microsoft Security Essentials is also a decent choice. No matter your operating system, however, you need to have something installed. With cross-platform malware such as java or pdf-based exploits, and growing desire for mobile attacks, assume that there is something out there.

Fifth, have good password security. Use a strong password to log into your system. Do not use an account with administrative access for everyday activity, to prevent malware from gaining a strong foothold if it gets onto your system. I’ve talked about this previously, but also use a password manager. Generate unique passwords for every single site, it protects you if one of those sites are cracked. Remember if you use the same password everywhere, your bank security depends on the security of that crappy forum you joined.

Finally, where it is available use use two-factor authentication. This is far from foolproof, and there are ways around it, but it stops the cheap attacks used to gain access to your email, your bank, social networking, and more. It also typically protects against repeated incursion on those accounts.

The combination of all of these tools creates an multi-layer protection that is far better than most people have. If any of these are missing, it creates a hole that can be exploited. Together, you will find yourself avoiding many of the greatest pitfalls and be far ahead of others.

Setting up GPG

One of the cornerstones of my home infrastructure is GPG. GPG is an encryption/signing/authentication tool, and is used for all three purposes in my network. I use it for SSH connections (authentication), my password store (encryption/decryption), and signing emails.  For added security, this is done via a smart card purchased from kernel concepts. My personal machine is a Lenovo T420, and I use the embedded card reader.

Setting up the card with current versions of GPG (2.0.21 as of today) is different from most tutorials you can find. This is due to GPG versions 2.0.18 and later supporting 4096 bit keys for the kernel concept smart card. Before you start configuring the card, you need to install all necessary software. For me, that is:

gpg2, gpgsm, pcscd, gnupg-agent

Once those are installed, you can begin to create your keys. While these instructions assume you have a smart card, they will work with minimal effort even absent one.

USERNAME@phoenix ~ % gpg --card-status 
Application ID ...: D276000124010200000500001ABD0000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 00001ABD
Name of cardholder: [not set]
Language prefs ...: en
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Your smart card information should look similar to this. First, here’s some important safety information: The card accepts up to three wrong PINs in a row and then block, until unblocked by the admin PIN. Three wrong admin PINs and your card bricks itself, to prevent access to the information. Don’t do this, unless you need to know that the information has to be destroyed.

Now we’ll begin to edit the smart card. With your card, you can either transfer pre-existing keys to the card, or generate new ones. I am going to generate keys on the card, as demonstrated below.

USERNAME@phoenix ~ % gpg --card-edit                        

Application ID ...: D276000124010200000500001ABD0000
Version ..........: 2.0
Manufacturer .....: ZeitControl
Serial number ....: 00001ABD
Name of cardholder: [not set]
Language prefs ...: en
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

Command> admin
Admin commands are allowed

Command> name
Cardholder's surname: O'Connell
Cardholder's given name: Patrick
gpg: 3 Admin PIN attempts remaining before card is permanently locked

Admin PIN
gpg: gpg-agent is not available in this session

Command> lang
Language preferences: en

Command> sex
Sex ((M)ale, (F)emale or space): m

gpg/card> generate 

Admin-only command

gpg/card> admin
Admin commands are allowed

gpg/card> generate
Make off-card backup of encryption key? (Y/n) y

What keysize do you want for the Signature key? (2048) 4096
The card will now be re-configured to generate a key of 4096 bits
NOTE: There is no guarantee that the card supports the requested size.
      If the key generation does not succeed, please check the
      documentation of your card to see what sizes are allowed.
What keysize do you want for the Encryption key? (2048) 4096
The card will now be re-configured to generate a key of 4096 bits
What keysize do you want for the Authentication key? (2048) 4096
The card will now be re-configured to generate a key of 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a <a class="zem_slink" title="User identifier" href="http://en.wikipedia.org/wiki/User_identifier" target="_blank" rel="wikipedia">user ID</a> to identify your key.

Real name: Patrick O'Connell
Email address: pat@aeriagloris.net
Comment: 
You selected this USER-ID:
    "Patrick O'Connell <pat@aeriagloris.net>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

You need a Passphrase to protect your secret key.

gpg: NOTE: backup of card key saved to `/home//.gnupg/sk_16A65751AA333CD9.gpg'
gpg: key F7D12196 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
pub   4096R/F7D12196 2013-09-22
      Key fingerprint = 0059 EA3C CC54 D92F E203  DE29 12F2 C901 F7D1 2196
uid                  Patrick O'Connell <pat@aeriagloris.net>
sub   4096R/43DDE8B2 2013-09-22
sub   4096R/AA333CD9 2013-09-22

gpg/card> quit

With those initial keys set up, we can now configure some settings. The first we want to get to is changing the preferences for how to do signatures.

USERNAME@phoenix [2] ~ % gpg --edit-key pat@aeriagloris.net 
gpg (GnuPG) 2.0.21; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/14F0F412  created: 2013-07-27  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/61DBC4A3  created: 2013-07-27  expires: never       usage: A   
sub  2048R/2081E3C6  created: 2013-07-27  expires: never       usage: E   
[ultimate] (1). Patrick O'Connell <pat@aeriagloris.net>

gpg> uid 1

pub  2048R/14F0F412  created: 2013-07-27  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  2048R/61DBC4A3  created: 2013-07-27  expires: never       usage: A   
sub  2048R/2081E3C6  created: 2013-07-27  expires: never       usage: E   
[ultimate] (1)* Patrick O'Connell <pat@aeriagloris.net>

gpg> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Set preference list to:
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences for the selected user IDs? (y/N) y

pub  4096R/F7D12196  created: 2013-09-22  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/43DDE8B2  created: 2013-09-22  expires: never       usage: A   
sub  4096R/AA333CD9  created: 2013-09-22  expires: never       usage: E   
[ultimate] (1)* Patrick O'Connell <pat@aeriagloris.net>

gpg> save
USERNAME@phoenix ~ %

You can now add any other uids you need to your key. This can be done with the edit-keys command followed by the adduid command.

USERNAME@phoenix ~ % gpg --edit-key pat@aeriagloris.net
gpg (GnuPG) 2.0.21; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/F7D12196  created: 2013-09-22  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/43DDE8B2  created: 2013-09-22  expires: never       usage: A   
sub  4096R/AA333CD9  created: 2013-09-22  expires: never       usage: E   
[ultimate] (1). Patrick O'Connell <pat@aeriagloris.net>

gpg> adduid 
Real name: Patrick O'Connell
Email address: 
Comment: 
You selected this USER-ID:
    "Patrick O'Connell "

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

pub  4096R/F7D12196  created: 2013-09-22  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/43DDE8B2  created: 2013-09-22  expires: never       usage: A   
sub  4096R/AA333CD9  created: 2013-09-22  expires: never       usage: E   
[ultimate] (1)  Patrick O'Connell <pat@aeriagloris.net>
[ unknown] (2). Patrick O'Connell 

gpg>  save
USERNAME@phoenix ~ %

Initializing the card generated both authentication and encryption subkeys, and the next stage is to add a separate signing subkey. Subkeys are keys that cannot sign other keys, but depend on the initial keys set up for their trust. These are used to avoid having to use the ultimately trusted key everywhere. This also helps demonstrate how to add other subkeys later, if needed.

USERNAME@phoenix ~ % gpg --edit-key pat@aeriagloris.net
gpg (GnuPG) 2.0.21; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub  4096R/F7D12196  created: 2013-09-22  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/43DDE8B2  created: 2013-09-22  expires: never       usage: A   
sub  4096R/AA333CD9  created: 2013-09-22  expires: never       usage: E   
[ultimate] (1). Patrick O'Connell 
[ultimate] (2)  Patrick O'Connell <pat@aeriagloris.net>

gpg> uid 2

pub  4096R/F7D12196  created: 2013-09-22  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/43DDE8B2  created: 2013-09-22  expires: never       usage: A   
sub  4096R/AA333CD9  created: 2013-09-22  expires: never       usage: E   
[ultimate] (1). Patrick O'Connell 
[ultimate] (2)* Patrick O'Connell <pat@aeriagloris.net>

gpg> addkey 
Secret parts of primary key are stored on-card.
Please select what kind of key you want:
   (3) DSA (sign only)
   (4) RSA (sign only)
   (5) Elgamal (encrypt only)
   (6) RSA (encrypt only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
        = key expires in n days
      w = key expires in n weeks
      m = key expires in n months
      y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
You need a Passphrase to protect your secret key.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.

pub  4096R/F7D12196  created: 2013-09-22  expires: never       usage: SC  
                     trust: ultimate      validity: ultimate
sub  4096R/43DDE8B2  created: 2013-09-22  expires: never       usage: A   
sub  4096R/AA333CD9  created: 2013-09-22  expires: never       usage: E   
sub  4096R/31FED8A5  created: 2013-09-22  expires: never       usage: S   
[ultimate] (1). Patrick O'Connell 
[ultimate] (2)* Patrick O'Connell <pat@aeriagloris.net>

gpg> save
USERNAME@phoenix ~ %

The next step, and critical to the security of the entire GPG infrastructure, is creating revocation certificates. These can be posted to GPG key servers to announce that you cannot trust them anymore, typically if you lose physical control over your smart card. This is the only possible way to revoke the trust of a certificate, so do not skip this step!

USERNAME@phoenix ~ % gpg --output pat@aeriagloris.net.gpg-revocation-certificate --gen-revoke pat@aeriagloris.net  

sec  4096R/F7D12196 2013-09-22 Patrick O'Connell <pat@aeriagloris.net>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 0
Enter an optional description; end it with an empty line:
> 
Reason for revocation: No reason specified
(No description given)
Is this okay? (y/N) y
ASCII armored output forced.
Revocation certificate created.Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
USERNAME@phoenix ~ %

Next, we will upload our GPG key to remote key servers. This allows for people to gain access to our public keys, and is necessary if anyone is going to send us encrypted information, or give us access via our authentication keys. For this I will just send you to the GPG instructions as to how to do so, in case they change in future versions.

Now, we can start actually using the keys we have just generated. First, lets set up SSH. For SSH, using a key is the only way I recommend connections. You do not want to allow password authentication to any machine you control. Additionally, you want to only be able to log in with a non-root user, and then authenticate to higher permissions. There is countless documentation as to why this is true, but in general someone is going to be able to crack your passwords far easier than any key-based login. We will use our authentication subkey, which for me is 43DDE8B2. The following commands, run on a remote machine, would immediately allow us to gain immediate SSH access to that machine.

USERNAME@phoenix ~ % gpg --recv-key 43DDE8B2
USERNAME@phoenix ~ % gpgkey2ssh 43DDE8B2 >> ~/.ssh/authorized_keys
USERNAME@phoenix ~ %

As for the password store, password managers are useful and allow for much easier management of per-account passwords. I do not re-use passwords between websites, which is always nice when you find out that a service has been compromised, I do not have to scurry around and figure out what websites I need to change things for. What I like most about using zx2c4’s Pass for this is that it integrates with GPG. Trust doesn’t have to be given to another service, nor do I need to embed any other plugins.

This sets up a fairly sound foundation for future work, such as enabling automatic GPG signing or encryption of email. It also encourages you to use more secure passwords for other services, and prevents security incident avalanches.