Category Archives: Events

Paris! eu-west-3

Category : Events


AWS grows by both increasing their services as well as adding new regions to their cloud infrastructure. The region Paris was announced but for now (May 11, 2017) it is not yet available in your AWS console.

But we also have a small S3-based website running that measures latency from your current IP address to all regions available; Ping. Preventing maintenance, the tool ‘discovers’ all available regions by scanning the AWS endpoint API. And that’s how we found *this*:

Paris up-and-running? Well, not yet but that should not take long looking at what AWS API’s already communicate. Do monitor our selec2or tool as well since that will also automatically update when pricing information comes available 🙂




i am here

Category : Events

As an AWS consultant/trainer I travel a lot for my work. When at customers locations, I occasionally want to log in into our sandbox environment. In previous postings, I have shown how we increase security by switching on and off the bastion host with a single (or double) key-press of the AWS IoT button.

In another post you can find how I setup my ssh configuration to use the bastion host without ever logging in to it and yet get access to our ec2 instances.

In this post, let me share iamhere with you. It is a little script that I use to modify the security group that protects inbound traffic to our bastion host. The bastion host has a security group attached to it that ‘whitelists’ the IP addresses of our office locations. But when on the road, that is of no use – unless I would first setup a VPN connection to our onprem infrastructure, which defeats the whole idea of using ‘The Cloud’.

So I added an extra security group to the bastion host, named ErikIsHere and the iamhere script on my laptop configures that security group to whitelist my IP address – wherever I am. With the -c option, the whitelisted ports are removed again.

It’s just a quick hack, so use it as is but feel free to adapt it for your own use! You find the script here.

And if you ever wonder where i am, probably in the cloud somewhere …

SSH config for AWS bastion

Category : Events

As a roaming AWS trainer, I work on my AWS infrastructure from many different locations to give demos to the course attendees and prepare stuff in EC2 instances when necessary.

When I launch instances, I usually do so in private subnets, not opening the instances to the Internet when not absolutely necessary. To access the instances I use what is called a stepping stone, jump server or bastion host.

The idea of a bastion host is that it is the single point of entrance into your (cloud) infrastructure. Therefor, you should harden and secure that host to the best extent possible. Read my blog about switching on and off the bastion host with the press of an IoT button to see how that can be implemented on AWS.

After the bastion host is started, just how do you get in the bastion and subsequently in the other instances ‘behind’ the bastion host? It all begins with keys. SSH Keys, that is. Of  course, you use a different key for the bastion host than for other instances you want to access. Should one of the keys be compromised not everything is lost!

For the bastion I use a key called bastion.labs.easytocloud whereas for ‘normal’ instances I use a key called labs.easytocloud

Our bastion host has an entry in my .ssh/config file that looks like this:

Host bastion-labs
        User ec2-user
        IdentityFile ~/.ssh/bastion.labs.easytocloud
        ForwardAgent no

So when I type ssh bastion-labs I will be logged in to the bastion specified automagically, using the correct key.

Now I could login to the bastion and then ‘hop’ to the target instance behind it. But where to store the key of the target instance? If I store that key ON the bastion host, it defeats the purpose; when the bastion is compromised, the intruder has the key to go to the target host. No extra security there!

In AWS courses, attendees are encouraged to use SSH agent instead. SSH agent runs on your local (desktop/laptop) and serves keys over the very SSH connection that you make with your bastion host. Consider it a kind of ‘call back’ from the bastion to the originating device. Good from the perspective of not storing keys on the bastion, but when the bastion is compromised, the attacker only has to wait for you to login to be able to ‘call back’ to your device to get the key. As both the bastion and the final target keys are stored on my laptop, any intruder on the bastion can get the subsequent keys from my device when I login. Read more about this in SSH agent forwarding considered harmful. Nothing really changed since goto was banned 😉

So, now what? Of course we could run some VPN server in our bastion. And in fact, we do. But as a roaming user, I too often get into locations where VPNs are blocked. That is where port forwarding comes in.

When connecting to an instance in our labs VPC, I first create a tunnel to the bastion and then run an ssh command over the tunnel to the target machine. This is implemented with the following bit in .ssh/config:

Host *.labs
        User ec2-user
        IdentityFile ~/.ssh/labs.easytocloud
        ProxyCommand ssh -q -W %h:%p bastion-labs

As a bonus, my laptop connects to the target machine, rather than to the bastion, so that when I copy files from and to a cloud instance, I don’t have to park them on a relatively slow/small bastion host. The security group on the target instance allows ssh traffic only from the bastion, as that is where it *really* comes from. In fact, we use the security group of the bastion host as an allowed source in the security group definition of the target instances.

The bastion host has a security group attached to it called ‘ErikIsHere’. This security group opens the bastion for VPN and SSH from my present location. To change the security group to reflect my current location, I have a script on my laptop named ‘iamhere’. It reconfigures the security group ‘ErikIsHere’ to open the relevant ports with my laptops current (public) IP address as source through a series of AWS commands.

When I arrive at a (course) location, i type iamhere on my laptop to configure the security group, start the bastion and thereafter can ssh to instances ‘behind’ the bastion host.

To find the IP address of such instances, we use AWS private hosted zones; a DNS service within the VPC. Whenever we launch an instance in the labs VPC, a DNS record for that instance will is added to the private hosted zone. This is achieved with AWS Cloudwatch Rules. A lambda function is called whenever an instance starts or stops and registers that instance’s name (as set in the Tag called Name) in DNS. All instances in the VPC use this private hosted zone for DNS information, so when we launch an instance named foo, foo.labs will be registered and any instance in the labs VPC can resolve foo.labs to the instance private IP address. From my laptop I now can connect to foo.labs by typing ssh foo.labs!

Here is how that works. I added an entry in my ssh config for  *.labs (see above) stating to use ec2-user as username and the labs.easytocloud key as ssh key. But before that, it will setup port forwarding to the bastion host. Real cool bonus here is that the resolving of foo.labs is actually handled by the bastion host! My laptop wouldn’t be able to resolve foo.labs, but the bastion host is.

So, any new instance I launch in the labs VPC using the labs.easytocloud SSH key, will be directly accessible from my laptop using no more than the name of the instance. Not only for ssh login, but also to copy files using scp:

$ scp large-local-file foo.labs:/tmp/remote-file

More often than not, ssh and port forwarding is sufficient for my needs. It has been an alternative in situations where VPN was blocked. With the added value of name resolution of instances in the VPC.

Veritas and AWS technology alliance

Last week, Veritas and AWS announced that they formed a technology alliance to bring the capabilities of Veritas 360 Data Management to AWS users. This did not surprise us as we know and understand both companies’ technologies and already recognised the potential that the combination presents. Possibilities include:
Orchestrated failover and failback to and from AWS
Combining AWS with Veritas Resiliency Platform (VRP) enables fully automated recovery of virtualized infrastructures to AWS. Standby datacenters can be consolidated to the cloud, saving money. Migration can be tested and easily rolled back, saving time.
Legacy applications without refactoring
Enterprise applications like SAP and Oracle have their own specific mechanisms to ensure performance, resiliency and scalability, and would need refactoring to adapt to the near infinite scalibility that AWS offers. Veritas InfoScale for AWS is the viable alternative to refactoring, simplifying the customer experience through a unified management console.
Cloud tiering software defined storage
Veritas Access and Amazon S3 combine to provide a low-cost storage tier for unstructured data workloads already. Later this year, Access will be available as a full featured cloud solution to enhance application performance while minimizing cost.
Unified data protection provided by Veritas NetBackup ensures a simple and reliable experience, no matter where your data resides or which platform is used.
You can read the full article about the alliance here. Please contact us if you would like to know more about the possibilities for your organization.

The Guru is Back In!

Category : Events

Some fifteen years or so ago, at Open Solution Providers we had the urge to share our knowledge on Unix where we could and in any way, shape or form we could. One of the options to use our consultants at the time, was to book us for a day where customers could ask us anything – Unix related. We called it

The Guru is In!

The idea was that, although formal training is good for fundamental knowledge, it is not always possible to tailor a training to the knowledge needs of our customers. And a single-day consultancy assignment is hardly worth the effort.

“The Guru is In” – something in between training and consultancy

You might have some questions on (niche) subjects that are not covered in any training, for example.

Alternatively, we could help you with something hands-on work, too small for a formal consultancy assignment.

Or you need a ‘second opinion’ on something you have designed but are not 100% sure about.

We have spotted some demand for this kind of consultancy and informal demand-driven workshops on AWS and are happy to announce today

The Guru is Back!

With this re-newed service, brought to you by easytocloud, one of our AWS consultants comes visit your office to answer any questions you might have – AWS related, that is.

All we ask is for you to prepare is a room with a beamer and whiteboard. The interactive character of the sessions means we will not use any pre-cooked slides, but draw on whiteboard and demonstrate on our laptops instead.

State the overall type of questions you have (architecting, sysops, security, development) when you book, so that we can send the right ‘guru’.

The price for “The Guru is In” is € 1.250,– Add travel and expenses for deliveries outside of the Netherlands. To ensure the right amount of interaction, please make sure you have between 4 and 12 participants.

Call +31 20 49 50 224 today and get the guru in!