This warning is pretty self- explanatory:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/georg/.ssh/my_rsa_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Solution

Limit the key to read/write access by the user only:

chmod 600 ~/.ssh/my_rsa_key

It's also possible to make it only readable by the user, but then you need to chmod every time you want to update/change it.

chmod 400 ~/.ssh/my_rsa_key

Sources: StackOverflow

Step before: Trying to connect to a server with a SSH key. System: OSX, Big Sur

Connecting to a Server via SSH fails:

georg@Fischer ~ % ssh trembl@myserver -v           
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/georg/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to myserver.com port 22.
ssh: connect to host myserver.com port 22: Operation timed out

Did not work for ca. 1 hour. Same connection problem to different account with same provider, other account with same provider worked.

(Possible) Solution: Intentionally mis-spelled username, -v not stopping and timing out, log-in now possible.

Update 1

Use

nmap -Pn -p22 myserver

to check if the port is open or filtered.

Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-03-30 14:15 JST
Nmap scan report for trembl@myserver (xx.xx.xxx.xxx)
Host is up (0.21s latency).
rDNS record for xx.xx.xxx.xxx: xx.xx.xxx.xxx

PORT   STATE     SERVICE
22/tcp filtered  ssh

It should say:

PORT   STATE SERVICE
22/tcp open  ssh

Update 2

Creating a ssh connection to the server from another computer (on the same network) worked. Somehow, after that check, the connection on this computer also worked. Very mysterious.

Update 3

Approach 2 did not work the next time. Switching to a different network (phone hotspot) worked. Maybe restarting the router?

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

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?

• 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

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

How to log-in with ssh, using a non-standard key:

ssh -i ~/.ssh/my_other_key username@host.server.org

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

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.