SSH_README.md

.ssh

Security Consideration

About SSH Agent Forwarding :

SSH Agent forwarding exposes your authentication to the server you're connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).

Design

I use distinct keys depending on usage

LEGACY vs MODERN

Two types of endpoints :

• legacy servers : OpenSSH < 6.4
• modern servers : OpenSSH >= 6.4

For legacy I use (default) 3072 bits RSA key which is the default minimum for usage above 2030. Previous default was 2048 bits and max usage shouldn't exceed 2030. See details (in french) in RGS B1 document, from French National Cybersecurity Agency (ANSSI)

ssh-keygen -f sshkey_legacy -P '' -t rsa -C "m@tthieu.fr"

For modern I use (fixed) 256 bits Ed25519 key. See details

ssh-keygen -f sshkey_modern -P '' -t ed25519 -C "m@tthieu.fr"

SSH vs GIT

My SSH keys are never loaded in ssh-agent. Ever.

My GIT keys are always loaded in ssh-agent. But only forwarded when a git authentication has to be performed from one of my remote ssh server.

# On 'local' : 
# - my ssh key identity used to authenticate to 'server' is not forwarded !!! (IdentityFile ~/.ssh/sshkey_server + ForwardAgent no)
# - only my git keys are loaded and forwarded so I can use git on the remote server without actually deploying my private key (ssh-add ~/.ssh/gitkey_bitbucket + ForwardAgent yes)

local$ ssh server

# On 'server' my git keys have correctly been forwarded

server$ ssh-add -l
256 SHA256:JCOF8ExTZ3bSt+9hcfFQBNVKvniLnPgFJIKwx3NmxH8 github.m@tthieu.fr (ED25519)
256 SHA256:AWQBxp8cvpjze1aXDz4Bce5Gvpk8bdtqmkVr/BvOM6o gitlab.m@tthieu.fr (ED25519)
256 SHA256:UvC5AzdQ+kbpdbEGkfzOvcWDbeSywQT+M7LRA2vLNMg bitbucket.m@tthieu.fr (ED25519)

# ...so I can use git authentication

server$ git clone git@remote_git:path/to/project

Limitations

Considering the following

[LOCAL] -> [JUMP] -> [REMOTE]

You can change the User on intermediate(s) and final nodes :

Host JUMP
  User John

Host REMOTE
  User jdoe
  ProxyCommand ssh JUMP -W %h:%p
  
Host *
  IdentityFile sshkey_any

But you cannot change the IdentityFile value as it will refer to a private key on the actual JUMP host, not on your LOCAL

This would require to deploy private keys to JUMP host : non-sense !

Host JUMP
  User John
  IdentityFile sshkey_jump               # <-- searched on LOCAL

Host REMOTE
  ProxyCommand ssh JUMP -W %h:%p
  IdentityFile sshkey_remote             # <-- searched on JUMP

So if I cannot have the same public key deployed on each node (JUMP and REMOTE) then, and only then, I will consider loading a ssh private key to ssh-agent.

But that's a very specific use case which I believe won't concern lot of people.

I had to do it once in 20 years.

Notice

For what I am used to do, I personnally consider identity impersonation of my SSH keys more dangerous than my GIT keys.

But this shouldn't be the case for everyone. If you're a software developer you may consider the other way around (or both) because software supply chain security should be now one of your the major concerns (see https://slsa.dev for guidance)

Please adapt to your flavor (you may not want to load all your git keys, or add ssh-agent confirmation '-c' for identity usage...)