Comment by h4ch1 | Hacker News Reader

Comment by h4ch1 | Hacker News Reader

Parent Full thread

Can't comment for others but for me I find zoc or in that regard, a SSH client useful for the following

1. Remembering multiple hostnames and keys in a centralized location

I manage a fleet of VPSs, whose hostnames, credentials I don't always remember off the top of my head. Writing ssh -i <identity> <hostname> gets tedious when I'm wrangling multiple of them over a single session

2. Faithful terminal emulation

Zoc does a great job at emulating a plethora of terminals; it's not a do or die feature, but nice to have.

3. Separation of concerns

This is a personal reason, but I like having two different applications while I am doing something that needs me to SSH to multiple VPSs, my main terminal will have local commands, local file editing, etc while my SSH client will only be used for remote connections and management. Just helps me keep things tidy for myself.

Also as I mentioned in the parent I primarily use my main terminal to SSH; but for the cases mentioned it's nice to use a separate client.

I don't have your use-case, but I use the `.ssh/config` to give aliases (Host/Hostname) to my remote machines and can set the identity to use there (IdentityFile).

> 1. Remembering multiple hostnames and keys in a centralized location

There’s ssh_config(5) for that.

This may be tinfoil, but this is the kinda configuration that I want version controlled, and I've never felt good about adding ~/.ssh/config (or anything within ~/.ssh) to my dotfiles because I definitely do not want its siblings in version control. And I don't trust myself not to bone myself.

Instead I have some files elsewhere that I source into my terminal on start, containing:

export M4MINI=192.168.1.204

I'm pretty sure SSH wouldn't mind the config being a symlink to a file in your safely-held-elsewhere repository. Maybe I'm wrong. (m)DNS is what I'd really go for if I'm really just looking for easy access to names.

I wouldn't worry, but I also have the habit of adding things to the index explicitly. If I did worry: gitignore.

In fact, the symlink thing is exactly how we distribute the common ssh config as an included file within the team. The config is part of the infrastructure repo, and everyone gets a current version whenever they pull afresh.

I'm also not sure why version control on ssh config should be a problem, unless previous poster confuses version control and "send everything to the cloud".

You can use "Include file/location" in your ~/ssh/config.

I don't understand, though, why you would not want to init a git repo in ~/ssh? What am I missing? It's not like "having version control" is the same as "upload it".

Reply on news.ycombinator.com