kodepilot.dev

Flashing SuperMicro IPMI/BMC firmware

Unknown — Tue, 13 Oct 2020 13:37:23 +0200
This was written after i soft-bricked multiple BMCs and got stuck in a reboot cycle after successfully un-bricking and updating them. This would also be a great time to rant a little about how running something like this with direct memory access and all that jazz is complete bonkers. But whatevs. If you're also stuck with similar issues, but on different hardware, fret not, it likely applies to you too. Just look for the right jumpers in the manual.
I have a couple of quite old and outdated SYS-6017R-WRF</a> that uses their Super X9DRW-iF</a> motherboards. They were in dire need of some love, and when moving into a new DC I decided it was about time to do something about it.
Like with all firmware updates you probably should read the update/install.txt before you start. But you have to be a special kind of stupid to run such an outdated BMC firmware like yours truly, so ain't nobody got time for that. I'm not going to say that my laziness paid off, but consider this:
The BIOS firmware update notes says you have to update the BMC firmware first</li>
The BMC firmware update notes says that you have to update the BIOS firmware first</li> </ol>
Being lazy I intended to just update the BMCs. So that's where I started. It has been years since I last logged into any of them, and the passwords were long gone. But given the quality of this software we even have options for how to get around this:

Exploit one of the many privilege escalation or authentication bypass</a> exploits that area available for older versions</li>
Use ipmitool</code> to reset the password</li> </ol> To successfully update the BMCs firmware using the modern</del> web interface you either have to run Internet Explorer (yes, that one) or open Developer Tools in Chrome (or similar) and manually create a cookie named WebServer</code> with no content. If you don't do that you will soft-brick the BMC during the update process, which means you have to unplug the machine, remove the battery and then reboot and let it initialize again. Trying to reset it using ipmitool or similar won't work. You can't even make this shit up. When the flashing process is completed it will tell you to unplug the server and reboot it. The machine will reset itself a few times while initializing the BMC, and after a few reboots it will start throwing errors, and the machine won't boot and you're unable to access the BIOS. This is because your BIOS firmware is too old for the new BMC firmware. The only way to get around this is to remove the jumper between pin 1-2 on the JPB1. This will disable the BMC completely so you can enter the BIOS and boot FreeDOS or something similar to run the BIOS update. When the BIOS is updated you just have to install the jumper again and be a little patient, it takes some time to boot the first time, and it'll reboot itself a couple of times as well.

Setting up IPv6 using dhcpv6-pd/slaac with dnsmasq
Unknown — Thu, 23 Apr 2020 13:37:23 +0200
For this to work it's important that you understand some concepts in IPv6, I'll briefly cover the most important ones in this post, but I strongly advice you to read up on them in detail. Also, I have absolutely no clue about networking. This setup is tested and working on Get (Telia), a service provider in Norway.</p>
Some assumptions, because you need that on IPv6</h2>

Your ISP delegates you a /56 using slaac or dhcpv6</li>
You run an EdgeRouter with EdgeOS 2.x or can figure out what you need to do otherwise</li>
</ul>
What we want to achieve</h2>

Open the firewall to allow traffic</li>
Request an /56-prefix using dhcpv6-pd and configure a prefix delegation</li>
Set up dnsmasq to handle router advertisement and dhcpv6 along side the regular dhcp for IPv4</li>
</ul>
And then covering some basics</h2>
There are multiple ways to delegate and obtain IPv6-prefixes, the most common way is that your ISP delegate a prefix to you using slaac or dhcpv6.</p>
Stateless Address Autoconfiguration (slaac) is where your ISP annouces a prefix using Router Advertisement (ra). Your client then uses this prefix to generate a new (sub) prefix for your interface using Extended Unique Identifier (eui-64). The results is a global and unique prefix. But nothing more. If we wanted more information, like DNS-servers and such, we'd have to request the prefix using either dhcpv6-stateless or dhcpv6-stateful.</p>
The main difference between slaac and dhcpv6-stateless is that you in dhcpv6-stateless request a prefix using slaac and additional information, like DNS-servers, using dhcpv6. If you request a prefix using dhcpv6-stateful the entire process of assigning a prefix is handled by the dhcpv6-server, more or less exactly like on DHCP on IPv4.</p>
Don't expose MySQL on the public Internet, you idiot</h2>
It's worth mentioning that IPv6-addresses by the nature of being global and unique are all routed and available on ther Internet. You don't have NAT to cover your ass for sloppy firewall rules. This is a fairly restrictive configuration, where we allow traffic to be established form the client, but not the other way around.</p>
Notice that we're allowing traffic from source port 547 to destination port 546 on udp. This is because we need to talk with our upstream router to request a prefix using dhcpv6-pd.</p>
01-WAN_IN</strong></p>
set firewall ipv6-name WAN_IN default-action drop</span></span>
set firewall ipv6-name WAN_IN rule 10 action accept</span></span>
set firewall ipv6-name WAN_IN rule 10 description "Allow established/related sessions"</span></span>
set firewall ipv6-name WAN_IN rule 10 protocol all</span></span>
set firewall ipv6-name WAN_IN rule 10 state established enable</span></span>
set firewall ipv6-name WAN_IN rule 10 state related enable</span></span>
set firewall ipv6-name WAN_IN rule 20 action drop</span></span>
set firewall ipv6-name WAN_IN rule 20 description "Drop invalid state6"</span></span>
set firewall ipv6-name WAN_IN rule 20 state invalid enable</span></span></code></pre>
02-WAN_LOCAL</strong></p>
set firewall ipv6-name WAN_LOCAL default-action drop</span></span>
set firewall ipv6-name WAN_LOCAL rule 10 action accept</span></span>
set firewall ipv6-name WAN_LOCAL rule 10 description "Allow established/related sessions"</span></span>
set firewall ipv6-name WAN_LOCAL rule 10 protocol all</span></span>
set firewall ipv6-name WAN_LOCAL rule 10 state established enable</span></span>
set firewall ipv6-name WAN_LOCAL rule 10 state related enable</span></span>
set firewall ipv6-name WAN_LOCAL rule 20 action drop</span></span>
set firewall ipv6-name WAN_LOCAL rule 20 description "Drop invalid state6"</span></span>
set firewall ipv6-name WAN_LOCAL rule 20 state invalid enable</span></span>
set firewall ipv6-name WAN_LOCAL rule 30 action accept</span></span>
set firewall ipv6-name WAN_LOCAL rule 30 description "Allow icmpv6"</span></span>
set firewall ipv6-name WAN_LOCAL rule 30 protocol icmpv6</span></span>
set firewall ipv6-name WAN_LOCAL rule 40 action accept</span></span>
set firewall ipv6-name WAN_LOCAL rule 40 description "Allow dhcpv6"</span></span>
set firewall ipv6-name WAN_LOCAL rule 40 protocol udp</span></span>
set firewall ipv6-name WAN_LOCAL rule 40 destination port 546</span></span>
set firewall ipv6-name WAN_LOCAL rule 40 source port 547</span></span></code></pre>
03-FIREWALL</strong></p>
set interfaces ethernet eth1 firewall in ipv6-name WAN_IN</span></span>
set interfaces ethernet eth1 firewall local ipv6-name WAN_LOCAL</span></span></code></pre>Requesting an /56-prefix and configuring a prefix delegation</h2>
Here we're requesting a prefix on eth0 and a prefix delecation (pd 0) to eth1, with a prefix-id set to :1, which means that it will get the first /64-prefix in the requested /56-prefix on eth0. We also configure the interface to use ::1 as address. This address will also be used later for things like DNS.</p>
set interfaces ethernet eth0 dhcpv6-pd prefix-only</span></span>
set interfaces ethernet eth0 dhcpv6-pd no-dns</span></span>
set interfaces ethernet eth0 dhcpv6-pd rapid-commit enable</span></span>
set interfaces ethernet eth0 dhcpv6-pd pd 0 prefix-length 56</span></span>
set interfaces ethernet eth0 dhcpv6-pd pd 0 interface eth1 host-address ::1</span></span>
set interfaces ethernet eth0 dhcpv6-pd pd 0 interface eth1 prefix-id :1</span></span>
set interfaces ethernet eth0 dhcpv6-pd pd 0 interface eth1 service slaac</span></span></code></pre>Setting up dnsmasq for RA, DNS and DHCP</h2>
To enable some more advanced features we're going to disable the internal dhcp-server (isc-dhcp-server) and instead use dnsmasq to handle all aspects of this, from router advertisement to DNS and DHCP. The perk here is that dnsmasq can act as an authorative DNS-server and inject DNS-records for hosts on the local network. For clients that use DHCP to request IPv4 it will also be able to provide DNS lookups for their respective IPv6 addresses, since the network interface has the same MAC-address.</p>
01-DELETE-ISC</strong></p>
delete service dhcp-server</span></span>
delete service dhcpv6-server</span></span></code></pre>
02-DNSMASQ</strong></p>
set service dns forwarding cache-size 4096</span></span>
set service dns forwarding listen-on eth1</span></span>
set service dns forwarding name-server 8.8.8.8</span></span>
set service dns forwarding name-server 8.8.4.4</span></span>
set service dns forwarding name-server 2001:4860:4860::8888</span></span>
set service dns forwarding name-server 2001:4860:4860::8844</span></span>
set service dns forwarding options interface=eth1</span></span>
set service dns forwarding options interface-name=lan.netwerk.io,eth1</span></span>
set service dns forwarding options interface-name=lan-v4.netwerk.io,eth1/4</span></span>
set service dns forwarding options interface-name=lan-v6.netwerk.io,eth1/6</span></span>
set service dns forwarding options enable-ra</span></span>
set service dns forwarding options bogus-priv</span></span>
set service dns forwarding options no-resolv</span></span>
set service dns forwarding options domain-needed</span></span>
set service dns forwarding options domain=lan.netwerk.io</span></span>
set service dns forwarding options auth-zone=lan.netwerk.io,eth1</span></span>
set service dns forwarding options auth-zone=lan-v4.netwerk.io,eth1/4</span></span>
set service dns forwarding options auth-zone=lan-v6.netwerk.io,eth1/6</span></span>
set service dns forwarding options dhcp-authoritative</span></span>
set service dns forwarding options dhcp-fqdn</span></span>
set service dns forwarding options dhcp-option=option:router,0.0.0.0</span></span>
set service dns forwarding options dhcp-option=option:dns-server,0.0.0.0</span></span>
set service dns forwarding options dhcp-option=option:domain-search,lan.netwerk.io,lan-v4.netwerk.io</span></span>
set service dns forwarding options dhcp-range=interface:eth1,192.168.1.100,192.168.1.254,24h</span></span>
set service dns forwarding options dhcp-option=option6:dns-server,[::]</span></span>
set service dns forwarding options dhcp-option=option6:domain-search,lan.netwerk.io,lan-v6.netwerk.io</span></span>
set service dns forwarding options dhcp-range=::,constructor:eth1,ra-stateless,ra-names</span></span></code></pre>
I recommend taking a look at dnsmasq(8)</a> to see what the different options do. In short we're setting up dnsmasq to enable router advertisement on the interface we're listening on and act as a authorative dhcp-server for ipv4. It also advertises local DNS-servers over both IPv4 and IPv6.</p>
Some notes</h2>
If you're using Get (Telia, Norway) you should be able to request two prefixes, one /128-prefix that I personally just set to autoconfigure on eth0 for IPv6 connectivity on the router. You don't really need to use it, but I guess it can be handy somehow. Just haven't figured it out yet. You can also request a /56-prefix, which should give you plenty of room to grow.</p>
If you're not able to request a prefix it probably means that they haven't enabled it for you or that you're blocking it in the firewall. IPv6-support needs to be enable by support before you can request a prefix.</p>
Links that has been helpful for me:</p>

Daniel Washburn - Ubiquiti EdgeOS + DHCPv6-PD Recipe</a></li>
dnsmasq</a></li>
dhcpv6-pd</a></li>
dhcpv6-stateless</a></li>
dhcpv6-stateful</a></li>
slaac</a></li>
eui-64</a></li>
</ul>


Using Lambda@Edge to fix permalink in Jekyll
Unknown — Wed, 28 Aug 2019 13:37:23 +0200
Origin Access Identity (OAI) is a secure way to access S3 buckets from CloudFront, think of it as letting CloudFront use the S3 APIs to request objects instead of H. The alternative is to make the bucket publicly available via bucket policy or ACLs, but that's not ideal.</p>
On S3 you can configure a default index document, which is requested if the specified path doesn't resolve to anything. This is handy, since static site generators like Jekyll relies on sub-directories for generating "clean URLs". But with Open Access Identity CloudFront will request the literal object using the S3 APIs, and in this case S3 doesn't know what to respond.</p>
sequenceDiagram
    participant Client
    participant CloudFront
    participant Lambda
    participant S3 as S3 Bucket
    Client->>CloudFront: Client Request GET /foobar/zoo/
    CloudFront->>Lambda: Invoke
    Lambda-->>CloudFront: Return
    CloudFront->>S3: S3 Object Request /foobar/zoo/index.html
    S3-->>CloudFront: S3 Object Response
    CloudFront-->>Client: Client Response GET /foobar/zoo/
</pre>
In this flowchart the users request is intercepted at the origin-request, which means before CloudFront requests the object from the origin, in our case, a S3 bucket. This lets us manipulate the request header to include index.html</code> so that CloudFront will request the correct object.</p>
import</span> re</span></span>
</span>
def</span> lambda_handler</span>(</span>event</span>,</span> context</span>):</span></span>
    request</span> =</span> event</span>[</span>'</span>Records</span>'</span>][</span>0</span>][</span>'cf'</span>][</span>'request'</span>]</span></span>
    request</span>[</span>'</span>uri</span>'</span>]</span> =</span> re</span>.</span>sub</span>(</span>r</span>'</span>/$</span>'</span>,</span> '/index.html'</span>,</span> request</span>[</span>'</span>uri</span>'</span>])</span></span>
</span>
    return</span> request</span></span></code></pre>


Using CloudFront with Origin Access Identity and S3
Unknown — Fri, 09 Aug 2019 13:37:23 +0200
There are many ways to host a static site on S3, either directly on S3 using S3 Website or by setting up CloudFront to serve content from S3. If you want to use your own domain and</em> TLS you more or less have to use CloudFront. However - many roads lead to Rome, and some are both quicker and more secure.</p>
You can configure a S3 bucket to serve static content over HTTP, even using your own domain. But there's a number of limitations with this setup, as detalied in the list below. Below is how you'd typically set things up in S3. Notice that ACL is set to private, this is intentional as this feature is deprecated and will throw all kinds of alarms if you've configured your AWS accounts properly. Instead, use bucket policies.</p>
resource</span> "aws_s3_bucket" "this"</span> {</span></span>
  # The bucket name must be the fqdn it responds to</span></span>
  bucket</span> =</span> "foobar.netwerk.io"</span></span>
  acl</span>    =</span> "private"</span></span>
</span>
  website</span> {</span></span>
    index_document</span> =</span> "index.html"</span></span>
  }</span></span>
}</span></span>
</span>
# Policy to grant access objects in bucket</span></span>
data</span> "aws_iam_policy_document" "this"</span> {</span></span>
  statement</span> {</span></span>
    actions</span>   =</span> [</span>"s3:GetObject"</span>]</span></span>
    resources</span> =</span> [</span>"</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>arn</span>}</span>/*"</span>]</span></span>
</span>
    principals</span> =</span> {</span></span>
      type</span>        =</span> "AWS"</span></span>
      identifiers</span> =</span> [</span>"*"</span>]</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_s3_bucket_policy" "this"</span> {</span></span>
  bucket</span> =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>id</span>}</span>"</span></span>
  policy</span> =</span> "</span>${</span>data</span>.</span>aws_iam_policy_document</span>.</span>this</span>.</span>json</span>}</span>"</span></span>
}</span></span>
</span>
resource</span> "aws_route53_record" "this"</span> {</span></span>
  zone_id</span> =</span> "</span>${</span>aws_route53_zone</span>.</span>this</span>.</span>zone_id</span>}</span>"</span></span>
  name</span>    =</span> "parked"</span></span>
  type</span>    =</span> "A"</span></span>
</span>
  alias</span> {</span></span>
    name</span>                   =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>website_domain</span>}</span>"</span></span>
    zone_id</span>                =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>hosted_zone_id</span>}</span>"</span></span>
    evaluate_target_health</span> =</span> true</span></span>
  }</span></span>
}</span></span></code></pre>
This way isn't ideal, especially not if you want or need to run TLS.</p>

The bucket website endpoint exists only in one region, the primary region for that bucket</li>
Little to no caching abilities, except for some client-side caching</li>
Limited access policies, you're stuck to conditions on bucket policies</li>
Not built for performance</li>
Bucket name has to correspond to the name of your domain</li>
</ul>
The CloudFront-way</h3>
Now - you could just put CloudFront in front of a S3 Website and consider yourself done, but you don't want that, at least not when you can</em> use Origin Access Identity instead. If you set CloudFront to use a S3 Website as backend then all backend traffic goes unencrypted from edge servers to S3. If you have some kind of policy attached to CloudFront users can just bypass it all by connecting to the backend bucket directly. Remember, they know exactly what name your bucket has.</p>
To mitigate all of this Amazon has created Origin Access Identity. This lets CloudFront use S3 APIs to request the objects, and all requests are authenticated and encrypted from edge servers to backend buckets. Now your backend bucket can be any bucket, or sub-directory in any bucket, and CloudFront will be able to access the content, as long as you've configured an appropriate access policy.</p>
There is one caveat, like it always is. Since CloudFront uses the S3 API to access objects they are treated like just that, objects. This means that it has no concept of sub-directories. Normally when you access a URI like /foobar/</code> the webserver knows that you're likely looking for /foobar/index.html</code> and will serve that up directly. But in this case the S3 API will just return that the object doesn't exist. Luckily we can fix this with a simple Lambda@Edge.</p>
resource</span> "aws_s3_bucket" "this"</span> {</span></span>
  bucket</span> =</span> "</span>${</span>var</span>.</span>bucket</span>}</span>"</span></span>
  acl</span>    =</span> "private"</span></span>
}</span></span>
</span>
resource</span> "aws_cloudfront_origin_access_identity" "this"</span> {}</span></span>
</span>
data</span> "aws_iam_policy_document" "this"</span> {</span></span>
  statement</span> {</span></span>
    actions</span>   =</span> [</span>"s3:GetObject"</span>]</span></span>
    resources</span> =</span> [</span>"</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>arn</span>}</span>/*"</span>]</span></span>
</span>
    principals</span> {</span></span>
      type</span>        =</span> "AWS"</span></span>
      identifiers</span> =</span> [</span>"</span>${</span>aws_cloudfront_origin_access_identity</span>.</span>this</span>.</span>iam_arn</span>}</span>"</span>]</span></span>
    }</span></span>
  }</span></span>
</span>
  statement</span> {</span></span>
    actions</span>   =</span> [</span>"s3:ListBucket"</span>]</span></span>
    resources</span> =</span> [</span>"</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>arn</span>}</span>"</span>]</span></span>
</span>
    principals</span> {</span></span>
      type</span>        =</span> "AWS"</span></span>
      identifiers</span> =</span> [</span>"</span>${</span>aws_cloudfront_origin_access_identity</span>.</span>this</span>.</span>iam_arn</span>}</span>"</span>]</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_s3_bucket_policy" "this"</span> {</span></span>
  bucket</span> =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>id</span>}</span>"</span></span>
  policy</span> =</span> "</span>${</span>data</span>.</span>aws_iam_policy_document</span>.</span>this</span>.</span>json</span>}</span>"</span></span>
}</span></span>
</span>
resource</span> "aws_cloudfront_distribution" "this"</span> {</span></span>
  enabled</span>             =</span> "</span>${</span>var</span>.</span>enabled</span>}</span>"</span></span>
  is_ipv6_enabled</span>     =</span> "</span>${</span>var</span>.</span>is_ipv6_enabled</span>}</span>"</span></span>
  price_class</span>         =</span> "</span>${</span>var</span>.</span>price_class</span>}</span>"</span></span>
  default_root_object</span> =</span> "</span>${</span>var</span>.</span>default_root_object</span>}</span>"</span></span>
</span>
  aliases</span> =</span> [</span>"</span>${</span>local</span>.</span>aliases</span>}</span>"</span>]</span></span>
</span>
  origin</span> {</span></span>
    domain_name</span> =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>bucket_regional_domain_name</span>}</span>"</span></span>
    origin_id</span>   =</span> "</span>${</span>var</span>.</span>domain_name</span>}</span>"</span></span>
</span>
    s3_origin_config</span> {</span></span>
      origin_access_identity</span> =</span> "</span>${</span>aws_cloudfront_origin_access_identity</span>.</span>this</span>.</span>cloudfront_access_identity_path</span>}</span>"</span></span>
    }</span></span>
  }</span></span>
</span>
  viewer_certificate</span> {</span></span>
    acm_certificate_arn</span>      =</span> "</span>${</span>aws_acm_certificate</span>.</span>this</span>.</span>arn</span>}</span>"</span></span>
    ssl_support_method</span>       =</span> "</span>${</span>var</span>.</span>ssl_support_method</span>}</span>"</span></span>
    minimum_protocol_version</span> =</span> "</span>${</span>var</span>.</span>minimum_protocol_version</span>}</span>"</span></span>
  }</span></span>
</span>
  default_cache_behavior</span> {</span></span>
    allowed_methods</span>  =</span> "</span>${</span>var</span>.</span>allowed_methods</span>}</span>"</span></span>
    cached_methods</span>   =</span> "</span>${</span>var</span>.</span>cached_methods</span>}</span>"</span></span>
    target_origin_id</span> =</span> "</span>${</span>var</span>.</span>domain_name</span>}</span>"</span></span>
    compress</span>         =</span> "</span>${</span>var</span>.</span>compress</span>}</span>"</span></span>
</span>
    forwarded_values</span> {</span></span>
      query_string</span> =</span> "</span>${</span>var</span>.</span>forwarded_query_string</span>}</span>"</span></span>
</span>
      cookies</span> {</span></span>
        forward</span> =</span> "</span>${</span>var</span>.</span>forwarded_cookies</span>}</span>"</span></span>
      }</span></span>
    }</span></span>
</span>
    viewer_protocol_policy</span> =</span> "</span>${</span>var</span>.</span>viewer_protocol_policy</span>}</span>"</span></span>
    default_ttl</span>            =</span> "</span>${</span>var</span>.</span>default_ttl</span>}</span>"</span></span>
    min_ttl</span>                =</span> "</span>${</span>var</span>.</span>min_ttl</span>}</span>"</span></span>
    max_ttl</span>                =</span> "</span>${</span>var</span>.</span>max_ttl</span>}</span>"</span></span>
  }</span></span>
</span>
  restrictions</span> {</span></span>
    geo_restriction</span> {</span></span>
      locations</span>        =</span> "</span>${</span>var</span>.</span>locations</span>}</span>"</span></span>
      restriction_type</span> =</span> "</span>${</span>var</span>.</span>restriction_type</span>}</span>"</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>


Key signing party for small teams
Unknown — Thu, 08 Aug 2019 13:37:23 +0200
To make key signings as efficient as possible it's important that all participants comes prepared. We avoid using Key Servers, since they are flakey, slow and might publish more information than you want. Before the event all users should have received a list of keys that will be signed, and imported them into their own keyring.</p>
Most people don't carry around their master key, or prefer to keep it air-gapped. These people will provide their signature later. During the signing party everyone will take a secure note of KeyID and fingerprints that they have checked. In order to speed things up and help for those with offline keys a list of KeyID and fingerprints can be prepared as a hardcopy, where the participants can take notes.</p>
The benefit of GPG in the workplace</a></h3>
Most companies do a decent job with background checks and general vetting of people before hiring them. And physical security in buildings is often more than good enough, someone will notice if you go around pretending to be me at the office. On the Internet however that is a lot harder, so you need to have some kind of digital proof, something that cannot be copied or easily stolen.</p>
You also get the added benefit of a second vetting. Security works best in layers, it's best to not assume anything. If the user loses their key or doesn't have it you just have to do another Key Signing. At least if you want to do anything online for this user.</p>
And that's GPG, when used in combination security tokens, like YubiKey</a>. Users store the private keys (or signing keys) on security tokens, which cannot be copied, and when lost, is easily noticed</a>. The token is protected by a PIN-number, and the private key stored on the devices cannot be extracted or otherwise removed from the device. The owner of the key can configure how many PIN attempts to allow before the key is locked. On keys like YubiKey you can also set an admin PIN which lets you reset PIN attempts. Signature counters (including number of bad PIN entries) can only be reset by factory resetting the device, which also removes key material.</p>
A very typical scenario is that someone needs to reset or unlink an MFA device from their account. Since it's easy to impersonate someone over the Internet you need a way to provide proof that the user is who they say they are. This can be done using asymmetric encryption. The idea is that all users exchange public keys in a secure manner, like in person or using Web Key Directory</a>, and that all requests are signed using their private key. This way everyone can verify (to some extent) that the person are who they say they are. We can also encrypt messages using the recipients public key, you sign the message or file to prove who you are and you encrypt the message to ensure that only the recipient can read it.</p>
Lets do the Key Signing Dance</a></h3>
To check that the key holder is who they say they are, we meet up face-to-face, and do the key signing dance:</p>

The other participants import the key holders public key into their local keyring, using either of these alternatives:</li>
</ol>

gpg --import foobar.gpg</code></li>
gpg --locate-keys foo@foobar.com</code></li>
gpg [--keyserver <pgp.mit.edu|pool.sks-keyservers.net>] --recv-keys foo@foobar.com</code></li>
curl https://github.com/foobar.gpg | gpg --import</code></li>
</ul>

The key holder confirms their KeyID and fingerprint by reading it out loud</li>
The other participants verify the key holders valid ID, like a drivers license or passport</li>
The other participants takes a note that they've verified this key</li>
</ol>
When all keys are verified the participants either sign and export the signature at the venue and hand them over to the key holder, or wait until they have access to their master key and do it then. Out of curtesy it's common to not publish key signatures to public key servers, but rather export the signature and send it via email to the key holder. Then they can import the signatures and publish it key servers and web key directory at their own will.</p>

Sign the key holders public key, using the KeyID</code></li>
</ol>

gpg --sign-key KeyID</code></li>
</ul>

Encrypt the key and send to key holder via email</li>
</ol>

gpg --export --armor <UID|KeyID> > <UID|KeyID>.key</code></li>
gpg --encrypt --recipient <UID|KeyID> <UID|KeyID>.key</code> (creates KeyID.key.gpg)</li>
(Alernative) gpg --export --armor <UID|KeyID> | gpg --encrypt --recipient <UID|KeyID> -o <UID|KeyID>.key.gpg</code></li>
</ul>
Cheat sheet</h3>

Listing keys and fingerprint</li>
</ol>

gpg --list-keys [UID|KeyID]</code></li>
gpg --list-keys --fingerprint [UID|KeyID]</code></li>
</ul>

Exporting keys</li>
</ol>

gpg --export --armor <UID|KeyID></code></li>
gpg --export --armor SUBKEYID! [SUBKEYID! ..]</code></li>
</ul>

Listing and importing key signatures</li>
</ol>

gpg --list-sig <UID|KeyID></code></li>
gpg --import --import-options merge-only foobar.gpg</code></li>
gpg --decrypt foobar.key.gpg | gpg --import --import-options merge-only</code></li>
</ul>

Signing and encrypting a file, where UID|KeyID is recipient of file</li>
</ol>

gpg -se -r <UID|KeyID> [file]</code></li>
</ul>

Creating a clearsign; a message that contains both message and signature</li>
</ol>

gpg --clear-sign [file]</code> (write message and finish with ^D)</li>
</ul>
Replacing a YubiKey (HSMs)</h3>
If you're using multiple YubiKeys with the same key material on them you need to tell gpg-agent about the serial number of the key you want to use, since they are tied together. The easiest way is to just tell the agent to relearn the new serial numbers.</p>

Replacing YubiKey using gpg-agent-connect to relearn</li>
</ol>

Plug in spare / replacement YubiKey</li>
gpg-connect-agent "scd serialno" "learn --force" /bye</code></li>
</ul>

Replacing YubiKey by removing key stubs</li>
</ol>

Find keygrip gpg --with-keygrip --list-secret-keys KeyID</code> for all keys</li>
Locate stubs in ~/.gnupg/private-keys-v1.d/</code> and delete them</li>
Insert new YubiKey</li>
</ul>
Why shouldn't you publish signatures to Key Servers on other users behalf?</a></h3>
I was a little puzzled by this myself, as it seems strange that key servers allow a usage pattern that is not recommended. Apparently there are two primary reasons, most notably that you've likely only verified their name and identity, not the ownership of the e-mail account used as their UID. When you send the signature to the key holder via e-mail only the holder of that e-mail account would be able to publish the signature, proving that they own that account. And last but not least, there is a privacy concern. The Key Holder might not want the world to know that you two know each other. So we make it up to them to decide.</p>


Configuring Web Key Directory for GPG
Unknown — Wed, 07 Aug 2019 13:37:23 +0200
Web Key Directory (WKD) is a proposal for a new way to discover other users keys, using HTTP and TLS. In short it looks up the UID on the users host. This works since all UIDs are email address, and all email addresses are built up of two parts, the username and host part.</p>
When we need to look up a new key, we can just query the server, establish a secure connection using TLS, and ask it to provide the users public key. Boom! Now you don't need to rely on flakey key servers that are abused by people for nefarious purposes, given their immutable nature.</p>
Technical details</h3>
The documentation</a> for WKD leaves much to be desired, and seems mostly focused on setting up more advanced systems for larger organizations to let users manage their WKD identity. For personal use it's pretty straight forward to generate and publish.</p>

UID is SHA1 hashed, Z-base32 encoded</a></li>
The public key is in binary format as payload of the UID</li>
Uses the RFC5785</a>-scheme: https://netwerk.io/.well-known/openpgpkey/hu/dmkqu7xwyxmspm94y6147dss1n59nfag</a>, where the last part is your UID</li>
</ul>
Show me, show me!</h3>
If you're too lazy, just export the UID hash directly, like so:</p>
vegardx@yondu:~</span> $</span> gpg --list-keys --with-wkd-hash vegard@netwerk.io</span></span>
pub</span>   rsa4096/0xBBF808963354ED16 2019-08-06</span> [SC]</span></span>
      Key</span> fingerprint =</span> 4770 5635</span> 6BEF A6F0 FBE7  BB21 BBF8</span> 0896 3354</span> ED16</span></span>
uid</span>                   [ultimate] Vegard Hansen </span><</span>vegard@netwerk.io</span>></span></span>
                      dmkqu7xwyxmspm94y6147dss1n59nfag@netwerk.io</span></span>
sub</span>   rsa4096/0xCE7C14C99AB0CF0C 2019-08-06</span> [E]</span></span>
sub</span>   rsa4096/0xC2CADE62F7C2714B 2019-10-08</span> [A]</span></span></code></pre>
So when you've put the file in the correct place with the correct content you should be able to look yourself up, without using a key server, like so:</p>
vegardx@bork:~</span> $</span> gpg --locate-keys vegard@netwerk.io</span></span>
gpg:</span> key BBF808963354ED16: public key "Vegard Hansen <vegard@netwerk.io>" imported</span></span>
gpg:</span> Total number processed:</span> 1</span></span>
gpg:</span>               imported:</span> 1</span></span>
gpg:</span> no ultimately trusted keys found</span></span>
pub</span>   rsa4096 2019-08-06</span> [SC]</span></span>
      477056356BEFA6F0FBE7BB21BBF808963354ED16</span></span>
uid</span>           [</span> unknown] Vegard Hansen</span> <</span>vegard@netwerk.i</span>o</span>></span></span>
sub</span>   rsa4096 2019-08-06</span> [E]</span></span>
sub</span>   rsa4096 2019-10-08</span> [A]</span></span></code></pre>


Dealing with hostnames, domains and environments
Unknown — Tue, 05 Mar 2019 15:50:50 +0100
Unless you've completely jumped on the container band wagon you probably still need to maintain a number of stateful servers, which typically live in a number of environments, like dev, stg and prd. You probably also have a number of servers in a cluster spread out on different availability zones.</p>
To keep things simple and predictable we have to use a consistent naming scheme. What pattern you end up choosing doesn't matter that much, as long as you're doing it consistently. The way described is how I like to do it.</p>
Hostnames</h3>
Say you have a server named foobar</code> in all environments, and you ssh into the one in prd</code>. How would you tell? There's nothing in the default shell prompt that would suggest which environment you're currently working on. However, if you prefix the hostname with current environment your local prompt will read like vegardx@prd-foobar:~$</code>.</p>
And foobar</code> is probably not a single server, more like a cluster of machines. So we add n+1</code> to the hostname, which helps us tell exactly what machine we're talking to. And now your prompt looks like vegardx@prd-foobar01:~$</code>, where server number 01</code> in cluster foobar</code> on environment prd</code>.</p>
Since we're dealing with multiple availability zones it also makes sense to add information about that to the hostname, so we postfix that to name as well, which makes the prompt look quite descriptive: vegardx@prd-foobar01a</code>, where a</code> defines the availability zone within the region.</p>
flowchart LR
    A["Env<br/>prd"] --> B["Name<br/>foobar"] --> C["Count<br/>01"] --> D["AZ<br/>a"]
</pre>
Service domain</h3>
Since we now have fairly predictable and unique hostnames we should extend this with a domain name as well. When working with multiple environments it makes sense to do sub-zone delegation, so that each environment has its own zone, and is completely isolated from each other.</p>
flowchart TD
    root["netwerk.io"] --> dev["dev.netwerk.io"]
    root --> stg["stg.netwerk.io"]
    root --> prd["prd.netwerk.io"]
</pre>
So now the fully qualified domain name for a machine in prd</code> would be something like prd-foobar07c.prd.netwerk.io</code>. The environment gets duplicated since we do sub-zone delegation, as mentioned earlier.</p>
Clusters are named in the same predictable way, we just remove the count and availability zone in the name, like so prd-foobar.prd.netwerk.io</code>. This could point to a load balancer in front of machines or machines directly. This is very useful as it can be used by other domains with CNAME.</p>
SSH and ProxyJump</h3>
We now have a completely predictable and consistent naming scheme that also resolves on every level we can add a few lines to our local ssh config to ssh directly into a host, via bastion / jump hosts.</p>
In this scenario I don't need to expose my ssh-agent, and if I need to ssh into the provisioning use (-l admin</code> for Debian on AWS) the key is already loaded up. With ssh prd-foobar01a</code> it will automatically ProxyJump via prd-bastion01a.prd.netwerk.io</code> and into prd-foobar01a.prd.netwerk.io</code>.</p>
Host</span> dev stg prd</span></span>
  HostName</span> %h-bastion01a.%h.netwerk.io</span></span>
  IdentityFile</span> ~/.ssh/id_rsa</span></span>
  UseKeychain</span> yes</span></span>
</span>
Host</span> dev-</span>*</span></span>
  HostName</span> %h.dev.netwerk.io</span></span>
  ProxyJump</span> dev</span></span>
  IdentityFile</span> ~/.ssh/id_rsa</span></span>
  IdentityFile</span> ~/.ssh/dev-internal.pem</span></span>
  UseKeychain</span> yes</span></span>
</span>
Host</span> stg-</span>*</span></span>
  HostName</span> %h.stg.netwerk.io</span></span>
  ProxyJump</span> stg</span></span>
  IdentityFile</span> ~/.ssh/id_rsa</span></span>
  IdentityFile</span> ~/.ssh/stg-internal.pem</span></span>
  UseKeychain</span> yes</span></span>
</span>
Host</span> prd-</span>*</span></span>
  HostName</span> %h.prd.netwerk.io</span></span>
  ProxyJump</span> prd</span></span>
  IdentityFile</span> ~/.ssh/id_rsa</span></span>
  IdentityFile</span> ~/.ssh/prd-internal.pem</span></span>
  UseKeychain</span> yes</span></span></code></pre>


Invalidate CloudFront with Lambda and S3 events
Unknown — Thu, 28 Feb 2019 15:50:50 +0100
Bla bla bla... You're here for the solution, not to hear me talk about it. See code example. Improvise, adapt and overcome.</a></p>
One thing though, unless you have a shit metric ton of objects that you want to keep all hot and sizzling in cache I suggest you just invalidate the entire path, and not per object. Amazon has this weird pricing model where wildcard invalidations are priced as a single path.</p>
lambda.py</strong></p>
import</span> os</span></span>
import</span> time</span></span>
import</span> boto3</span></span>
</span>
def</span> lambda_handler</span>(</span>event</span>,</span> context</span>):</span></span>
    client</span> =</span> boto3</span>.</span>client</span>(</span>'cloudfront'</span>)</span></span>
    invalidation</span> =</span> client</span>.</span>create_invalidation</span>(</span></span>
        DistributionId</span>=</span>os</span>.</span>environ</span>[</span>'</span>DISTRIBUTION_ID</span>'</span>],</span></span>
        InvalidationBatch</span>=</span>{</span></span>
            'Paths'</span>: {</span></span>
                'Quantity'</span>:</span> 1</span>,</span></span>
                'Items'</span>: [</span></span>
                    '/*'</span>,</span></span>
                ]</span></span>
            },</span></span>
            'CallerReference'</span>:</span> str</span>(</span>time</span>.</span>time</span>())</span></span>
        }</span></span>
    )</span></span></code></pre>
terraform.tf</strong></p>
data</span> "archive_file" "lambda"</span> {</span></span>
  type</span>        =</span> "zip"</span></span>
  source_file</span> =</span> "lambda_function.py"</span></span>
  output_path</span> =</span> "lambda.zip"</span></span>
}</span></span>
</span>
data</span> "aws_iam_policy_document" "role"</span> {</span></span>
  statement</span> {</span></span>
    actions</span> =</span> [</span></span>
      "sts:AssumeRole"</span>,</span></span>
    ]</span></span>
</span>
    principals</span> {</span></span>
      type</span>        =</span> "Service"</span></span>
      identifiers</span> =</span> [</span>"lambda.amazonaws.com"</span>]</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_iam_role" "this"</span> {</span></span>
  name</span>               =</span> "</span>${</span>local</span>.</span>prefix</span>}</span>-lambda"</span></span>
  assume_role_policy</span> =</span> "</span>${</span>data</span>.</span>aws_iam_policy_document</span>.</span>role</span>.</span>json</span>}</span>"</span></span>
}</span></span>
</span>
data</span> "aws_iam_policy_document" "policy"</span> {</span></span>
  statement</span> {</span></span>
    actions</span> =</span> [</span></span>
      "logs:CreateLogGroup"</span>,</span></span>
      "logs:CreateLogStream"</span>,</span></span>
      "logs:PutLogEvents"</span>,</span></span>
    ]</span></span>
</span>
    resources</span> =</span> [</span>"arn:aws:logs:*:*:*"</span>]</span></span>
  }</span></span>
</span>
  statement</span> {</span></span>
    actions</span> =</span> [</span></span>
      "cloudfront:CreateInvalidation"</span>,</span></span>
    ]</span></span>
</span>
    # You'd assume that Amazon lets you specify the ARN of the CloudFront</span></span>
    # distribution. But na-ah!</span></span>
    resources</span> =</span> [</span>"*"</span>]</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_iam_role_policy" "this"</span> {</span></span>
  name</span>   =</span> "</span>${</span>local</span>.</span>prefix</span>}</span>-lambda"</span></span>
  policy</span> =</span> "</span>${</span>data</span>.</span>aws_iam_policy_document</span>.</span>policy</span>.</span>json</span>}</span>"</span></span>
  role</span>   =</span> "</span>${</span>aws_iam_role</span>.</span>this</span>.</span>name</span>}</span>"</span></span>
}</span></span>
</span>
resource</span> "aws_lambda_function" "this"</span> {</span></span>
  runtime</span>          =</span> "python3.6"</span></span>
  filename</span>         =</span> "lambda.zip"</span></span>
  function_name</span>    =</span> "</span>${</span>local</span>.</span>prefix</span>}</span>-cloudfront-invalidation"</span></span>
  role</span>             =</span> "</span>${</span>aws_iam_role</span>.</span>this</span>.</span>arn</span>}</span>"</span></span>
  handler</span>          =</span> "lambda_function.lambda_handler"</span></span>
  source_code_hash</span> =</span> "</span>${</span>data</span>.</span>archive_file</span>.</span>lambda</span>.</span>output_base64sha256</span>}</span>"</span></span>
</span>
  environment</span> {</span></span>
    variables</span> =</span> {</span></span>
      DISTRIBUTION_ID</span> =</span> "</span>${</span>aws_cloudfront_distribution</span>.</span>this</span>.</span>id</span>}</span>"</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_lambda_permission" "this"</span> {</span></span>
  action</span>        =</span> "lambda:InvokeFunction"</span></span>
  function_name</span> =</span> "</span>${</span>aws_lambda_function</span>.</span>this</span>.</span>arn</span>}</span>"</span></span>
  principal</span>     =</span> "s3.amazonaws.com"</span></span>
  source_arn</span>    =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>arn</span>}</span>"</span></span>
}</span></span>
</span>
resource</span> "aws_s3_bucket_notification" "this"</span> {</span></span>
  # This would be the bucket that CloudFront fetches the objects from.</span></span>
  bucket</span> =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>id</span>}</span>"</span></span>
</span>
  lambda_function</span> {</span></span>
    lambda_function_arn</span> =</span> "</span>${</span>aws_lambda_function</span>.</span>this</span>.</span>arn</span>}</span>"</span></span>
    events</span>              =</span> [</span>"s3:ObjectCreated:*"</span>]</span></span>
    filter_prefix</span>       =</span> "index.html"</span></span>
  }</span></span>
}</span></span></code></pre>


Parking a domain on S3
Unknown — Mon, 25 Feb 2019 15:50:50 +0100
You might want to "park" a domain to notify people that they're no longer in use or whatever. Since we're using Terraform you can update a ton of parked domains at the same time. Which is nice when business decides to rebrand everything. Like they do.</p>
Notice that we're using a bucket policy and not ACLs to make the contents of the bucket public. This gives us more fine grained control over access to the bucket, and while it doesn't really matter in this case, it's a good habit to get into.</p>
resource</span> "aws_s3_bucket" "this"</span> {</span></span>
  # The bucket name must be the fqdn it responds to</span></span>
  bucket</span> =</span> "parked.netwerk.io"</span></span>
  acl</span>    =</span> "private"</span></span>
</span>
  # We set both index and error document so that all requests are routed to</span></span>
  # index.html</span></span>
  website</span> {</span></span>
    index_document</span> =</span> "index.html"</span></span>
    error_document</span> =</span> "index.html"</span></span>
  }</span></span>
}</span></span>
</span>
# Create index.html with the domain name used to access this bucket</span></span>
resource</span> "aws_s3_bucket_object" "this"</span> {</span></span>
  key</span>          =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>website</span>.</span>index_document</span>}</span>"</span></span>
  bucket</span>       =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>id</span>}</span>"</span></span>
  content</span>      =</span> "<h1></span>${</span>aws_route53_record</span>.</span>this</span>.</span>fqdn</span>}</span> is parked.</h1>"</span></span>
  content_type</span> =</span> "text/html"</span></span>
}</span></span>
</span>
# Policy to grant access to object previously created inside the bucket</span></span>
data</span> "aws_iam_policy_document" "this"</span> {</span></span>
  statement</span> {</span></span>
    actions</span>   =</span> [</span>"s3:GetObject"</span>]</span></span>
    # This is a very restricted policy that will only allow access to object</span></span>
    resources</span> =</span> [</span>"</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>arn</span>}</span>/</span>${</span>aws_s3_bucket_object</span>.</span>this</span>.</span>id</span>}</span>"</span>]</span></span>
</span>
    principals</span> =</span> {</span></span>
      type</span>        =</span> "AWS"</span></span>
      identifiers</span> =</span> [</span>"*"</span>]</span></span>
    }</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_s3_bucket_policy" "this"</span> {</span></span>
  bucket</span> =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>id</span>}</span>"</span></span>
  policy</span> =</span> "</span>${</span>data</span>.</span>aws_iam_policy_document</span>.</span>this</span>.</span>json</span>}</span>"</span></span>
}</span></span>
</span>
resource</span> "aws_route53_record" "this"</span> {</span></span>
  zone_id</span> =</span> "</span>${</span>aws_route53_zone</span>.</span>this</span>.</span>zone_id</span>}</span>"</span></span>
  name</span>    =</span> "parked"</span></span>
  type</span>    =</span> "A"</span></span>
</span>
  alias</span> {</span></span>
    name</span>                   =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>website_domain</span>}</span>"</span></span>
    zone_id</span>                =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>hosted_zone_id</span>}</span>"</span></span>
    evaluate_target_health</span> =</span> true</span></span>
  }</span></span>
}</span></span></code></pre>


Using Terraform to manage redirects
Unknown — Wed, 26 Dec 2018 15:50:50 +0100
S3 has a few neat features, like letting you publish your webpage or store backups. But one of my favorite features is the ability to set up more or less maintenance-free redirects. This is super useful when you're in a corporate environment where domain name changes are quite frequent, either due to rebranding or similar.</p>
So, say you want to redirect all traffic on redir.netwerk.io to https://google.com, then a simple configuration like this is enough.</p>
resource</span> "aws_s3_bucket" "this"</span> {</span></span>
  # The bucket name must be the fqdn it responds to</span></span>
  bucket</span> =</span> "redir.netwerk.io"</span></span>
</span>
  website</span> {</span></span>
    redirect_all_requests_to</span> =</span> "https://google.com"</span></span>
  }</span></span>
}</span></span>
</span>
resource</span> "aws_route53_record" "this"</span> {</span></span>
  zone_id</span> =</span> "</span>${</span>aws_route53_zone</span>.</span>this</span>.</span>zone_id</span>}</span>"</span></span>
  name</span>    =</span> "redir"</span></span>
  type</span>    =</span> "A"</span></span>
</span>
  alias</span> {</span></span>
    name</span>                   =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>website_domain</span>}</span>"</span></span>
    zone_id</span>                =</span> "</span>${</span>aws_s3_bucket</span>.</span>this</span>.</span>hosted_zone_id</span>}</span>"</span></span>
    evaluate_target_health</span> =</span> true</span></span>
  }</span></span>
}</span></span></code></pre>
This only works when you want to redirect regular HTTP traffic, if the endpoint you're redirecting from was using TLS you have to put CloudFront with certificates from Certificate Manager in front.</p>


Running ssh-agent on macOS Sierra
Unknown — Fri, 20 Oct 2017 00:21:40 +0200
Previously macOS shipped with its own build of openssh</code> that had some special additions to store the keys and passphrase in your keychain. They've finally come to their senses and reverted back to a more standard openssh</code>. But this naturally cause some frustration when things stop working like they used to.</p>
To mimic the same kind of functionality you have to instruct ssh</code> to add your keys on startup, and alternatively store the passphrase in your keychain. In my opinion this is a lot cleaner approach than running ssh-add</code> when you start a new shell, since you don't try to add them to ssh-agent</code> every time.</p>
Caution! When adding keys to your ssh-agent</code> consider that any host you forward your keys to potentially will have access to these keys. You also potentially leak a lot of information</a> about yourself when connecting to a host.</p>
Host</span> *</span></span>
  IdentityFile</span>  ~/.ssh/id_rsa</span></span>
  UseKeychain</span>    yes</span></span>
</span>
  # Use with caution, see comment</span></span>
  AddKeysToAgent</span> yes</span></span></code></pre>


Salted sha-512 hashes on macOS
Unknown — Thu, 19 Oct 2017 20:37:15 +0200
This has been a recurring issue for me. I often need (for some weird reason) to send a sha-512 hashed password to someone. This seems like such a trivial task, but since you've landed here I guess you've also figured out that this is non-trivial without pulling out Python or something similar. And that takes a lot of time.</p>
In comes Docker and Alpine Linux. You can always pass the password and copy the output directly, but then you also have that password in your shell history. Probably not what you want.</p>

docker run --rm -ti alpine:latest mkpasswd -m sha512 [password] [| pbcopy]</code></li>
</ul>


Using gpg-agent on macOS Sierra
Unknown — Thu, 19 Oct 2017 20:37:15 +0200
There are many ways to configure this beast. This is one of them. In newer versions of gnupg the option --write-env-file</code> has been removed. If you have a problem with gpg-agent</code> not working across multiple shells this is likely the issue; you're running a newer version of gnupg.</p>
First install gnupg@2.0</code> and pinentry-mac</code> from homebrew. We're using pinentry-mac</code> so you get a nice little graphical input when you need to enter your key. You probably shouldn't store this passphrase in your local keychain.</p>
brew</span> install gnupg@2.0 pinentry-mac</span></span></code></pre># Enables GPG to find gpg-agent</span></span>
use-standard-socket</span></span>
</span>
# Connects gpg-agent to the OSX keychain via the brew-installed</span></span>
# pinentry program from GPGtools. This is the OSX 'magic sauce',</span></span>
# allowing the gpg key's passphrase to be stored in the login</span></span>
# keychain, enabling automatic key signing.</span></span>
pinentry-program</span> /usr/local/bin/pinentry-mac</span></span>
</span>
# Optional, cache the keys for some time so you don't have to enter</span></span>
# your passphrase so often.</span></span>
# default-cache-ttl 7200</span></span>
# max-cache-ttl 7200</span></span></code></pre># Launch gpg-agent if it's not already running</span></span>
gpgconf</span> --launch gpg-agent</span></span>
</span>
# Optional, when signing git commits</span></span>
# export GPG_TTY=$(tty)</span></span></code></pre>
kodepilot.dev

Flashing SuperMicro IPMI/BMC firmware

Setting up IPv6 using dhcpv6-pd/slaac with dnsmasq

Some assumptions, because you need that on IPv6</h2> Your ISP delegates you a /56 using slaac or dhcpv6</li>

What we want to achieve</h2> Open the firewall to allow traffic</li> Request an /56-prefix using dhcpv6-pd and configure a prefix delegation</li>

Using Lambda@Edge to fix permalink in Jekyll

Using CloudFront with Origin Access Identity and S3

Key signing party for small teams

Configuring Web Key Directory for GPG

Dealing with hostnames, domains and environments

Invalidate CloudFront with Lambda and S3 events

Parking a domain on S3

Using Terraform to manage redirects

Running ssh-agent on macOS Sierra

Salted sha-512 hashes on macOS

Using gpg-agent on macOS Sierra
