hwechtla-tl: SSH features everyone should use


Mikä on WikiWiki?
koko wiki (etsi)
viime muutokset

(nettipäiväkirja 19.11.2015) SSH is a very versatile tool that basically every Unix/Linux user knows and uses. However, the default setup of SSH is relatively conservative and leaves many extremely useful SSH features disabled. Here's a list of stuff almost every SSH user should find useful.

Host aliases

If you're writing a given ssh command very often, it certainly pays off to make an alias. For example, if you write this:

$ ssh mylongusername@verylonghostname.domain.com

Then put the following into your .ssh/config:

Host very
  User mylongusername
  Hostname verylonghostname.domain.com

After that, you can just use "ssh very". The alias also works for all commands that use ssh underneath: you can say e.g.

$ ssh anotheruser@very  # override User
$ scp very:foo.txt .
$ rsync -az mydir/ very:mydir/
$ git clone ssh://very/repos/myproject

Key authentication

If you use SSH a lot or for automation, key authentication is a must. It allows you to skip password authentication in a secure way. If you set a passphrase for a key, it's strictly more secure than passwords; you can then use ssh-agent to only give the passphrase once per local session. Agent forwarding can also be used to use the same key for further ssh hops (when you ssh forwards from a host you are accessing by ssh).

Create a key by:

$ ssh-keygen

Put the key's public counterpart to hosts which you want to access without password:

$ ssh-copy-id user@host   # you can also use aforementioned host aliases

The agent stuff nowadays usually works without any configuration in Gnome and other desktop environments. If SSH keeps asking for the passphrase, you can give it just once by 'ssh-add' if the agent is already running. However, if you need to use it from a terminal, you need to write something like this:

$ ssh-agent bash   # or your favourite shell
$ ssh-add

Now you have a shell where the agent is running and your key is loaded.

Reliable interactive terminal sessions

mosh (https://mosh.mit.edu/) is a great program that offers reliable, uninterrupted shell access and better terminal emulation that raw ssh. Mosh session also live over suspend/resume or changing networks. You should always use mosh if you just want a shell session on a remote host.

Instead of 'ssh server', type:

$ mosh server   # you can use ssh aliases here, too.

mosh has some issues with IPv6 (https://github.com/mobile-shell/mosh/issues/81), try to ensure you have the newest version.

Running one-off commands

If you just need the output of one command via SSH, you can give that command on the SSH command line:

$ ssh host ls tmp/

It also combines well with pipes:

$ ssh host who | grep -i bob
$ echo foo | ssh host 'cat > test.txt'

Jump host related stuff

If you often ssh into some server just to ssh into another from there (e.g. because of firewalls), you have use for agent forwarding and SSH proxy commands. Agent forwarding allows you to use your authentication keys without installing them on the jump host (the intermediate server). Put this into the beginning of your .ssh/config:

Host *
  ForwardAgent yes

You can also set up the destination hosts so that you don't need to explicitly contact the jump host, by using an SSH proxy command. Put this into your .ssh/config:

Host desthost
  User desthostuser
  Hostname desthost.foo.bar
  ProxyCommand ssh -W %h:%p username@jumphost   # or use an alias

ProxyCommand is the more secure approach of these two, agent forwarding comes with its problems (see https://heipei.github.io/2015/02/26/SSH-Agent-Forwarding-considered-harmful/).

Controlling existing SSH sessions

If your ssh session is stuck, you can terminate it with: <newline>~. For international keyboards with dead keys, that's <Enter>, <AltGr+^>, <Space>, <dot>.

You can also add port forwardings as an afterthought with <newline>~C

Encrypting other applications

If you're connecting to a service in host X, port Y, and you can ssh to host X, you can encrypt the connection by first running:

$ ssh -L Y:localhost:Y X

and then connecting to localhost, port Y (instead of server X, port Y). Other, more complicated schemes exist, but this is the simplest one.

If you use a port forwarding rule often, just add it into that host's alias configuration:

Host X
  LocalForward Y localhost:Y

Circumventing firewalls securely

The tunnels above can be used to circumvent firewalls, because SSH is making the connection to your custom application from your remote host instead of your local machine. You can also use "ssh -L Y:appl.server.com:Y shell.server.com" if appl.server.com is accessible from shell.server.com but not your local workstation. (Note however that the connection between shell.server.com and appl.server.com will be unencrypted.)

However, if you have a client that supports SOCKS proxies, you can make everything work as if your client was running on the SSH remote host - this allows e.g. using a local browser as if it was in a company internal network, if you have an SSH connection to the internal network. Just run:

$ ssh -D 9853 ssh.server.com   # the port number can be whatever

Then configure e.g. your Firefox to use a SOCKS proxy at localhost, port 9853. Clients that don't support SOCKS can usually be made to by using tsocks (http://tsocks.sourceforge.net/about.php). And, of course, the SSH option can be put in .ssh/config:

Host server
  Hostname ssh.server.com
  DynamicForward 9853

Multiplexing many connections through one

Sometimes you make a lot of SSH connections to the same host simultaneously or in succession - for example if you use SSH for some kind of automation. You can multiplex all those connections through one connection. The "master" mechanism allows SSH to use another connection if there is already one to the same host,port,username combination.

Put this into .ssh/config:

Host *
 ControlPath ~/.ssh/master-%l-%r@%h:%p
 ControlMaster auto

Note that this works as such for simultaneous connections; to optimise recurring connections, first make one ssh session to the host; all connections after that will use that "master" session.


kommentoi (viimeksi muutettu 24.11.2015 21:56)