SSH agent forwarding, eller vidarebefordran av SSH-agenten, innebär att man kan vidarebefordra SSH-agenten till ett fjärrsystem. På så sätt behöver man inte kopiera sin privata SSH-nyckel till fjärrsystemet, eller skapa flera nycklar för olika system. Men det finns risker med det.

Blåsfisk
Bild: Montage av bilder från OpenClipart-Vectors och Peggy och Marco Lachmann-Anke

Om man använder en SSH-agent på sin lokala dator för att hålla nyckeln upplåst för sin användare, går det att vidarebefordra den till ett fjärrsystem. Det är praktiskt om man exempelvis utvecklar kod på flera olika system och behöver pusha till GitHub eller Bitbucket. Detta tar bort behovet att ha flera nycklar på flera olika system.

Det enda som behövs för att aktivera vidarebefordran av agenten är flaggan -A när man ansluter till fjärrsystemet, samt att nyckeln finns i sin lokala agent.

jake@red-dwarf$> eval $(ssh-agent)
Agent pid 62196

jake@red-dwarf$> ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/jake/.ssh/id_rsa: 
Identity added: /home/jake/.ssh/id_rsa (jake@red-dwarf)

jake@red-dwarf$> ssh -A jake@192.168.0.43

jake@ubuntu$> git clone git@bitbucket.org:jackbenny/test-repo.git
Cloning into 'test-repo'...
Receiving objects: 100% (3/3), done.

Bakom kulisserna

Bakom kulisserna använder vidarebefordran en socket. Filen skapas i /tmp-katalogen, och en miljövariabel – SSH_AUTH_SOCK – pekar på den.

jake@ubuntu$> echo $SSH_AUTH_SOCK
/tmp/ssh-XXXXOmC7Wb/agent.181748

jake@ubuntu$> file /tmp/ssh-XXXXOmC7Wb/agent.181748
/tmp/ssh-XXXXOmC7Wb/agent.181748: socket

jake@ubuntu$> ss -x -e -a | grep agent.181748
u_str LISTEN 0  128  /tmp/ssh-XXXXOmC7Wb/agent.181748 467833   * 0  <-> ino:1059313  dev:0/64514 peers:

När du loggar ut eller avslutar den aktiva sessionen tas socket-filen bort från fjärrsystemet.

Problem med tmux

Ett problem med vidarebefordran av agenten är när man återupptar en tmux-session. När man återupptar en tmux-session med tmux at har sessionen kvar den gamla socket-filen i miljövariabeln – från när tmux först startades. Detta är dock enkelt åtgärdat med ett enda kommando.

Kom ihåg att kommandot ska köras efter att du har återupptagit din session med tmux at:

jake@ubuntu$> eval $(tmux show-env -s | grep '^SSH_AUTH_SOCK')

Kommandot listar miljövariablerna från tmux med show-env, greppar efter den rätta variabeln – SSH_AUTH_SOCK – och exekverar sedan variabeln i skalet med eval, som då exporterar den. Detta uppdaterar variabeln med den rätta socket-filen.

Säkerhetsrisker

Man bör vara försiktig med att vidarebefordra sin agent till okända system. En annan användare med root-rättigheter på fjärrsystemet kan använda din socket-fil i sitt egna skal. Då kan den användaren använda din identitet till att komma åt alla git-repon eller andra fjärrsystem dit din nyckel fungerar.

Här använder jag användaren Kalle från samma fjärrsystem som tidigare till att använda användaren Jakes identitet. Kalle har sudo-rättigheter på systemet.

kalle@ubuntu$> sudo -i
[sudo] password for kalle: 

root@ubuntu#> export SSH_AUTH_SOCK=/tmp/ssh-XXXXOmC7Wb/agent.181748

root@ubuntu#> git clone git@bitbucket.org:jackbenny/test-repo.git
Cloning into 'test-repo'...
Receiving objects: 100% (3/3), done.

Det finns således både för- och nackdelar med vidarebefordran av SSH-agenten. Å andra sidan finns det även risker med att kopiera sin nyckel till fjärrsystemet, eller att skapa flera nycklar för olika system.

I jämförelse med att kopiera sin egna privata nyckel till mängder av fjärrsystem är ändå vidarebefordran av SSH-agenten relativt säker. Socket-filen raderas från systemet vid utloggning. En nyckel kommer å andra sidan alltid finnas kvar tills du raderar den. Man bör dock vara medveten om att det finns en risk att en root-användare använder socket-filen.