Show HN: Ssh2, simplifying EC2 ssh'ing | Hacker News Reader

Show HN: Ssh2, simplifying EC2 ssh'ing

github.com

51 pointssoheil50 comments

Nice idea, but needs a bit of refactoring:

hardcoded paths like '/tmp/.ssh2_list' should not be used. This is insecure and wouldn't work on (most) multi user systems. Something like os.path.expanduser("~/.cache/ssh2_list") should be used instead.

  f = open(cache_file_list, 'w')
  f.write(output)
  f.close()

can be written as

  with open(cache_file_list, 'w') as f:
    f.write(output)

This:

  i = 0
  for instance in all_instances:
    i += 1
    #..
    print '%-4s%-55s%-30s' % ('[' + str(i) + ']',
      instance['PublicDnsName'], name)

Simplifies to:

  for i, instance in enumerate(all_instances, 1):
    choice = '[%d]' % i
    name = extract_name(instance) #function instead of copy/paste    
    print '%-4s %-55s %-30s' % (choice, instance['PublicDnsName'], name)

Also would kind of make more sense to support matching on the name of the instance rather than requiring a number. In your case, 'ssh2 cron' makes a bit more sense than 'ssh2 0'

Might be better to open an issue.

https://github.com/soheil/ssh2/issues

I'd do it, but I have to run.

Just made those changes, will update the tmp path.

Since this is Python, you can use the built-in tempfile module to securely create/delete temporary files

https://docs.python.org/2/library/tempfile.html

Additionally, a feature where the command line argument is applied as a wildcard search against the list of hosts would be nice, with the default behavior being to ssh into the first match when there's only one matching host.

> os.path.expanduser("~/.cache/ssh2_list")

Please, consider $XDG_CACHE_HOME. Not everyone likes the default directory layout.

I think, ugly-looking but reasonably portable version would look like

  os.path.join(os.environ.get("XDG_CACHE_HOME", os.path.join(os.path.expanduser("~"), ".cache")), "ssh2_list")

Took care of this, thanks for the tip.

Nobody does a quick Google search for name clashes these days? "ssh2" is the name of the protocol, to distinguish from SSH protocol 1.0.

The name is confusing.

https://en.wikipedia.org/wiki/Secure_Shell#Version_2.x

Agreed, ECSSH2 is either a convoluted replacement or a nice play on both technologies depending on how you look at it... although that could be confused with ECDSA - naming things is hard!

ec2ssh? ec2sh? ec2s?

soheil, you should note that blurring digits is often an ineffective way of preserving privacy.

In this case it looks as if the blurred data is only IP addresses, so unlikely to cause any real damage on its own. But API keys, passphrases, private keys, and the like -- don't use gaussian blur. Crop them out or overwrite them entirely with an opaque color.

Also, don't put anything important in /tmp. As a practical matter it won't matter much if no one else has access to this machine. But it's a good habit to get into.

It's OK to put stuff in /tmp if you pay attention to permissions. ssh-agent puts its named pipes in /tmp

All /tmp usage is not the same. ssh-agent uses mkdirtemp or similar, and does not hardcode a single path.

Good point, I was thinking about it, decided blur looked better. For more important things I will start using an opaque color.

Thanks for the /tmp tip.

and you also forgot the window titles.

but it doesn't matter anyways. all IP addresses are by definition public; there are only about 4 billion of them anyways, less than there are people on Earth. you should probably focus more on making your code secure rather than obfuscating your IP address in screenshots.

for example, in addition to what has already been said about /tmp, system() is almost never the correct answer. in this case, if options.user or dns contain "special characters" they may be interpreted by the shell differently from what you intended.

Also, don't assume /tmp is the right directory. Always read the $TMP environment variable.

Read $TMPDIR. If you are feeling generous, then check $TMP if $TMPDIR isn't set.

On that note, you may also be interested in $XDG_RUNTIME_DIR (complex-ish semantics) or $XDG_CACHE_HOME (Default: ~/.cache/)

Hi, just a FYI, found a typo on the mainpage... You can select <<form>> a list of running servers under your account.

Ordinarily the IP address wouldn't give you much to go on but another screenshot leaks more info - including the fact that this server is 180 security updates behind!

putting stuff in /tmp is fine if you use something like mkstemp to prevent symlink races, using a well known file name is certain bad however.

A related tool, I wrote ish: https://github.com/grahamc/ish which lets you log in to a machine by name, tag, instance ID, AMI, etc.

This should be higher, it's a much nicer effort.

Very useful. I'm currently using ~/.ssh/config. I gave nickname for the servers and all parameters are in the config:

  Host my-foo
  HostName 54.xx.xx.xx
  User my_user
  IdentityFile ~/.ssh/server_key.pem

So, just: ssh my-foo

Yeah that's what I do too. How is ssh2 any better? Especially considering (IIRC) that tab-complete works for ~/.ssh/config .

We're using a wrapper around SSH which generates an ssh_config file listing our current EC2 instances, including aliases for instance id, role, and name tags. It does slow down starting SSH if you don't have the list of instances cached, but otherwise is pretty nice.

Do you mind share your script? It seems very useful.

At the moment its a horrible hack which is so specific to our environment I'm not sure I want to share it, but I might make something more generic and share that.

I was about to post the same.

~/.ssh/config with identity files (certs) is the right way to ssh.

And ssh config entries can be used in other software, for example I use them in mc.

Nice work!

Consider something like mkstemp() or mkdtemp() instead (really, it should be marked 'insecure' until updated.)

https://docs.python.org/2/library/tempfile.html#tempfile.mkd...

It's a great idea and might work well w jumpbox config @ Userify ... I'll send over a pull request if I get a chance this week!

Looking forward to it.

Another way to do the same thing by registering the hosts in your SSH config file:

https://gist.github.com/4704110

I'm curious: why would I use this over just assigning DNS names to the instances?

DNS names where? How long does it take for the updates to get to whatever resolver you're using?

If the instance name is new, instantly. (As long as nobody queries it prior to the record getting created, of course.) Otherwise, the TTL. We use either 1 or 5 min TTLs where we expect changes for exactly this reason, and in practice, it isn't a problem.

If your servers are 'permanent', then give them a short hostname and put them in your .ssh/config and DNS (or hosts file). 'ssh cron' or 'ssh archive' and connecting directly is quicker than going through a dialogue, or using an index number and having to remember which is which (or worrying about the index number changing when you refresh).

This tool would be good for temporary or autoscaling instances, though.

I made it primarily for my temp servers, it's also useful if you keep restarting a box as the DNS name changes on reboot. As someone else also mentioned I think a nice addition would be to allow the name to be passed instead of just the index. The thing with temp servers is that, I don't usually bother to name them, hence again, this tool.

If you have instances in a VPC, they will keep their IP addresses until you destroy them. Turn them off for a week, then back on, and they bounce back with the same IP as before.

EC2 classic servers will also keep their IP addresses (and hence aws-assigned hostnames) through a reboot (in which the VM itself doesn't actually get torn down), but not through a stop/start cycle.

Edit: If your tool works for you, go for it. I don't mean to sound discouraging.

Thanks for clarifying the reboot sequence, I do, however, stop/start instances on a regular basis to save cost. Also good to know VPC behaves differently in that respect.

I'm working on adding VPC support.

Ideally, none of your servers on EC2 should be 'permanent' :) Although having EBS available makes it easier to start relying on them as if they are permanent.

This is my take on this: uses a tagging convention on your EC2 instances. Can also run commands in parallel over a set of instances.

https://github.com/madebymany/moltar

http://madebymany.com/blog/a-little-tooling-goes-a-long-way

Pack this up and get it on PyPI! Nice simple little script but quite inconvenient to get onto a system, especially if one prefers using package managers.

This is one of the first scripts that I made myself after migrating to ec2. I initially programmed it in ruby, but just recently re-wrote it in Go. I don't cache the hosts and it usually takes around 0.5 - 0.7 seconds. My ruby implementation was much slower due to the libraries I was using needing to be loaded in each time it ran as opposed to the Go compiling ahead of time.

I have all my servers listed in my .ssh/config file with nice short names. With a simple alias on the command "grep -A1 '^H' .ssh/config | grep -v '--'", I can display the full list (amazon, but also scaleway, clouscale, my home box, ...).

What stores the SSH private keys ? I hate having to manage my private keys across work machines.

Filters and tab-completion would be nice when you have hundreds of EC2 instances.

I've also seen tab completion on `ssh` which matches EC2 IDs & "Name" tags, but can't find the project right now.

I think you also would like use https://github.com/haosdent/s to simplify ssh login.

Quick question regarding best practices - do you prefer connecting to an ec2 instance using the `.pem` file or do you transfer your ssh keys the first time you connect?

Thanks,

I personally do the latter but it's obviously an extra step in the provisioning process.

Offtopic: on the screenshot "180 updates are security updates" on apparently live service makes me sad...

This is a freshly spawned up test machine;)

Reply on news.ycombinator.com