Yeah, as a neckbearded network and systems engineer I really don't understand this thing at all - it should be a non-issue. Specifically, because the OP states the machines are mostly dedicated machines, there should be absolutely no reason why they don't have dedicated hostnames in DNS, either locally or globally.
At organizations where I have held the above titled roles, DNS was one of first things to be put into service if it had not already been used. Connecting to the IP address of a dedicated machine by a nice name is pretty much what the DNS was invented for. DNS is very much not static and if you are changing a host's IP very often, you can set it up such that the DNS responds appropriately with the proper up to date IP address.
OP's script is nice but... it's solving an already solved problem, IMO.
Another great way is to just modify ~/.ssh/config
To something like this:
host alias
hostName thehostname
user your_username
I like the work in the article, but many times when I think I need to whip up a sweet script to fix some problem in the terminal I find the old neckbeards already wrote it, polished it, and left it on the shelf for me to use.
Perhaps different use case - but I prefer to use a VPC with internal addressing and DNS. Particularly if you're using more than just a few instances.
Then have a bastion host in a DMZ that forward to the actual instances (I prefer 172 as it tends to avoid clashing with wifi networks). This does cost you a m1.small Amazon instance, but if you reserve it the cost is negligible.
Even better. You can do this automagically with ssh by putting a suitable `ProxyCommand ssh <bastion> "nc %h %p"` in your ssh config. So you just `ssh 172.0.0.10` or ssh `my-internal-name.blah` and it tunnels straight in for you.
You can pair this with internal DNS if you want to get really fancy - although it's a bit fiddly. From what I read internal DNS is pretty high up on the Route 53 feature request list.
So I use almost exactly the same approach except in the VPN configuration options (I use Ubuntu 12.04) I just set the search domain to my-internal-name.blah, as well as, making sure the VPN connection is only used for resources on its own network.
Then as part of my bootstrapping I register the VPC instance's internal-ip address on route53 under the my-internal-name.blah zone.
If you're looking for something a little more packaged and not averse to installing a Ruby gem, this will manage multiple AWS accounts and allow you to ssh/scp using AWS instance IDs as the target:
https://github.com/mheffner/awsam
Hi! I'm the author of the blog post that you listed in your article. Glad you found it useful; it surprises me to this day, almost 2 years later, at just how many pageviews it continues to generate.
However, I would like to point out that the correct solution to this problem is DNS, as others here have indicated. Couple Route53 with something like Zonify (http://nerds.airbnb.com/easy-aws-inventorying-with-dns/) by the fine folks at AirBnB, and you've got something quite powerful that is diff'able via your normal tools, and can be easily versioned for sanity and safety.
Don't let my comments (or the comments of others here) detract from the pretty clever approach that you took. I think it's the fate of every ops/devops to, at some point in their careers, create a host address storage/querying system that contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of DNS without realizing it the first time around.
I'll even admit that I once had a particular client whose hosts I managed with a Makefile that grepped a HOSTS file. I am ashamed and my neckbeard is burning!
DNS is a good solution here, but it also seems appropriate to highlight that you shouldn't need to be connecting to these instances directly. As others said, some type of configuration tool should be in place, logs should be centralized, storage should be centralized, queues should be elsewhere. Painful ssh config is a symptom of a different issue.
This is a pretty complicated solution. There are a ton of easier ones, but probably the easiest is to just use ec2-ssh. It lets you apply tags to your ec2 instances and ssh to them by very simple names.
25 comments
[ 3.4 ms ] story [ 72.1 ms ] threadAt organizations where I have held the above titled roles, DNS was one of first things to be put into service if it had not already been used. Connecting to the IP address of a dedicated machine by a nice name is pretty much what the DNS was invented for. DNS is very much not static and if you are changing a host's IP very often, you can set it up such that the DNS responds appropriately with the proper up to date IP address.
OP's script is nice but... it's solving an already solved problem, IMO.
host alias hostName thehostname user your_username
I like the work in the article, but many times when I think I need to whip up a sweet script to fix some problem in the terminal I find the old neckbeards already wrote it, polished it, and left it on the shelf for me to use.
Then have a bastion host in a DMZ that forward to the actual instances (I prefer 172 as it tends to avoid clashing with wifi networks). This does cost you a m1.small Amazon instance, but if you reserve it the cost is negligible.
Even better. You can do this automagically with ssh by putting a suitable `ProxyCommand ssh <bastion> "nc %h %p"` in your ssh config. So you just `ssh 172.0.0.10` or ssh `my-internal-name.blah` and it tunnels straight in for you.
You can pair this with internal DNS if you want to get really fancy - although it's a bit fiddly. From what I read internal DNS is pretty high up on the Route 53 feature request list.
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dn...
Then as part of my bootstrapping I register the VPC instance's internal-ip address on route53 under the my-internal-name.blah zone.
Then I can simply do ssh staging01, etc.
However, I would like to point out that the correct solution to this problem is DNS, as others here have indicated. Couple Route53 with something like Zonify (http://nerds.airbnb.com/easy-aws-inventorying-with-dns/) by the fine folks at AirBnB, and you've got something quite powerful that is diff'able via your normal tools, and can be easily versioned for sanity and safety.
Don't let my comments (or the comments of others here) detract from the pretty clever approach that you took. I think it's the fate of every ops/devops to, at some point in their careers, create a host address storage/querying system that contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of DNS without realizing it the first time around.
>>ssh -i <yourkey> ec2-user@<yourinstance>.amazonaws.com
isn't it the easiest it can get to?
https://pypi.python.org/pypi/ec2-ssh