Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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)


Also you can organize servers into different config files and Include them your base config,.

  $ cat .ssh/config
  # Fictitious example
  Include work.config
  Include personal.config
  $ 
https://man7.org/linux/man-pages/man5/ssh_config.5.html


This looks very useful. I did not know this. Thank you!


Hope it helps. I use the configs as a source of truth and have a dozen or so different included files. This way the servers are grouped logically similar to ansible enventories (which I generate using the different configs). Running a command against all servers in one or more configs is simple this way:

  $ grep '^Host' .ssh/<config file> | awk '{print $2}' | while read hst; do ssh $hst '<remote command>' 2> /dev/null < /dev/null; done


One thing I wish ~/.ssh/config had was more slightly powerful matching. I think all you get for dynamic matches is * and ? instead of a regex syntax. Works probably 99% of the time.


It seems there are many aspects of the OpenSSH suite you are unfamiliar with.

I would personally prefer using well-known tools over installing someone's latest project to handle something as sensitive as my SSH credentials.

Installing code instead of editing my .ssh/config seems like a gigantic risk.


> No need to remember server IPs

If I put my server's IP in my ~/.ssh/config, I don't need to remember it, and the autogenerated `~/.ssh/known_hosts` file will ensure that the IP doesn't change after my first time connecting. Is there some functionality beyond this in terms of remembering server IPs?


Like other commentators have already mentioned but the openssl suite already solves these problems and even more complex ones

For example:

Specifying different keys different servers

Host github.com

    User git

    IdentityFile ~/.ssh/id_rsa_github
Host myserver

    User username

    IdentityFile ~/.ssh/id_rsa_myserver
Reuse SSH connections for multiple sessions

https://blog.scottlowe.org/2015/12/11/using-ssh-multiplexing...

https://blog.poespas.me/posts/2024/04/27-optimizing-ssh-conn...

Host *

    ControlMaster auto

    ControlPath ~/.ssh/sockets/%r@%h-%p

    ControlPersist 600
Other than that, you can also do ssh agent forwarding, port forwarding etc. These are all crucial functions that user like me need when we access remote machines.

I hope you take this as constructive criticism and not a knockdown on your work. You've created and released something that's great but this site usually brings more advanced users.


Essentially you wrap via CLI what you can code in ~/.ssh/config, I'm not so sure how this could be comfy.


Right, I don't see the point of this at all. If anything it seems like more of a pain in the ass than just using ssh directly.


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 into a system as different users for different purposes?

How about adding some security features to make key management more secure than the standard "everything in the .ssh directory" strategy?

Maybe add some SCP/SFTP features so that moving files from host to host is easier. Maybe even have a package you can install on remote hosts so that they can transfer files directly between each other when asked to from an outside terminal.


> 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?

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
> How about adding some security features to make key management more secure than the standard "everything in the .ssh directory" strategy?

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.


"putting different hosts into groups" - it's on my radar "Maybe add some SCP/SFTP features so that moving files from host to host is easier." - sounds good, I'll check


> No need to remember server IPs

Umm, DNS?

> with feedback, the project will move closer to the goal

What goal? That was the question you replied to.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: