[HN Gopher] SSH Agent Restriction (new in OpenSSH 8.9)
___________________________________________________________________
SSH Agent Restriction (new in OpenSSH 8.9)
Author : frutiger
Score : 164 points
Date : 2022-01-09 18:18 UTC (4 hours ago)
(HTM) web link (www.openssh.com)
(TXT) w3m dump (www.openssh.com)
| 3np wrote:
| > Last modified: 2021-01-07
|
| Seeing as OpenSSH 8.8 was released in 2021-09, I assume the year
| is a typo.
|
| That aside, this is a great feature that I haven't seen mentioned
| before. Up until now, retaining any form of clear separation of
| personas while working across teams and platforms with SSH keys
| has been a fools errand. This seems to make it sane!
| soheil wrote:
| Once the ssh agent has access to a forwarded key from the client
| isn't it just a matter of reverse engineering the agent to
| extract that key regardless of what restrictions the client has
| specified?
| 131hn wrote:
| Forwarding the agent does not forward the keys, only a socket
| to the original server (agent)
| soheil wrote:
| Can't the server still pretend to be connecting to one of the
| specified hops? For example if _-h 'allowed.com'_ is
| specified then in _/ etc/hosts/_ wouldn't an entry to
| _127.0.0.1 allowed.com_ allow the local server to receive the
| key?
| misnome wrote:
| It looks like the dns name is just a convenience; it
| actually looks up the associated host key and uses that,
| not the hostname. So the attacker would have the private
| keys for the destination to make use of it; I think?
| akerl_ wrote:
| There's no such thing as "receiving the key". At best, you
| can coerce the forwarded agent to sign things w/ a key that
| it has. It will never give you the key itself; that isn't
| part of the agent's available behaviors.
| tialaramex wrote:
| Yup. And because SSH is a well-designed protocol, the
| signature needed to prove your identity is fresh (both
| sides pick large random values) each time, so even though
| SSH agent was over-used and securing it better is
| important, even today you cannot obtain enduring
| credentials from it. If I cut off your access to my SSH
| agent today, you can't authenticate to my servers
| tomorrow using what you learned.
|
| This also has the benefit that the SSH agent can offer
| this capability on behalf of physical hardware that won't
| give up the keys either. My Yubico Security Key won't
| tell anybody (even me) my SSH private keys, but since SSH
| agent only offers to make signatures, it can proxy that
| work to the Security Key as necessary.
|
| The Yubico product won't sign anything without a physical
| gesture (touching a glowing icon on the key) and so now
| if my laptop is sat unused on my desk while I eat lunch
| it's _impossible_ for a remote system to use my
| credentials to sign in to another system, even if it 's
| hostile, and it has somehow taken over control of my
| local machine's SSH client or I've unwisely authorised
| SSH agent forwarding, because it cannot cause the touch
| sensor to get touched.
| fpoling wrote:
| I just use separated ssh-agent with separated keys when I may
| need to forward the agent.
|
| For example, to deploy things to a production host from a build
| host I login to the build host using the agent with the
| production key and push things from there.
|
| With that, the jump host support and the ability to login with
| one agent but to forward another I just see no point for what ssh
| is doing. As they wrote, they want to keep things simple. But
| this complicates things.
| perlgeek wrote:
| Adding the permissions to the `ssh-add` call is probably easiest
| for the authors of ssh-add, but seems to me the wrong user
| interface for me.
|
| Putting such information in a config file (or maybe attaching
| them to the key somehow, by default $PATH_TO_KEY.permissions or
| so?) would seem better to me than either requiring the user to
| write wrapper shell aliases or fetching the previous ssh-add
| command out of the shell's history.
| runlevel1 wrote:
| My need for agent forwarding has almost completely vanished since
| `ProxyJump` was added a few years ago. Host
| *.example.com User runlevel1 IdentityFile
| ~/.ssh/id_rsa-foo ProxyJump foo@jump.example.com
|
| So when I SSH to _qux.example.com_ , it first SSHs to
| _foo@jump.example.com_ then through it to
| _runlevel1@qux.example.com_ and my agent is used on each
| individually.
|
| So there's no ssh-agent socket on the intermediate jump box.
|
| EDIT: More examples here:
| https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_J...
|
| EDIT2: For folks stuck on older SSH clients, you can do this with
| `ProxyCommand ssh -W ...` instead (also shown in the previous
| link) which is actually what ProxyJump is doing under-the-hood
| anyhow. https://github.com/openssh/openssh-
| portable/blob/d9dbb5d/ssh...
| PeterWhittaker wrote:
| Agreed. What worries me is this statement: "While it is
| generally better for users to avoid the use of a forwarded
| agent altogether (e.g. using the ProxyJump directive), the
| agent protocol itself has offered little defence against this
| sort of attack."
|
| Which I cynically read as "Hey, there is a better way, but
| we're going to try to make the worse way slightly more secure,
| here's how!"
|
| Some of the described behaviours strike me as opening up
| entirely new and hard-to-detect attack vectors.
| ed25519FUUU wrote:
| There's completely valid use-cases for which ProxyJump makes
| no sense. For example forwarding your SSH agent to a remote
| dev box so that you can push and pull from git.
| jeltz wrote:
| ProxyJump also does not support pam_ssh_agent_auth which
| can be used for e.g. implementing sudo auth with ssh keys.
| ProxyJump only solves a small subset of what agent
| forwarding can be used for.
| marcosdumay wrote:
| That's exactly what it says. Like X11 forwarding, there are
| cases where agent forwarding is secure and cases where it's
| not, and unless the alternatives completely eliminate the
| need for this feature, improving it is always good.
| ed25519FUUU wrote:
| One really obvious use-case for this which cannot be solved
| with proxyjump is pushing and pulling via git on a remote dev
| box.
| [deleted]
| rsync wrote:
| Related:
|
| My favorite simple VPN, sshuttle[1], can use ProxyJump to
| traverse a "chain" of hosts:
|
| https://github.com/sshuttle/sshuttle/issues/340#issuecomment...
|
| [1] https://github.com/sshuttle/sshuttle
| [deleted]
| nimish wrote:
| ProxyJump absolutely rules. Much, much simpler than dealing
| with agent forwarding which is janky even at the best of times.
| ed25519FUUU wrote:
| Why is it jenky? It just makes it so your ssh-agent is
| available on a remote host. It does exactly what it's
| supposed to do.
| tarkin2 wrote:
| What's the usecase?
| runlevel1 wrote:
| Jumping through a bastion host.
| egberts1 wrote:
| I'd be most curious about the reverse path part of this new SSH
| sub-channel protocol.
|
| Any new sub channel should get a major SSH version bump.
| GauntletWizard wrote:
| When I was at Google, there was a modified version of ssh-agent,
| that would simply ask before signing any login request. It popped
| up a window (x11 or curses, I think regulated by an external
| program) that asked "Do you want to connect to HOST?"
|
| It seemed such an obvious feature that I was surprised it wasn't
| part of the standard distribution.
| endre wrote:
| ssh agent protocol does not carry host information
| jeltz wrote:
| Yeah, part of this new feature seems to be to add host
| information to the agent protocol.
| axiolite wrote:
| This article mentions that option and explains why it isn't
| sufficient.
| krono wrote:
| Blacklisting all connections by default on my own devices and
| networks.
|
| Native tooling setup guides are easy to find, and software such
| as PiHole, AdGuard, and Little Snitch (Leaky Snitch btw) make
| it very manageable... once you get past the first two weeks of
| manual connection whitelist popups and log crawling hell, that
| is :)
| metafunctor wrote:
| No need for a modified agent, just put this in your
| ~/.ssh/config: AddKeysToAgent confirm
|
| You may need to separately install ssh-askpass.
| lima wrote:
| This does not do what parent describes.
| metafunctor wrote:
| It tells the agent to confirm each use of a key using ssh-
| askpass. The same can be achieved with the -c option for
| ssh-add.
|
| If the confirmation dialog really also showed a host name
| then yeah, this is not strictly the same. But it's pretty
| close.
| azalemeth wrote:
| Just in case anyone is wondering about their interesting choice
| of hostnames, they are very Greek in origin - somewhat
| appropriate for Geeks.
|
| > Scylla and Charybdis were mythical sea monsters noted by Homer.
| [...]Scylla was rationalized as a rock shoal (described as a six-
| headed sea monster) on the Calabrian side of the strait and
| Charybdis was a whirlpool off the coast of Sicily. They were
| regarded as maritime hazards located close enough to each other
| that they posed an inescapable threat to passing sailors;
| avoiding Charybdis meant passing too close to Scylla and vice
| versa. According to Homer's account, Odysseus was advised to pass
| by Scylla and lose only a few sailors, rather than risk the loss
| of his entire ship in the whirlpool. [0]
|
| This is _distinct_ from the Hydra, which was a _land based_
| multi-headed beast, and guarded an entry to the underworld. [1]
|
| So, OpenSSH thinks that you have to brave the seas to fight your
| demons on land.
|
| Seems apt, I think.
|
| (As an aside -- ``To be swept from Scylla to Charybdis'' is a
| (predominantly somewhat upper-class) British expression beloved
| by lawyers [e.g. [2]] meaning "caught between a rock and a hard
| place", and sometimes found in the formal judgements of some of
| the highest courts in the world, e.g. the ECJ ruling about
| whether or maintenance failures for airlines count as
| 'extraordinary' -- and therefore outside of the scope of the
| compensation legislation -- or not. It was found that they are
| 'part and parcel of an airline's operation'. I found this out as
| a teenager, when suing EasyJet for compensation I was owed. I
| won.)
|
| [0] https://en.wikipedia.org/wiki/Between_Scylla_and_Charybdis
|
| [1] https://en.wikipedia.org/wiki/Lernaean_Hydra
|
| [2] https://europeanlawblog.eu/2013/12/09/the-recent-landmark-
| ca...
| staticassertion wrote:
| Another thing that would be extremely helpful is improved
| logging. If the ssh-agent logged the entity that was attempting
| to hijack the connection it would be pretty easy to write
| detection logic for weird shit.
|
| We'll probably publish about this in the next few months, my
| colleague added some logging and we wrote ~10 detections on the
| process tree + IPC signatures. It makes the entire attack
| extremely dangerous for an attacker.
| laurent92 wrote:
| Port 22 shouldn't be accessible from the internet, in addition.
| Some people say it shouldn't be port 22, but we dip into
| security by obscurity, while making it annoying for you to use.
| staticassertion wrote:
| That doesn't really have to do with the ssh-agent or key
| forwarding though.
| [deleted]
| brightball wrote:
| Thank goodness. I'd been trying to figure out a good solution to
| this for a while.
|
| Horrified me when I realized all my keys were exposed on any
| server I hopped into.
| tailspin2019 wrote:
| > Horrified me when I realized all my keys were exposed on any
| server I hopped into.
|
| For someone only half paying attention, would you mind
| expanding on what you mean by this?
| Andys wrote:
| But.. public keys are public? Its not sending your private keys
| to anyone.
| based2 wrote:
| Does SSHv3 implementation exists as an Open Source Server/Client
| version?
| tw04 wrote:
| There isn't even a draft specification for SSHv3 so anyone
| claiming to have a server/client implementation (closed source
| or otherwise) is playing fast and loose with the term to try to
| sell something.
|
| https://datatracker.ietf.org/wg/secsh/about/
| based2 wrote:
| https://media.defense.gov/2020/Aug/18/2002479461/-1/-1/0/HAR.
| ..
| frutiger wrote:
| There is indeed no such thing as SSH3.
|
| I'm somewhat certain that document is supposed to say
| "SSLv3 or TLS". It's a minor typo but it brings into
| question the validity of the rest of the document.
| tialaramex wrote:
| SSLv3 seems unlikely in 2020 document about security. TLS
| 1.0 and TLS 1.1 are already known to be a bad idea by
| then, and SSLv3 was formally deprecated in 2015.
|
| Whereas a typo of SSHv2 makes sense because you probably
| _do_ want SSHv2 on products which have it, even if they
| also speak TLS 1.2 or better, since the functionality is
| orthogonal.
| jhgb wrote:
| But the "Use SSH or TLS" interpretation seems to make as
| much sense as saying "use a square or a yellow" regarding
| shapes. SSH is not (easily, anyway) a substitute for TLS
| where TLS is applicable.
| stonogo wrote:
| They both provide line encryption to underlying
| applications. In the early days of ssh the main
| competitor was rsh over an ssl tunnel.
| tialaramex wrote:
| This document isn't suggesting which services to _use_ it
| 's telling you what should be enabled, it's titled
| "Hardening Network Devices" and says "Research should be
| done to determine what services are running by default.
| The following guidance will serve to determine the
| services that should be enabled or disabled"
|
| Among the services they recommend disabling are: Daytime,
| BootP, and telnet.
| tialaramex wrote:
| Human types "3" when they meant "2" versus shadowy US
| government agency has invented a completely new
| cryptographic protocol that everybody needs to use yet
| somehow escaped mention anywhere except this one
| document... Who knows right?
|
| It is amusing reading the confused warblings of people
| who've been handed a mandate for something that doesn't
| exist. "How do I enable SSHv3 on this Cisco router?". We
| don't have many pranks in our industry, perhaps enabling
| SSHv3 can be our left-handed screwdriver or gallon of prop
| wash.
| shmerl wrote:
| I noticed that ssh agent isn't working out of the box in the
| Wayland session in KDE (unlike in X11 session). Is that intended?
___________________________________________________________________
(page generated 2022-01-09 23:00 UTC)