Always specify ssh port when using ghe-ssh

[lildude]

If a user doesn't specify a port, backup-utils makes assumptions based on the successful connection test at https://github.com/github/backup-utils/blob/master/bin/ghe-host-check#L27

The problem with this is if a user adds an entry to their ${HOME}/.ssh/config similar to:

Host ghe.example.com
    Port 122       # <----- This is the pertinent part
    User admin
    IdentityFile /Users/username/.ssh/id_rsa

... this test thinks the connection was made on port 22, when it was actually on port 122, and the restore fails as follows:

$ bin/ghe-restore ghe.example.com
Connect ghe.example.com:22 OK (v2.1.2)
Starting restore of ghe.example.com:22 from snapshot 20150201T144744
Restoring settings ...
Restoring license ...
Restoring Git repositories ...
ssh: connect to host ghe.example.com port 22: Connection refused
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at /SourceCache/rsync/rsync-45/rsync/io.c(453) [sender=2.6.9]

... forcing people to explicitly specify a port in their backup.config or in the hostname they pass as an argument.

This PR removes this assumption and forces the explicit setting of a port in all SSH commands thus catching this scenario.

As GitHub Enterprise only accepts connections on port 22 and 122 with no option of customising this, I think this is a safe thing to do. Even if someone does change this to some obscure port in the future, the processing of the port passed in via the argument or config continues to work.

[rtomayko]

👍 Looks great.

I wanted to verify we weren't going to accidentally pass -p without a value. The ssh_port_part function used by ghe-ssh always returns a port number so we should be good there:

https://github.com/github/backup-utils/blob/always-use-ssh-port/share/github-backup-utils/ghe-backup-config#L230-L235