976Git, Mac, SSH Keys and the OSX Keychain

When using git with a key that has a passphrase, you are asked the passphrase every time you pull/push. To make this a bit more convenient, add the key to the OSX Keychain.

Store key in OSX Keychain:

ssh-add -K ~/.ssh/my_key

Open .ssh/config

Host *
  UseKeychain yes
  AddKeysToAgent yes
  IdentityFile ~/.ssh/my_key

950SSH, Keys and Cyberduck

Environment: OSX 10.15.2

Understanding ~/.ssh/config

Host test.trembl.org              # Hostname
  User trembl                     # Username
  IdentityFile ~/.ssh/trembl_rsa  # Path to Key

Before config entry:

ssh -i ~/.ssh/trembl_rsa trembl@test.trembl.org

After config entry:

ssh trembl@test.trembl.org

.ssh/config looks up the corresponding IdentityFile and applies the matching IdentityFile for user & host

Keychain Access, SSH & Cyberduck

Adding key to the ssh agent:

ssh-add -K ~/.ssh/trembl_rsa

Check, if the key is present?

ssh-add -l 

Response:

2048 SHA256:abcdefghijk trembl@Fischer.local (RSA)

This does not add the key to the Keychain Access App. Does it survive a restart, or will it only be in RAM?

Answer?

Login in via Cyberduck adds Passphrase to the Keychain Access App. Is this persistent?

941Local SSH Key via ssh-add

  • Add SSH to the Git Service
  • Run ssh-add locally
  • Connect via ssh to your server
ssh-add
ssh user@host

git status
git ...

Check status of ssh-add

ssh-add -l

Delete all keys from current process

ssh-add -D

924Connecting via SSH and Key

ssh -i ~/.ssh/path_to_key username@server

859Using a non-standard key for ssh

How to log-in with ssh, using a non-standard key:
ssh -i ~/.ssh/my_other_key username@host.server.org

829Digging a tunnel to a remote SFTP Server, Part 2

Back in Part 1, I was using a tunnel and a SOCKS proxy to connect to a remote server. While this might work in certain conditions, other circumstances might call for other solutions.

Take this case.

Recently our Sysadmins changed to login procedure to our servers. Instead of just logging on like this...

localmachine:~ me$ ssh username@host

...we are now forced to jump through another hoop:

localmachine:~ me$ ssh username@host
username@host's password: •••••••
Last login: Tue Aug 14 10:39:17 2012
[username@host]$

[username@host]$ ssh username@anotherHost

I have to guess, that for reason's of security, it's not possible to log-in directly to anotherHost from my local machine: Any connection has to go through the host machine.

While some like to edit their text files with the very powerful, but slight archaic vi or Emacs, some others prefer more a more civilised approach and use tools like TextMate.

But if the text files are on a remote server, which needs to be logged-in from another server, how can I use TextMate to edit files there?

Enter the Tunnel

Cyberduck, the ever-popular SFTP application, can lend us a hand in editing the text files. A simple cmd-J, and the text file on the server opens in TextMate, cmd-S saves the modified file back to the server.

But how exactly do we open the tunnel? How do we start the port-forwarding?

ssh usename@host -L 1024:anotherHost:22

Let's dissect this command:

ssh usename@host open a connection to the host with our username. Of course you'll be prompted for your password.

-L 1024:anotherHost:22 is where the magic happens. It specifies the local port on your machine (in this case: 1024) to which the remote port (22) of anotherHost is mapped. And all this happens by way of the host machine.

Other switches which could be helpful for this command are: -f send ssh to the background -N stops the execution for remote command.

Check the ssh man pages for more details.

If you prefer a GUI for opening the tunnel, have a look at Fugu.

It does basically the same, only with a graphical user interface. If that removes or adds confusion is for you to decide.

If we look at the ssh command that Fugu is generated, we see that we were basically doing the same before:

/usr/bin/ssh -N -L1024:anotherHost:22 username@host -oPort=22 -v

707Digging a tunnel to a remote SFTP Server

The problem seems to be familiar. The host (let’s call it target machine) you want to connect to is in a corporate network, you are not able to directly connect to it. However you have SSH access to another computer (the intermediary machine) on the same network, which means your are able to SSH your way into the intermediary machine and from there to the target machine. So far so good. Whereas the command line has its merits, for some jobs it’s more convenient to use an FTP client (like Cyberduck). Cyberduck does not support SSH tunneling by itself, but there are way to make it work. First, we will create an SSH tunnel to the intermediary machine and second we will set this tunnel up as a proxy through which Cyberduck will be able to connect to the target machine. 1. The SSH Tunnel
ssh -qTnN -D 4040 -C username@intermediary
Key in the password for your intermediary server, and its connection should be available for your localhost:4040. 2. The SOCKS Proxy And localhost:4040 is were we are pointing our SOCKS proxy to: 2. Back to Cyberduck Now, with the tunnel active and the proxy configured, just enter the login credentials of the target machine in your FTP application – and voila – it should work. At least it worked for me.