Wednesday, 24 May 2017

An overview of UEFI Secure Boot on Ubuntu

Secure Boot is here

Ubuntu has now supported UEFI booting and Secure Boot for long enough that it is available, and reasonably up to date, on all supported releases. Here is how Secure Boot works.

An overview

I'm including a diagram here; I know it's a little complicated, so I will also explain how things happen (it can be clicked to get to the full size image).


In all cases, booting a system in UEFI mode loads UEFI firmware, which typically contains pre-loaded keys (at least, on x86). These keys are usually those from Microsoft so that Windows can load its own bootloader and verify it, as well as those from the computer manufacturer. The firmware doesn't, by itself, know anything special about how to boot the system -- this is something that is informed by NVRAM (or some similar memory that survives a reboot) by way of a few variables: BootOrder, which specified what order to boot things in, as well as BootEntry#### (hex numbers), which contains the path to the EFI image to load, a disk, or some other method of starting the computer (such as booting in the Setup tool for that firmware). If no BootEntry variable listed in BootOrder gets the system booting, then nothing would happen. Systems however will usually at least include a path to a disk as a permanent or default BootEntry. Shim relies on that, or on a distro, to load in the first place.

Once we actually find shim to boot; this will try to validate signatures of the next piece in the puzzle: grub2, MokManager, or fallback, depending on the state of shim's own variables in NVRAM; more on this later.

In the usual scenario, shim will validate the grub2 image successfully, then grub2 itself will try to load the kernel or chainload another EFI binary, after attempting to validate the signatures on these images by way of asking shim to check the signature.

Shim

Shim is just a very simple layer that holds on to keys outside of those installed by default on the system (since they normally can't be changed outside of Setup Mode, and require a few steps to do), and knows how to load grub2 in the normal case, as well as how to load MokManager if policy changes need to be applied (such as disabling signature validation or adding new keys), as well as knowing how to load the fallback binary which can re-create BootEntry variables in case the firmware isn't able to handle them. I will expand on MokManager and fallback in a future blog post.

Your diagram says shim is signed by Microsoft, what's up with that?

Indeed, shim is an EFI binary that is signed by Microsoft how we ship it in Ubuntu. Other distributions do the same. This is required because the firmware on most systems already contains Microsoft certificates (pre-loaded in the factory), and it would be impractical to have different shims for each manufacturer of hardware. All EFI binaries can be easily re-signed anyway, we just do things like this to make it as easy as possible for the largest number of people.

One thing this means is that uploads of shim require a lot of effort and testing. Fortunately, since it is used by other distributions too, it is a well-tested piece of code. There is even now a community process to handle review of submissions for signature by Microsoft, in an effort to catch anything outlandish as quickly and as early as possible.

Why reboot once a policy change is made or boot entries are rebuilt?

All of this happens through changes in firmware variables. Rebooting makes sure we can properly take into account changes in the firmware variables, and possibly carry on with other "backlogged" actions that need to happen (for instance, rebuilding BootEntry variables first, and then loading MokManager to add a new signing key before we can load a new grub2 image you signed yourself).

Grub2

grub2 is not a new piece of the boot process in any way. It's been around for a long while. The difference from booting in BIOS mode compared to in UEFI is that we install an UEFI binary version of grub2. The software is the same, just packaged slightly differently (I may outline the UEFI binary format at some point in the future). It also goes through some code paths that are specific to UEFI, such as checking if we've booting through shim, and if so, asking it to validate signatures. If not, we can still validate signatures, but we would have to do so using the UEFI protocol itself, which is limited to allowing signatures by keys that are included in the firmware, as expressed earlier. Mostly just the Microsoft signatures.

grub2 in UEFI otherwise works just like it would elsewhere: it try to find its grub.cfg configuration file, and follow its instructions to boot the kernel and load the initramfs.

When Secure Boot is enabled, loading the kernel normally requires that the kernel itself is signed. The kernels we install in Ubuntu are signed by Canonical, just like grub2 is, and shim knows about the signing key and can validate these signatures.

At the time of this writing, if the kernel isn't signed or is signed by a key that isn't known, grub2 will fall back to loading the kernel as a normal binary (as in not signed), outside of BootServices (a special mode we're in while booting the system, normally it's exited by the kernel early on as the kernel loads). Exiting BootServices means some special features of the firmware are not available to anything that runs afterwards, so that while things may have been loaded in UEFI mode, they will not have access to everything in firmware. If the kernel is signed correctly, then grub2 leaves the ExitBootServices call to be done by the kernel.

Very soon, we will stop allowing to load unsigned (or signed by unknown keys) kernels in Ubuntu. This is work in progress. This change will not affect most users, only those who build their own kernels. In this case, they will still be able to load kernels by making sure they are signed by some key (such as their own, and I will cover signing things in my next blog entry), and importing that key in shim (which is a step you only need to do once).

The kernel

In UEFI, the kernel enforces that modules loaded are properly signed. This means that for those who need to build their own custom modules, or use DKMS modules (virtualbox, r8168, bbswitch, etc.), you need to take more steps to let the modules load properly.

In order to make this as easy as possible for people, for now we've opted to let users disable Secure Boot validation in shim via a semi-automatic process. Shim is still being verified by the system firmware, but any piece following it that asks shim to validate something will get an affirmative response (ie. things are valid, even if not signed or signed by an unknown key). grub2 will happily load your kernel, and your kernel will be happy to load custom modules. This is obviously not a perfectly secure solution, more of a temporary measure to allow things to carry on as they did before. In the future, we'll replace this with a wizard-type tool to let users sign their own modules easily. For now, signature of binaries and modules is a manual process (as above, I will expand on it in a future blog entry).

Shim validation

To toggle shim validation, if you were using DKMS packages and feel you'd really prefer to have shim validate everything (but be aware that if your system requires these drivers, they will not load and your system may be unusable, or at least whatever needs that driver will not work):
sudo update-secureboot-policy --enable
If nothing happens, it's because you already have shim validation enabled: nothing has required that it be disabled. If things aren't as they should be (for instance, Secure Boot is not enabled on the system), the command will tell you.

And although we certainly don't recommend it, you can disable shim validation yourself with much the same command (see --help). There is an example of use of update-secureboot-policy here.

Tuesday, 23 May 2017

ss: another way to get socket statistics

In my last blog post I mentioned ss, another tool that comes with the iproute2 package and allows you to query statistics about sockets. The same thing that can be done with netstat, with the added benefit that it is typically a little bit faster, and shorter to type.

Just ss by default will display much the same thing as netstat, and can be similarly passed options to limit the output to just what you want. For instance:

$ ss -t
State       Recv-Q Send-Q       Local Address:Port                        Peer Address:Port              
ESTAB       0      0                127.0.0.1:postgresql                     127.0.0.1:48154              
ESTAB       0      0            192.168.0.136:35296                      192.168.0.120:8009                
ESTAB       0      0            192.168.0.136:47574                     173.194.74.189:https
[...]

ss -t shows just TCP connections. ss -u can be used to show UDP connections, -l will show only listening ports, and things can be further filtered to just the information you want.

I have not tested all the possible options, but you can even forcibly close sockets with -K.

One place where ss really shines though is in its filtering capabilities. Let's list all connections with a source port of 22 (ssh):

$ ss state all sport = :ssh
Netid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port              
tcp   LISTEN     0      128                    *:ssh                                  *:*                  
tcp   ESTAB      0      0          192.168.0.136:ssh                      192.168.0.102:46540              
tcp   LISTEN     0      128                   :::ssh                                 :::* 
And if I want to show only connected sockets (everything but listening or closed):

$ ss state connected sport = :ssh
Netid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port              
tcp   ESTAB      0      0          192.168.0.136:ssh                      192.168.0.102:46540 

Similarly, you can have it list all connections to a specific host or range; in this case, using the 74.125.0.0/16 subnet, which apparently belongs to Google:

$ ss state all dst 74.125.0.0/16
Netid State      Recv-Q Send-Q     Local Address:Port                      Peer Address:Port              
tcp   ESTAB      0      0          192.168.0.136:33616                   74.125.142.189:https              
tcp   ESTAB      0      0          192.168.0.136:42034                    74.125.70.189:https              
tcp   ESTAB      0      0          192.168.0.136:57408                   74.125.202.189:https
        
This is very much the same syntax as for iptables, so if you're familiar with that already, it will be quite easy to pick up. You can also install the iproute2-doc package, and look in /usr/share/doc/iproute2-doc/ss.html for the full documentation.

Try it for yourself! You'll see how well it works. If anything, I'm glad for the fewer characters this makes me type.

Tuesday, 9 May 2017

If you're still using ifconfig, you're living in the past

The world evolves

I regularly see "recommendations" to use ifconfig to get interface information in mailing list posts or bug reports and other places. I might even be guilty of it myself. Still, the world of networking has evolved quite a lot since ifconfig was the de-facto standard to bring up a device, check its IP or set an IP.

Following some improvements in the kernel and the gradual move to driving network things via netlink; ifconfig has been largely replaced by the ip command.

Running just ip yields the following:

Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
       ip [ -force ] -batch filename
where  OBJECT := { link | address | addrlabel | route | rule | neigh | ntable |
                   tunnel | tuntap | maddress | mroute | mrule | monitor | xfrm |
                   netns | l2tp | fou | macsec | tcp_metrics | token | netconf | ila }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
                    -h[uman-readable] | -iec |
                    -f[amily] { inet | inet6 | ipx | dnet | mpls | bridge | link } |
                    -4 | -6 | -I | -D | -B | -0 |
                    -l[oops] { maximum-addr-flush-attempts } | -br[ief] |
                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] |
                    -rc[vbuf] [size] | -n[etns] name | -a[ll] | -c[olor]}

I understand this may look complicated to some people, but the jist of it is to understand that with ip, you interact with objects, and apply some kind of function to it. For example:

ip address show

This is the main command that would be used in place of ifconfig. It will just display the IP addresses assigned to all interfaces. To be precise, it will show you the layer 3 details the interface: the IPv4 and IPv6 addresses, whether it is up, what are the different properties related to the addresses...

Another command will give you details about the layer 2 properties of the interface: its MAC address (ethernet address), etc; even if it is shown by ip address:

ip link show

Furthermore, you can set devices up or down (similar to ifconfig eth0 up or ifconfig eth0 down) simply by using:

ip link set DEVICE up or ip link set DEVICE down

As shown above, there are lots of other objects that can be interacted with using the ip command. I'll cover another: ip route, in another post.

Why is this important?

As time passes, more and more features are becoming easier to use with the ip command instead of with ifconfig. We've already stopped installing ifconfig on desktops (it still gets installed on servers for now), and people have been discussing dropping net-tools (the package that ships ifconfig and a few other old commands that are replaced) for a while now. It may be time to revisit not installing net-tools by default anywhere.

I want to know about your world

Are you still using one of the following tools?

/bin/netstat    (replaced by ss, for which I'll dedicate another blog post entirely)
/sbin/ifconfig
/sbin/ipmaddr   (replaced by ip maddress)
/sbin/iptunnel
/sbin/mii-tool    (ethtool should appropriately replace it)
/sbin/nameif
/sbin/plipconfig
/sbin/rarp
/sbin/route
/sbin/slattach

If so and there is just no alternative to using them that comes from iproute2 (well, the ip or ss commands) that you can use to do the same, I want to know about how you are using them. We're always watching for things that might be broken by changes; we want to avoid breaking things when possible.

Friday, 5 May 2017

Quick and easy network configuration with Netplan

Earlier this week I uploaded netplan 0.21 in artful, with SRUs in progress for the stable releases. There are still lots of features coming up, but it's also already quite useful. You can already use it to describe typical network configurations on desktop and servers, all the way to interesting, complicated setups like bond over a bridge over multiple VLANs...

Getting started

The simplest netplan configuration might look like this:

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
At boot, netplan will see this configuration (which happens to be installed already on all new systems since 16.10) and generate a single , empty file: /run/NetworkManager/conf.d/10-globally-managed-devices.conf. This tells the system that NetworkManager is the only renderer for network configuration on the system, and will manage all devices by default.

Working from there: a simple server

Let's look at it on a hypothetical web server; such as for my favourite test: www.perdu.com.

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
This incredibly simple configuration tells the system that the eth0 device is to be brought up using DHCP4. Netplan also supports DHCPv6, as well as static IPs, setting routes, etc.


Building up to something more complex

Let's say I want a team of two NICs, and use them to reach VLAN 108 on my network:

            network:
              version: 2
              ethernets:
                eth0:
                  dhcp4: n
                eth1:
                  mtu: 1280
                  dhcp4: n
              bonds:
                bond0:
                  interfaces:
                  - eth1
                  - eth0
                  mtu: 9000
              vlans:
                bond0.108:
                  link: bond0
                  id: 108

I think you can see just how simple it is to configure even pretty complex networks, all in one file. The beauty in it is that you don't need to worry about what will actually set this up for you.

A choice of backends

Currently, netplan supports either NetworkManager or systemd-networkd as a backend. The default is to use systemd-networkd, but given that it does not support wireless networks, we still rely on NetworkManager to do just that.

This is why you don't need to care what supports your config in the end: netplan abstracts that for you. It generates the required config based on the "renderer" property, so that you don't need to know how to define the special device properties in each backend.

As I mentioned previously, we are still hard at work adding more features, but the core is there: netplan can set up bonds, bridges, vlans, standalone network interfaces, and do so for both static or DHCP addresses. It also supports many of the most common bridge and bond parameters used to tweak the precise behaviour of bonded or bridged devices.


Coming up...

I will be adding proper support for setting a "cloned" MAC on a device. I'm reviewing the code already to do this, and ironing out the last issues.

There are also plans on better handling administrative states for devices; along with a few bugs that relate to support MaaS, where having a simple configuration style really shines.

I'm really excited for where netplan is going. It seems like it has a lot of potential to address some of the current shortcomings in other tools. I'm also really happy to hear of stories of how it is being used in the wild, so if you use it, don't hesitate to let me know about it!

Contributing

All of the work on netplan happens on Launchpad. Its source code is at https://code.launchpad.net/netplan; we always welcome new contributions.

Thursday, 2 June 2016

Netflix, or the pains of dealing with royalties and DMCA

A few days ago, after enjoying the use of a pretty much static IP address for a long while from my ISP (it hadn't changed in easily a year), my IP changed. This took down my IPv6 tunnel, which I tend to use a lot to access to various services for work -- you know, dogfooding and all of that. My IPv6 address depends on a tunnel that needs to stay up (and for that requires my IPv4 address to not change too much, but whatever).

Probably since then (but I did not really notice until yesterday or so), I've had multiple issues with Netflix streaming. As many know, Netflix is now enforcing some method of trying to detect VPN and proxy users to force local content upon its users. I think it's a stupid idea, but I see where they come from with that decision.

Netflix has to deal with royalties, copyright, and varying laws depending on where a user might be. For instance, you may wish to watch NCIS -- this will likely depend on Netflix having paid CBS (or whomever the title belong to) to be allowed to present it to clients. I have no idea how these costs are done, they might well be a percentage based on number of viewers or some such.

In the US, this is relatively easy, they can deal with local companies and handle things. This becomes more complicated when you factor in different copyright laws in other countries, and exclusivity rights, etc. In the case of NCIS, Global appears to have (exclusive?) rights for NCIS, so they look to be the only legit place to stream episodes online. I suspect Netflix would possibly have to pay *them* to stream NCIS in Canada, or otherwise be subject to random other byzantine rules. I don't pretend to understand the intricacies past the one class I took on Canadian copyright/patent/IP law over a year ago. Suffice to say it's complicated, and there are probably good reasons to try and have users in country X watch country X's content, and not country Y's. It's likely to cut costs.

My issue stemmed from the fact that with the reset of my IPv4/IPv6 connection, or possibly just as a coincidence, Netflix started to care about my IPv6 addresses. It's possible that geoip data informed this, or that Netflix started to do more checking, or started to do proper IPv6, etc. I don't know.

I had an online chat with an awesome Netflix Customer Service rep; HecThor (the name is awesome too!), and received great service even if they could not help:


Netflix Customer Service
You are now chatting with: Hecthor
Netflix Hecthor
Hello!! My name is HecThor! How can I help?
You
Hi, I'm Matt, I keep getting error messages saying that I am behind a proxy or VPN when I am not
You
Would you be able to consult logs or whatever you might have to tell me why that has been detected so I can take the necessary steps?
Netflix Hecthor
Oh, let me check this out for you. Could you please tell me which device are you using?
You
Right now, my Chrome browser
You
probably listed as Chrome on linux, version 50.0.2661.94
You
I had the same issues on a different device too (another Chrome, version is most likely different as it is running on a Chromebook device)
Netflix Hecthor
Just a quick question, have you tried going to the extensions of Google Chrome and unchecked and tried Netflix one more time?
You
yes
You
what's more, this one does not have any extensions
Netflix Hecthor
Alright, just to confirm, are you using Linux?
You
not exclusively, but yes
Netflix Hecthor
Oh got it, I'm seeing here that the signal is being redirected to the US and then to Canada several times in a day, in this case the best thing to do is to check with your Internet Service Provider to investigate why your connection appears to come from a VPN or a proxy service, as they are in charge of the signal.
You
this is to be expected, I get IPv6 connectivity from a US provider for work purposes
You
could it be that you guys started to allow ipv6?
Netflix Hecthor
Oh got it, we do support with IPv6, however having the setting set to the US instead of Canada may cause this conflict , so in this case what I recommend is to turn it off and you'll be able to stream without a problem. :)
You
it's not the kind of thing I can turn off
You
there aren't providers here who do IPv6
You
is there any way for you to set my account to only use IPv4?
Netflix Hecthor
Got it, you see we don't have a way to set an account to use IPv4 or Ipv6 as this has to do with the Internet service, so in this case I would recommend you to contact them and try to reset the signal or check if they're able to do that change on your settings, I'm sure that once they do you'll be able to stream Netflix without a problem.
You
There is no thing to reset, there is no Canada endpoint for this thing.
You
in fact, it only started to be an issue since the last reset, because my IPv4 address changed a few days ago as well
Netflix Hecthor
I understand, and do you have a way so you can return to IPv4? The thing is that Netflix is working fine, however the system is detecting that your IP is constantly changing from region to region, this is why the system is not letting you stream.
You
I can't do this change on the local systems, no. This is how my home network is set up -- like I said, I do need IPv6 for my work. I work from home.
Netflix Hecthor
Oh I definitely understand what you mean, however, to be completely honest, the process you use will not let you stream. Unless you change that wont be able to stream, because when the system detects that you're in a country and your network shows another one, this issue appears, it might work some times but I can't guaranty it will always work, if you like you can try Netflix on your mobile's network to verify this.
You
I don't especially want to verify anything, since we have a fair expectation of what the issue is
You
you've been quite helpful
You
Do you object to me using this chat log for documentation purposes?
You
I can remove your name if you prefer, but I thought it looked badass enough ;)
Netflix Hecthor
Sure, no problem, and it's been a pleasure being able to help! :) Is there anything else I can do for you?

I went on to ask to file a complaint / provide feedback to the team, since Netflix should be aware of the complexity, and inconvenience this poses on its customers. Still, I want to reiterate that I was quite happy with the service I've had from Customer Support rep HecThor, who was helpful and understanding.

I'm technical enough to be able to deal with such issues in various ways. I did some searching, and it looks like you *can not* disable IPv6 simply for Chrome. It's also impractical to disable the IPv6 tunnel... I have it up for a good reason, and it had been working for a long while (that too, over a year) with no issues. Other people could also have other special network setups that could impede on Netflix steaming services. VPNs happen, and they are not all used to watch US content. They can also be done at the router level rather than at the device level; and even some ISPs require PPTP VPN use to get any kind of connectivity at all (or did in the past).

The inability to disable IPv6 in Chrome is probably really a usability bug in it, but it shows how the average user might eventually run into issues dealing with content "blocking" based on location. I'm not really expecting the average user to have a network setup like mine: I had to set up IPv6 myself here, as none of the providers in Canada do a satisfactory job at it. I also don't expect the average user to care about the IP family at all -- but we'll soon get to a point where blocking based on IP and location won't make sense. IPv6 is meant to improve mobility, and there are some steps taken to ensure this (see RFC 3775). GeoIP data can be wrong, misleading, or simply inexistant too, so you really ought not to rely on that at all.

Netflix has been doing relatively well in leading some interesting infrastructure ideas it seems, aside from not being very cooperative with Linux users for a long while (fortunately, now Netflix works on Linux, but only with the official Google Chrome, still not with free software browsers). It would be good to see that leadership continue and avoid restrictive policies in favor of cooperation, especially for a company priding itself on using Linux and open source technologies.

For now, I've opted to null-route IPv6 netflix, which means I get a small delay but I can still watch Futurama. It's the least intrusive change I thought of to not have to tear down my IPv6 tunnel, but still be able to watch content.

If for some inexplicable reason you also have a Cisco router at home and use an IPv6 provider from the US to get IPv6 connectivity and want to make sure Netflix keeps working; this is the command I used:

#ipv6 route 2406:DA00:FF00::/48 Null0

Rather than using outdated, unreliable technology to enforce restrictive, ill-designed content rules, Netflix should lead an overhaul of the limitations imposed upon it by the original content providers. That, or use some of those uncountable piles of moneys to cover potential costs of out-of-country-content access.

Monday, 29 February 2016

Nominations wanted for the Developer Membership Board

Hi!

The Ubuntu Developer Membership Board is in need of new blood.

Of the seven members of the board, five (5) will be expiring on March 9th. Members of the Developer Membership Board are elected by all Ubuntu Developers for a term of 2 years, meeting in #ubuntu-meeting about once a fortnight. Candidates should be Ubuntu developers themselves, and should be well qualified to evaluate prospective Ubuntu developers.

The DMB is responsible for reviewing developer applicants and decides when to entrust them with developer privileges or to grant them Ubuntu membership status.

Providing at least six valid nominations are received, the new members will be chosen using Condorcet voting. Members of the ubuntu-dev team in Launchpad will be eligible to vote, and will receive voting ballots by email (to their email address recorded in Launchpad). A Call for Nominations has already been sent by email to the ubuntu-devel-announce mailing list (but another call for nominations should follow soon): https://lists.ubuntu.com/archives/ubuntu-devel-announce/2016-February/001167.html.

Applications should be sent as GPG-signed emails to developer-membership-board at lists.ubuntu.com (which is a private mailing list accessible only by DMB members).

Of course, if you're nominating a developer other than yourself, please make sure to ask who you're about to nominate beforehand, to make sure they're okay with it.

Friday, 15 January 2016

In full tinfoil hat mode: Using GPG with smartcards

Breaking OPSEC for a bit to write a how-to on using GPG keys with smartcards...

I've thought about experimenting with smartcards for a while. Turns out that my Thinkpad has a built-in smartcard reader, but most of my other systems don't. Also, I'd like to use a smartcard to protect my SSH keys, some of which I may use on systems that I do not fully control (ie. at the university to push code to Github or Bitbucket), or to get to my server. Smartcard readers are great, but they're not much fun to add to a list of stuff to carry everywhere.

There's an alternate option: the Yubikey. Yubico appears to have made a version 4 of the Yubikey which has CCID (smartcard magic), U2F (2-factor for GitHub and Google, on Chrome), and their usual OTP token, all on the same tiny USB key. What's more, it is documented as supporting 4096 bit RSA keys, and includes some ECC support (more on this later).

Setting up GPG keys for use with smartcards is simple. One has the choice of either creating your own keys locally, and moving them on the smartcard, or generating them on the smartcard right away. In other to have a backup of my full key available in a secure location, I've opted to generate the keys off of the card, and transferring them.

For this, you will need one (or two) Yubikey 4 (or Yubikey 4 Nano, or if you don't mind being limited to 2048 bit keys, the Yubikey NEO, which can also do NFC), some backup media of your choice, and apparently, at least the following packages:

gnupg2 gnupg-agent libpth20 libccid pcscd scdaemon libksba8 opensc

You should do all of this on a trusted system, not connected to any network.

First, setup gnupg2 to a reasonable level of security. Edit ~/.gnupg/gpg.conf to pick the options you want, I've based my config on Jeffrey Clement's blog entry on the subject:

#default-key AABBCC90DEADBEEF
keyserver hkp://keyserver.ubuntu.com
no-emit-version
no-comments
keyid-format 0xlong
with-fingerprint
use-agent
personal-cipher-preferences AES256 AES192 AES CAST5
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
You'll want to replace default-key later with the key you've created, and uncomment the line.

The downside to all of this is that you'll need to use gpg2 in all cases rather than gpg; which is still the default on Ubuntu and Debian. gpg2 so far seems to work just fine for ever use I've had (including debsign, after setting DEBSIGN_PROGRAM=gpg2 in ~/.devscripts).

You can now generate your master key:
gpg2 --gen-key

Then edit the key to add new UIDs (identities) and subkeys, which will each have their own different capabilities:

gpg2 --expert --edit-key 0xAABBCC90DEADBEEF
Best is to follow jclement's blog entry for this. There is no point in reiterating all of it. There's also a pretty complete guide from The Linux Foundation IT here, though it seems to include a lot of stuff that does not appear to be required here on my system, in xenial.

Add the subkeys. You should have one of encryption, one for signing, and one for authentication. Works out pretty well, since there are three slots, one for each of these capabilities, on the Yubikey.

If you also want your master key on a smartcard, you'll probably need a second Yubikey (that's why I wrote two earlier), which would only get used to sign other people's keys, extend expiration dates, generate new subkeys, etc. That one should be left in a very secure location.

This is a great point to backup all the keys you've just created:

gpg2 -a --export-secret-keys 0xAABBCC90DEADBEEF > 0xAABBCC90DEADBEEF.master.key
gpg2 -a --export-secret-subkeys 0xAABBCC90DEADBEEF > 0xAABBCC90DEADBEEF.sub.key
gpg2 -a --export 0xAABBCC90DEADBEEF > 0xAABBCC90DEADBEEF.pub

Next step is to configure the smartcard/Yubikey to add your name, a URL for the public key, set the PINs, etc. Use the following command for this:
gpg2 --card-edit

Finally, go back to editing your GPG key:
gpg2 --expert --edit-key 0xAABBCC90DEADBEEF

From this point you can use toggle to select each subkey (using key #), move them to the smartcard (keytocard), and deselect them (key #). To move the master key to the card, "toggle" out of toggle mode then back in, then immediately run 'keytocard'. GPG will ask if you're certain. There is no way to get a key back out of the card, if you want a local copy, you needed to make a backup first.

Now's probably a great time to copy your key to a keyserver, so that people may eventually start to use it to send you encrypted mail, etc.

After transferring the keys, you may want to make a "second backup", which would only contain the "clues" for GPG to know on which smartcard to find the private part of your keys. This will be useful if you need to use the keys on another system.

Another option is to use the public portion of your key (saved somewhere, like on a keyserver), then have gpg2 discover that it's on a smartcard using:

gpg2 --card-status

Unfortunately, it appears to only manage to pick up either only the master key, or only the subkeys, if you use separate smartcards. This may be a blessing in disguise, in that you'd still only use the master key on an offline, very secure system, and only the subkeys in your typical daily use scenario.

Don't forget to generate a revocation certificate. This is essential if you ever lose your key, if it's compromised, or you're ever in a situation where you want to let the world know quickly not to use your key anymore:

gpg2 --gen-revoke 0xAABBCC90DEADBEEF
Store that data in a safe place.

Finally, more on backing up the GPG keys. It could be argued that keeping your master key on a smartcard might be a bad idea. After all, if the smartcard is lost, while it would be difficult to get the key out of the smartcard, you would probably want to treat it as compromised and get the key revoked. The same applies to keys kept on USB drives or on CD. A strong passphrase will help, but you still lost control of your key and at that point, no longer know whether it is still safe.

What's more, USB drives and CDs tend to eventually fail. CDs rot after a number of years, and USB drives just seem to not want to work correctly when you really need them. Paper is another option for backing up your keys, since there are ways (paperkey, for instance) to represent the data in a way that it could either be retyped or scanned back into digital data to be retrieved. Further securing a backup key could involve using gfshare to split it into multiple bits, in the hope that while one of its locations could be compromised (lost), you'll still have some of the others sufficient to reconstruct the key.

With the subkeys on the Yubikey, and provided gpg2 --card-status reports your card as detected, if you have the gpg-agent running with SSH support enabled you should be able to just run:

ssh-add -l

And have it list your card serial number. You can then use ssh-add -L to get the public key to use to add to authorized_keys files to use your authentication GPG subkey as a SSH key. If it doesn't work, make sure the gpg-agent is running and that ssh-add uses the right socket, and make sure pcscd isn't interfering (it seemed to get stuck in a weird state, and not shutting down automatically as it should after dealing with a request).

Whenever you try to use one of the subkeys (or the master key), rather than being asked for the passphrase for the key (which you should have set as a very difficult, absolutely unguessable string that you and only you could remember and think of), you will be asked to enter the User PIN set for the smartcard.

You've achieved proper two-factor authentication.

Note of ECC on the Yubikey: according to the marketing documentation, the Yubikey knows about ECC p256 and ECC p384. Unfortunately, it looks like safecurves.cr.yp.to considers these unsafe, since they do not meet all the SafeCurves requirements. I'm not especially versed in cryptography, but this means I'll read up more on the subject, and stay away from the ECC implementation on the Yubikey 4 for now. However, it doesn't seem, at first glace, that this ECC implementation is meant for GPG at all. The Yubikey also has PIV magic which would allow it to be used as a pure SSH smartcard (rather than using a GPG authentication subkey for SSH), with a private certificate being generated by the card. These certificates could be created using RSA or ECC. I tried to play a bit with it (using RSA), following the SSH with PIV and PKCS11 document on developers.yubico.com; but I didn't manage to make it work. It looks like the GPG functions might interfere with PIV in some way or I could just not handle the ssh-agent the right way. I'm happy to be shown how to use this correctly.