File format: as many of the following blocks as you like
Host $ALIAS <-- whatever you want here
Hostname www.example.com
User someuser
Port 1234
You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.
What is more, you can specify an abstraction
for the tedious double-ssh where you first connect
to some internet-facing host in order to gain access
to an internal machine:
The ssh -W option -- which replaces netcat -- is relatively new. E.g. Redhat 5.x did not have it, nor did Ubuntu 10.04 LTS. Until OpenSSH 5.4 netcat was the way to do this sort of proxying.
I found references to it going back to 2008, and the git repo that has my dotfiles says I've been using it (in Linux) for 3 or so years. Maybe it depends on the OS/distro.
The patterns are similar to shell globs: * matches zero or more characters, ? matches exactly one.
I've worked around this by creating a ~/.ssh/config.d directory and splitting my configuration out into multiple files (normally by project). I then use dotdee[1] to watch that directory and automatically rebuild ~/.ssh/config anytime there is a change.
I don't know of any, but one thing you can do is split up your config into multiple files and then use `cat` to combine them after making a change. There's also https://github.com/markhellewell/sshconfigfs
Sadly, this doesn't work always. Some apps which implement their own ssh don't support ~/.ssh/config. For example, the OSX Subversion GUI client Cornerstone doesn't support this.
You have been down voted, but the question is reasonable.
One reason is so that invocations of ssh outside of the context of user invocation of ssh at the command line will also have these customizations included. This is especially important for ssh, which has emerged as a main security interoperability tool for Unix systems.
For example, if you use rsync, the tunneling and host alias conventions you set up in .ssh/ will carry over transparently to the ssh tunnel used by rsync.
Another example would be invocations of ssh in scripts (sh/bash scripts, even) that will not or might not read your .zshrc.
Ya, I think the underlying issue is I do things very differently than people on HN.
The idea of creating dependencies on a configuration profile inside a bash script is the exact opposite of what I would do.
I also could not rsync things to my local machine [bandwidth constraints] and would be rsyncing between remote machines, which being a shared environment, I would rely on explicit invocations instead of creating configurations/aliases.
Thank you for telling me how/why other people make different choices. I always do seem to have the blinders of my process is the only process I consider when commenting on HN. :)
To add to what @mturmon said; you'll want to keep in mind that even GUI tools (i.e. consider your favorite database tool that supports SSH connection) that support SSH connection will pick up this configuration so you don't have to manually plug in all of the pieces for each session.
Just specify the alias host name as configured in ~/.ssh/config and the user, identify file, and anything else you put there will be used as set.
File format: as many of the following blocks as you like
You can now ssh to that server as that user by doing "ssh $ALIAS" on the command line, without needing to specify the port or user with the usual command line arguments, or necessarily spell out the entire host name.