I keep forgetting this, so I'd better jot it down here once and for all. To add a Git remote repository, accessible through SSH with a different port than 22, execute:

So this adds a remote repository behind port 2222 of the host, immediately followed by the remote path of the repository. The ssh:// part is crucial and forgetting this part has cost already some minutes of my life.

In Nagios, I wanted to let one particular host (out of many) to be checked with a different SSH port. In the checkcommands.cfg file, you will find commands which need to be checked remotely written as follows:

This does not allow you to let a host use another SSH port. There are many other hosts which just work fine like this (since all hosts have the default port 22 set), it's just one particular host using SSH port 24. I could also redefine all remote commands by adding a -p 24 but this is inflexible. I would need a new set of commands for each different port number.

I had to transfer a big file to some remote site, and have it split up there. So something like:

However, the split(1) utility does not have a command line option to specify an output directory. It only puts files in the current working directory, which is undesired in this case. But /bin/sh to the rescue, it is possible:

For some script a passwordless SSH login was required. However, despite the public key had no passphrase set, a password was being asked nevertheless.

The SSH client is not really verbose on what was going on, but it turned out to be the private key's permissions. When the permissions are too open, SSH refuses to use that key and falls back to something else. So make sure that they key has mode 600 (read and write only for the owner of the key) and that the owner is OK.

Doing a git clone/pull/push command might result in the following error message:

I was wondering how to connect to a SSH server running on a guest computer with QEmu. There wasn't really an obvious way to do that, until I looked at the help text a bit closer:

So starting QEmu with the following parameters did the trick:

Now connecting is a piece of cake:

SSH can be funny to set up, it's easy to do something wrong. Some time ago I had to help a customer with setting up a SSH connection to our webserver, which only allows public key authorization.

Error message:

We retried about everything. The problem was not server side, the keys were generated according to our instructions (as far as we could check), the permissions to the keys were OK, no incompatibilities with the Mac version of openssh and our FreeBSD server. Everything was OK, except...