DevOps · Manfred Touron

6 pages about "DevOps"

sshportal - An Opinionated SSH Jump-Host

There are many reasons why spaceships don’t have doors that open into the outer space. For one, when a crewmate returns to the ship after visiting a planet, we can do some bio-scanning on them in the airlock, to see if it’s safe to open the doors and let them aboard, or if there’s an alien gestating in their chest.

Maybe the dangers of alien infestation won’t be a concern for at least ten more years, but right now we already are in the digital space, which packs many threats of its own. To protect your infrastructure from an invasion, allow me to suggest a jump host1 named sshportal.

Distinguishing features

Full independence of users and hosts.

sshportal streamlines their management and makes it easy to have multiple users to multiple hosts. They are decorrelated, as only the bastion knows information about both sides – the end user doesn’t have to know the hosts, he is automatically connected to everything he should have access to. So, for example, if a new developer comes into the company or changes their key, the configuration on each of the target servers don’t have to be changed; if the developer leaves, you can remove their access in seconds.

Access to target features

Kitchen, cargo hold, gym – there are many things that an airlock isn’t. sshportal does its job only at the connection, then it “pipes” everything to the target host. So it supports various advanced features, without having any code related to them. Some tested features are: X11 forwarding, port forwarding, tunneling, ssh-agent, sftp, scp, rsync, git support.

Connecting to servers that don’t support SSH keys

…, but only have username/password, This can be especially true for some hardware like internet router or old computers. Once you configure a remote host with the username/password, sshportal will automatically enter the login information. So, other people won’t have to know the login and password – they will connect as they would to any other hosts, using their personal SSH key to connect to sshportal.

“Roles” that provide various levels of access. A user can have access only to a particular host or host group. Login, ssh access, sftp access, and many other features can be enabled or disabled for specific users.

sshportal is also portable, scalable, provides various kinds of statistics and other neat features.

The “invite” system

sshportal was made to be fluid and easy to install and manage, and adding new users is a task that it simplifies greatly. Let’s take a look at a scenario that often occurs when someone in a company wants to access the server:

This person needs to request access from an administrator, to which the administrator will ask for the “public ssh key” of the user – user provides the key, and the administrator manually adds it on the server. Even if the user provides the key along with the request, the administrator still has to ask the user to test the connection, then the user tries and confirms – or doesn’t, which leads to some more steps. This workflow becomes even more involved when you have a user asking his manager to ask the “admin team” or to “open a ticket”, as every step is asynchronous and non-monitorable.

The “invite” mechanism works the opposite way. Admin can create an “invite code” in advance, with a named account that doesn’t have any public ssh key; the first user connecting to the server with this code will automatically link its key with the account. So, after a user requests the access, the workflow goes like this:

Administrator creates the user account sshportal user create toto@company.com. sshportal returns a one-line instruction, i.e.: ssh portal.company.com -l invite:XXXXX that the administrator can give to the user. A user executes the line, and that’s it.

Also, the administrator can check if the user tried to reconnect or not.

Use cases

Used by educators to provide temporary access to students.

A group of over 6000 people is using it internally to manage access to servers/routers, saving hours on configuration management and not having to share the configuration information.

There are companies who use a jump host to monitor connections at a single point.

A hosting company is using sshportal for its “logging” feature, among the others. As every session is logged and introspectable, they have a detailed history of who performed which action. This company made its own contribution to the project, allowing the support of more than 65.000 sessions in the database.

The project has also received multiple contributions from a security researcher that made a thesis on quantum cryptography. This person uses sshportal in their security-hardened hosting company.

A step beyond

There are more things to say about sshportal, but you could visit the GitHub page to check out the demo for yourself and learn more about its features and inner workings. The project is actively supported and has new features in development, like direct access to docker container. Perhaps there is something you personally would like to add or improve? Welcome aboard!

Footnotes

Jump host1 – also known as “bastion” or “gateway” – is an intermediary host that stands between the user and target hosts. It is exposed to the internet and configured to withstand attacks, while the target host remains in the “protected” network, behind the firewall. For more details, here are the Wiki articles on Bastion host and Demilitarized Zo ne.

#code (51) #tool (14) #golang (9) #devops (6) #release (5) #ssh (4)

Docker Machine driver for Scaleway

We just released the Docker Machine driver for Scaleway; You can now use Machine to create Docker hosts on Scaleway servers.

This tool comes as an alternative method of provisionning Docker engines on Scaleway and won’t replace the Docker Instant-App.

Using Docker-Machine, it is now very easy to create a Swarm cluster in minutes: start-swarm-cluster.sh script (output).

It is now easy to manage a Swarm cluster of hybrid servers (x86_64 + armhf).

It is also very convenient to use a Swarm cluster composed of Raspberry PI using the Hypriot OS and Scaleway servers together.

#code (51) #tool (14) #golang (9) #docker (8) #devops (6) #scaleway (3)

docker-diff

docker-diff is a mini tool to quickly compare the contents of two Docker images.

$ ./docker-diff alpine:3.2 alpine:3.3
7,8c7
< ---s--x--x 9944       bin/bbsuid
< -rwxr-xr-x 800936     bin/busybox
---
> -rwxr-xr-x 809128     bin/busybox
63d61
< lrwxrwxrwx 0          bin/rc-status
82d79
< -rwxr-xr-x 9872       bin/uniso
92,94d88
< drwxr-xr-x 0          etc/acpi/
< drwxr-xr-x 0          etc/acpi/PWRF/
< -rwxr-xr-x 19         etc/acpi/PWRF/00000080
105,106c99,100
< -rw-r--r-- 45         etc/apk/repositories
< -rw-r--r-- 12         etc/apk/world
---
> -rw-r--r-- 95         etc/apk/repositories
> -rw-r--r-- 51         etc/apk/world
108,129d101
< -rw-r--r-- 328        etc/conf.d/bootmisc
< -rw-r--r-- 876        etc/conf.d/consolefont
< -rw-r--r-- 55         etc/conf.d/cron
< -rw-r--r-- 348        etc/conf.d/devfs
< -rw-r--r-- 117        etc/conf.d/dmesg
< -rw-r--r-- 1402       etc/conf.d/fsck
< -rw-r--r-- 59         etc/conf.d/hostname
< -rw-r--r-- 857        etc/conf.d/hwclock
< -rw-r--r-- 911        etc/conf.d/keymaps
[...]

#code (51) #tool (14) #docker (8) #devops (6)

Docker + multiarch = 💖

Docker + multiarch = <3

Recently, I started the multiarch organization on GitHub.

Multiarch aims to provide

1. Docker images builds of Linux distributions for multiple architecture

full list on multiarch on Docker hub.

2. tools around multiarch

multiarch/docker-goxc: a ready-to-use goxc in Docker, build GO projects for multiple architectures from an x86_64 host
multiarch/true: minimalist Docker images for multiarch, ideal for testing runtime
multiarch/qemu-user-static: qemu-user-static Docker images for all architectures + a register special image that helps to configure the Kernel binfmt support
multiarch/crossbuild: multiarch cross compiling environments, cross-build C/C++ programs using Docker from an x86_64 host