81–90 of 97 posts
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
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…
Earlier quoted context omitted.
cassh is a manager for CA's in SSH. CA's were added to SSH to satisfy people who thought PKI was a good idea; it's not, and SSH pubkeys are far better IMO. Better to use a tool like Userify (or similar like SSH.com) for pubkey management.
At least certificates expire, and can list capabilities right in the certificate?
With Userify, sessions (like tmux or screen) actually get terminated within seconds when the user's access is removed. That doesn't happen at all with certificates.
If someone's certificate expires, but they're still logged in, they'll stay logged in, because there is no mechanism to kill their session (and they can channel all kinds of things over their logged-in session).
That's an absolute nightmare for compliance.
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.
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 everyth…
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 everyth…
That was very well put. I noticed an increasing negativity in Show HN posts lately. The usual inquisitive and supportive comments are being replaced with straight up negative and dismissive ones (or maybe it was always like this and people being nice is just a fabricated memory of mine)
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…
That can be done with a simple awk/fzf script, which would even allow me to interactively chose the hosts from the ones configured in the ssh config.
> How about managing both hosts and users so that I can easily log into a system as different users for different purposes?
The ssh config already allows doing that:
Host prod-as-foo
HostName domain.of.prod.server
User foo
Identity File ~./ssh/foo.key
Host prod-as-bar
HostName domain.of.prod.server
User bar
Identity File ~./ssh/bar.key
IdentityFile keys can be setup to be symmetrically encrypted, requiring a password on use.
The keyfiles can also be loaded via `ssh-agent(1)`, allowing to directly use non-local keyfiles (source: `man ssh`)
> Maybe add some SCP/SFTP features so that moving files from host to host is easier.
Both `scp` and `sftp` already use the ssh config file.
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
The goal is to simplify the entire server management and deployment process for personal/small team use case, extending beyond just handling SSH keys.
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 would argue this should be 100% avoided in production environments at this time.
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 ?
as someone who dislikes config files to an extreme degree (hidden information, commands stop being portable) a modern cli that allows me to manage my configurations seems very useful
Create entry (using a template and exported variables):
$ envsubst > .ssh/config
$ sed -n //,+3p .ssh/config
Delete entry (assuming the 4 line template):
$ sed -i //,+3d .ssh/config