Show HN: I built a simple, open-source tool to manage servers and SSH keys

I see that you're getting hammered in this thread, so I want to say a few things:

1. Great job on shipping! Whether or not the people in this thread find this tool useful, I want to congratulate you on putting together something you're ready to share with the world.

2. I'd love to hear the story of what prompted you to create this tool. Was it an issue you had? Did you set out to make something easier?

3. Not everything has to be useful to everybody. It's OK if this is something you find useful and no one else does.

Cheers

So, congratulations on releasing your project but I'm not sure what problem are you trying to solve.

Please add some use-cases to make it clear where exactly does it come in, because once I add a key in my ssh config, I'm pretty much there. For more complicated tasks I use ansible.

Question: What is the specific advantage I get from using

    $ viking machine add --name deathstar --key starkey 168.112.216.50
    $ viking exec --tty deathstar /bin/bash

Over putting the following in my ~/.ssh/config

    Host deathstar
        HostName 168.112.216.50
        User my_user
        IdentityFile ~/.ssh/starkey

And then just typing

    $ ssh deathstar

?

From the outside looking in, it's not at all clear what the tool is trying to solve. What exactly is made "easier"..? What does it do that ssh doesn't? Who is this for?

Many questions...

That's a sensitive area for someone unknown to be touching.

You have no information about who you are or what you've done and you expect me to trust you with ssh keys and remotes?

The go.sum is concerning as well because now I need to trust all of those.

https://github.com/d3witt/viking/blob/main/go.sum

I feel like some of these things are solved problems. We store our SSH authorized keys in LDAP, cache it with NSLCD. Backup keys are pushed during setup, rotated regularly. Everything audited through separate systems.

Congratulations on shipping your project!

Before I provide any feedback, I’m curious…

Your GitHub account appears to be a fresh account, using a pseudonym and a DuckDuckGo email address. What’s the reason for all of that? Are you a new developer? Did you simply not have a GitHub account because you never needed it? Is it just some privacy-related reason? Some other reason(s)?

I’d love some clarification on that, if you don’t mind.

To be clear, it’s perfectly fine to not have had a GitHub account—it’s just a bit unsettling when the very first project from a new and pseudonymous account is one dealing with servers and SSH keys.

What's the point of having different ssh key per server?

You are .pub is meant to be shared; even publicly. It's fine to have one ssh key for everything. It's also hard to think about a scenario where one ssh key in your machine is compromised, but not the others.

You are very close to solving a real business problem. The problem is not "how can I have SSH aliases on my computer" but "how can we manage, company-wide, who can access which SSH servers."

My company currently uses YubiKeys to support hardware-based individual SSH keys. These SSH keys are distributed with Ansible. It works but is cumbersome and lacks a single pane of glass.

What we would like to have: a list of servers, a list of users, user roles (via sudoers), and a WebUI to manage all of it. And I don't know of any tool to do this. Of course, there are tools like Teleport or SSH CA instead of SSH keys, but they are for larger organizations and are overkill for my company.

I would rather require a tool to manage host keys. I really wish to write them along with the host configs in my `~/.ssh/config` instead of `known_hosts`. Additionally I think other host keys e.g. from GitHub should be delivered in a better way. For example, on Archlinux I would prefer getting them from package manager instead of being prompt during connection. Unfortunately host keys can only be written in `known_hosts` and `known_hosts` does not support importing or other method to seperate into different files.

EDIT: I was wrong. See comments.

Does anyone have any suggestions?

After having executed an involved ssh connection, my brain often opts to keep working on whatever I needed to use that remote machine for, instead of switching context and saving the details in ~/.ssh/config, even if I expect to use the connection details again.

So I understand the desire to manage both of those tasks, connecting and persisting, from one tool. I wrote a similar little utility that does this by adding a persist option to built-in ssh. https://github.com/emileindik/slosh

Very nice for a first project! (the clipboard integration is a nice touch)

Seeing this passion is great! TBH, some of the negative comments here might be warranted: SSH is an especially important and tricky area to start in as your first Github project or for those inexperienced in security.

However, we're always looking for people at Userify to help us build the next wave of SSH UX and who aren't afraid to put something out there. It's a lot of work to get things built and it's very exciting to see some new ideas. Hit me up if you want to talk!

Personally I prefer to manage my ssh config file manually and I like the way 'stormssh' shows the list of hosts and the options.

https://github.com/emre/storm

You should really look into Ansible, and ssh_config...

why not just utilize a Certificate Authority?

This sounds like Smallstep to me.

r/DIWhy material.

how does this compare to cassh

https://github.com/nbeguier/cassh

assh is another project to consider, altough I falled back to just regular SSH config files and imports.