Live data from Hacker News

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

github.com

51–60 of 97 posts

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

#51
post #45

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_ho…

You can specify multiple files using either `GlobalKnownHostsFile` or `UserKnownHostsFile` options. Plus you can specify a command that will return host keys. See this entry in `man ssh_config`: KnownHostsCommand Specifies a command to use to obtain a list of host keys, [...]

Wow I didn't know that. I will definitely try it! Thx!

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

#52

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.

Some segregation is useful. If a key I use for work never touches my personal machine, that's a good thing. If my work laptop gets stolen I don't want to have to cycle my personal key, etc. I guess the point I'm making is more for making decent keys to create sensible separation points, rather than having one for each machine though. Allowing work vs home vs foo vs bar

Right. We usually recommend a single key per client device (laptop, desktop, etc), because that way you can rotate that key if it gets lost/stolen without changing your other devices as well. This way, those private keys stay totally local to the device and never actually need to move, which is much safer. (I work at Userify.)

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

#53

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_ho…

DNS SSHFP records

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

#54
post #37

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.

> What's the point of having different ssh key per server? I do have some use-cases where I use different ssh-keys per server/cluster: - Setting up client's machines allow me to nuke the keypair when work is done and I no longer have access. Customers trust me to do this - they trusted me to set up their machines already. - Belonging to different projects: so that when the project is finished, handed over or closed d…

I agree!

People should generate at least a single ssh key per client device. (On Userify, rotating your key is just a matter of pasting the new public key into your keybox in your dashboard.) One per client device will let you revoke/rotate only that key when it's compromised. This also helps keep you from copying the private key somewhere else (which you should never do).

It does look like this wants to be a replacement for ssh-agent/ssh-add; also check out GNU keychain by Daniel Robbins, which is in most distro repos.

(blatant plug - we actually developed Userify for these three use cases, especially on cloud instances with constantly changing IP's)

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

#55
post #23

Earlier quoted context omitted.

If you’re managing a ton of servers you are already using ansible or packer or salt or something.

You’d be surprised… a lot of especially legacy setups are very duct-taped together. Heck recently as last year I needed a three machine cluster and just did it manually instead of ansible. I could definitely see the use of a tool like this if it was fleshed out a bit more.

https://www.reddit.com/media?url=https%3A%2F%2Fi.redd.it%2F5...

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

#56

why not just utilize a Certificate Authority?

CA's have a lot of management and logistical issues and potential for misuse. The simplicity and TOFU design of the SSH key system (which obv can bring along some issues of its own) can bring a lot of benefits, especially for people who don't want to introduce a CA or PKI.

(obligatory disclaimer, I work at Userify and we have a server-side product that automates SSH key management and distribution. For example, the CA design doesn't kick someone out once their access is removed, but Userify's shim actually terminates all of sessions instantly, like screen or tmux, across all of the servers they're logged into and removes (but retains for historical record) their home directory.)

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

#57

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_ho…

There's GlobalKnownHostsFile and UserKnownHostsFile. The global known hosts file is usually stored in /etc/ssh, linux distributions could store common ssh host keys in there.

Unfortunately, ArchLinux is not doing so. It is hard to define common though. I guess that's one of the reasons such package does not exist.

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

#58

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.

Here are a few use cases for having multiple SSH key per server: - use a different SSH key for each client machine: if the client machine is lost/compromised, just remove that key from the server's authorized_key - multiple accounts for the same server. This is useful for example to use multiple GitHub accounts

My github-keygen tool allows to manage your ~/.ssh/config for those GitHub use cases.

https://github.com/dolmen/github-keygen

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

#59
post #19
post #13

Earlier quoted context omitted.

Thanks! - No need to remember server IPs - Viking gives you an overview with simple machine ls and key ls commands - A more modern and intuitive API - Works consistently across all platforms - Close to the Docker API Sure, it’s only the first release. It may not seem like much now, but with feedback, the project will move closer to the goal.

>No need to remember server IPs On your local machine under ~/.ssh/config you can add something like #PERSONAL Host vpn-us HostName 1.2.3.4 User my_fun_username Port 1212 now you can ssh using ssh vpn-us (above is the same as the following command --> ssh my_fun_username@1.2.3.4 -p1212)

[dead]

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

#60
post #42
post #13

Earlier quoted context omitted.

Thanks! - No need to remember server IPs - Viking gives you an overview with simple machine ls and key ls commands - A more modern and intuitive API - Works consistently across all platforms - Close to the Docker API Sure, it’s only the first release. It may not seem like much now, but with feedback, the project will move closer to the goal.

SSH already has host and key management via the user's config file. I somewhat understand the desire for an SSH client that behaves like the Docker shell, but it needs some features that actually set it apart. How about putting different hosts into groups, and then running a command on the group so that every machine in the group runs the same command? How about managing both hosts and users so that I can easily log…

[dead]
Post reply on HN