A command line tool to manage your ssh connections | Hacker News Reader

A command line tool to manage your ssh connections

github.com

34 pointsthromba32 comments

Is it really easier than just editing ~/.ssh/config? In the config, you can use wildcards for groups of servers

    Host *.whatever.net
       IdentityFile ~/.ssh/whatever-key
       ServerAliveInterval 10
       port 1022

and then add specific information and aliases per host

    Host someserver.whatever.net someserver ss
      Hostname someserver.whatever.net
      User spin

    Host otherserver.whatever.net otherserver os
      Hostname otherserver.whatever.net
      User dritf

Plus, since you probably edit it only once in a while, you don't need to remember the syntax and can simply base new additions on existing entries.

It seems like one of those situations where it is better to just learn the tool you're using instead of learning a tool to configure the tool you're using.

It's probably not much easier, but the tool is almost certainly less error-prone. I like to see this extended with a GUI, but it's a good start.

I doubt it's less error-prone. SSH config files aren't particularly complicated, and if you get it wrong, it's easy enough to fix - just edit the file again.

I hate to be snarky but having read through the code this really isn't a big thing. It's a tool for people that can't use .ssh/config.

Manage your SSH like a boss? Perhaps, but only in the pointy-haired can't-read-man-ssh_config boss sense of the word.

For those that don't want to install a script and would prefer to understand the tools they already have try this:

http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-...

There are a lot of tools like that for years.

like;

- managing /etc/hosts - managing crontab

It's just a preference to do it with a command line tool, or just doing it in the config with editor.

I don't have a problem with the tool. If it helps people it's doing a good job. My problem is only with the article title overplaying it's utility somewhat.

I agree with the comments to just freakin edit your .ssh/config. But, it clearly states "SSH like a boss". The implication I take means "configure ssh for people who don't know how to use an editor, can't read man page, don't know where man pages are, and can't find/don't know about .ssh."

So, not for us. We can move along and be happy someone else is taking care of those people.

The people who can't use an editor, read a man page, and don't know about SSH a) probably don't need this and b) would probably have just as hard of a time figuring out how to use this CLI utility as they would learning nano and .ssh/config syntax.

    vim ~/.ssh/config

I've built a script that creates the config by querying EC2 for servers, this avoids having to pass around server names when new servers are created. Just run the script and every server is added.

When I saw the project name, the first thing I thought of was: https://github.com/nathanmarz/storm

And I was https://storm.canonical.com/

Honest question:

Why is this preferable to using:

vim/emacs/subl/nano ~/.ssh/config ?

It is not.

Very cool. I'd love to actually set this up with some scripts as a way to manage server migrations or new servers

I'm actually working on a web-based gui for managing ssh configs and I'm likely to switch to python and reuse some of this

happy to hear that :)

loading and dumping ssh configs would be tricky. let me know if you need further assistance.

What does this add over just editing ~/.ssh/config with $EDITOR?

Nothing. Maybe just getting a list of host entries in a clean way.

It becomes useful when: You have a large number of items in your ssh config, say 20-100+ and you don't want to jump around in vim. When you want to control teams' ssh configs using scripts. If you have a team of developers that all have this installed, you can now update ssh configs just by having them run an executable or possibly by some sort of job queue. Want to switch to key-based access for an old server, delete a different old server and give devs access to a new server without having to coordinate and answer questions with 20+ people? You now have the ability.

Very nice work

In OS X, by pressing Cmd+Shift+K whilst in Terminal.app, you can save SSH, SFTP, FTP and telnet connections. Personally I don't use it but some people might prefer it.

I read through the readme and I couldn't figure out how this is an improvement over ssh_config(5), other than adding Yet Another Dependency.

If this could make key management significantly easier (e.g. no need to rely on the buggy GNOME keychain app) or make it easier to manage persistent connections (ControlMaster is trivial, but juggling dozens of connections and gracefully terminating/resuming them is not), maybe it would be genuinely useful.

For the time being, though, this just looks like a lightweight editor for ssh_config.

The boss wants putty, the user can edit .ssh/config by himself already.

more easy to write bash aliases like alias ssh-web="ssh username@host" and you take bash completion support

There is bash completion for ssh.

Its included as part of the bash-completion package on most distributions of linux.

Its got extremely good completion support for hostnames

It has the added advantage of also auto-completing for scp.

SCP autocomplete is very useful indeed. Especially when using ControlMaster, then autocomplete is almost instantly.

you can override some of the ssh options if you use it with sshconfig.

example ssh config: Host vps hostname 1.1.1.1 port 22 identityfile /home/emre/.ssh/vps.pub

If you want to override stuff, just do it like ssh vps -p 99.

And there is bash completion support with ssh, too. try it.

ssh <TAB>

I can see this being useful if you have lots of keys and the server kicks you when you try too many of them, but in theory you really shouldn't need more than one key.

http://www.funtoo.org/wiki/Keychain

slightly exaggerated: by that logic only one password should also be enough.

If the integrity of a password was dependent on a one-time unlocking mechanism secured on my local machine, then yes, you would only need one password. Passwords are not public key cryptography.

No, that's a little different. The problem with password reuse is that if someone breaks into a site and steals the passwords, or a malicious administrator steals your password, they can reuse it. The public/private key separation of ssh keys means that that is much less of an issue. You can't login to another server with my public key.

Reply on news.ycombinator.com