Archive for the 'Admin' Category

Ansible and Vagrant SSH Keys

I recently came across the question how to handle SSH keys with Vagrant and Ansible.

Vagrant

Traditionally all Vagrant boxes and VMs require a fixed login (vagrant) with a fixed SSH key. This was very convenient in a development context, but could raise security issues in case Vagrant VMs were used for anything important and users were not aware of the insecure key.

In current Vagrant versions only boxes (i. e. base images) use the insecure key. When Vagrant starts a new VM it generates a new individual SSH key for this instance. Vagrant keeps these custom keys in the .vagrant/machines subdirectory; so host to guest logins (like vagrant ssh) are still possible.

A vagrant up shows the multi-step procedure:

    workstation: Vagrant insecure key detected. Vagrant will automatically replace
    workstation: this with a newly generated keypair for better security.
    workstation: 
    workstation: Inserting generated public key within guest...
    workstation: Removing insecure key from the guest if it's present...
    workstation: Key inserted! Disconnecting and reconnecting using new SSH key...
==> workstation: Machine booted and ready!

To prevent this mechanism one can configure the VM with config.ssh.insert_key = False. This is necessary when modifying a box. Say you want to take a bento base box, install your development tools, and then repackage the VM as your own development box in order to distribute it to a development team. — With the default behaviour (config.ssh.insert_key = True) every repackage build would generate a new basebox with an individual ssh keypair; this makes the new boxes practically unusable, because every user would have to get and configure the custom SSH key for each box. With config.ssh.insert_key = False the box will retain the previous key; that means you users have the same experience as with a normal box.

Note: As a compromise between the two modes one can set a custom ssh key for all baseboxes with config.ssh.private_key_path. This might be useful for companies with many internal boxes. In this case one distribute one SSH key to use with all Vagrant boxes but not use the publicly known insecure standard key.

Ansible

If all VMs use the same SSH key the setup is straightforward: Configure all Vagrant VMs with config.ssh.insert_key = False or config.ssh.private_key_path and use that key for the Ansible login.

With Vagrant’s default behaviour there is no common SSH key for all VMs. In this case one has to configure Ansible to use the right keys for every VM, but the setup is still simple as long as you have the default /vagrant mount with the .vagrant subdirectory.

This subdirectory contains all Vagrant state and contains these files, right now the private_key is the important one:

$ find .vagrant/
.vagrant/
.vagrant/rgloader
.vagrant/rgloader/loader.rb
.vagrant/machines
.vagrant/machines/workstation
.vagrant/machines/workstation/virtualbox
.vagrant/machines/workstation/virtualbox/synced_folders
.vagrant/machines/workstation/virtualbox/vagrant_cwd
.vagrant/machines/workstation/virtualbox/index_uuid
.vagrant/machines/workstation/virtualbox/action_set_name
.vagrant/machines/workstation/virtualbox/private_key
.vagrant/machines/workstation/virtualbox/id
.vagrant/machines/workstation/virtualbox/box_meta
.vagrant/machines/workstation/virtualbox/action_provision
.vagrant/machines/workstation/virtualbox/creator_uid

I usually run one Vagrant VM as an Ansible controller (with node.vm.provision :ansible_local) and then 1 to N other VMs as installation targets. To enable access from the controller to the other VMs I include this line in the Ansible inventory: ansible_ssh_private_key_file=/vagrant/.vagrant/machines/{{ inventory_hostname }}/virtualbox/private_key

This should work just the same for running Ansible on your host machine and use it to provision the guest VMs. In this case the path would be a relative one: .vagrant/machines/....

The only important detail is the consistent naming of the VM in Vagrant and Ansible. With the ansible_ssh_private_key_file as above Vagrant’s VM name (set with config.vm.define) and Ansible’s inventory_hostname have to be the same. They are not required to match the guest’s hostname (config.vm.hostname), but I strongly recommend to either use the same value or use an obvious mapping. I usually try to use an FQDN for the hostname, and then use the short hostname (the first component) as the VM name and inventory name.

The only important detail is a consistent naming between Vagrant’s VM name (as set with config.vm.define), the VM’s hostname

postwhite

I recently updated my small mailserver and finally configured DKIM. But another change was easier and still had more impact: installing postwhite. This little tool takes a list of mail domains, then uses their SPF records to derive a list of their outgoing mail servers, then writes this list into a postscreen whitelist configuration. The current default setting contains 43 domains and generates a whitelist with nearly 2000 lines (each containing an IP or subnet). Everything is nicely scripted and can run as a nightly cronjob.

This setup eliminates my biggest problem with greylisting, which is Office356. Their combination of long email resubmit intervals and using multiple cluster servers for delivery attemps always lead to long delays before I received email from Microsoft or any company using Office356. (BTW, I really like greylisting but this is its biggest design problem: it works for single SMTP servers and enforces certain behaviour, but does not and can not consider clusters.)

Links 2017-05-15

On tools …

  • Setting the Record Straight: containers vs. Zones vs. Jails vs. VMs
    Solaris Zones, BSD Jails, and VMs are first class concepts. [..] Containers on the other hand are not real things.
  • CPU Utilization is Wrong
    The metric we all use for CPU utilization is deeply misleading, and getting worse every year. What is CPU utilization? How busy your processors are? No, that’s not what it measures. Yes, I’m talking about the “%CPU” metric used everywhere, by everyone.
  • Practical jq
    I really love jq, the JSON processor. It has changed my life and pretty much replaced Perl and Ruby as my ETL and data-munging go-to tools.
  • Reshaping JSON with jq
    Working with data from an art museum API and from the Twitter API, this lesson teaches how to use the command-line utility jq to filter and parse complex JSON files into flat CSV files.
  • A Visual Guide to What’s New in Swagger 3.0
    Over the past few years, Swagger 2 has become the de facto standard for defining or documenting your API. Since then, it’s been moved to the Linux foundation and renamed to OpenAPI Spec.
  • A plan for open source software maintainers
    As I envision it, a solution would look something like a cross between Patreon and Bugzilla: Users would be able sign up to “support” projects of their choosing […] and would be able to open issues.

let’s learn tcpdump

When I worked on IPv6 implementations I used tcpdump(1) on a daily basis. — Those times are long gone, but even today it is an extremely helpful tool. Just last week it helped me to debug a database connection problem.

To quote the great Rachel: “tcpdump -e can resolve a great many mysteries.”

If you never used tcpdump (or Wireshark) before then Julia Evan’s zine “let’s learn tcpdump” is a great place to start and to learn the 3-7 important command line parameters.

 

Links 2016-09-19

More stuff on cloud and service architecture.

Links 2016-07-18

Thoughts and recipes to build and run systems and services.

  • How to build stable systems
    The first decision is easily the most important. It is one of ideology: the developers are in control of the software. Not the other way around. Managers are not in control of the software. Product Owners are not in control of the software. Developers are.
  • The 15-point DevOps Check List
    The checklist could help you proceed with setting up a DevOps culture but don’t consider it as a unique way to proceed with your organization transformation.
  • 10 Philosophies for Engineers
    In this post and podcast episode, I convey some loose philosophies about modern software engineering. These are strong opinions weakly held. I welcome debate and discussion.
  • 3 Reasons AWS Lambda Is Not Ready for Prime Time
    When I first sat down to write my microservice using Lambda, I really wanted it to be the greatest thing since sliced bread. […] Sadly, it was too good to be true.
  • Microservices & Einradfahren
    Zu meiner großen Enttäuschung muss ich nun feststellen, dass die Leute in der IT, bzw. Developer wie sie heute genannt werden, mit den gleichen Denkmustern arbeiten wie die Business Kasper.
  • Creating a Microservice? Answer these 10 Questions First
    Microservices appear simple to build on the surface, but there’s more to creating them than just launching some code running in containers and making HTTP requests between them.

DevOpsDays Kiel 2016

I finally attended my first DevOpsDays in Kiel. I cannot compare to other events in the DevOpsDays series, but in any case it was a wonderful small one-track IT conference. One with the cosy atmosphere because with less than 200 attendees you can talk to everyone. We had two great days with a beautiful venue on the science campus, good catering, several sponsors, competent speakers, and last but not least a professional and dedicated organizing team.

One interesting observation: DevOps certainly has become mainstream already; because even IBM tells us how to do it.

To see more impressions take a look at the flickr albums. For summaries of the talks read Manuel Pais’ articles on InfoQ (Day 1, Day 2).

OSDC 2016

This year was my second OSDC, and the first one as a speaker. Thanks to Netways for organizing this great conference (and also for inviting me to talk there). The conference archive for 2016 with all presentation slides is now online.
Read the rest of this entry »