[HN Gopher] The pitfalls of using SSH-agent, or how to use an ag...
___________________________________________________________________
The pitfalls of using SSH-agent, or how to use an agent safely
Author : koolba
Score : 121 points
Date : 2021-09-18 14:40 UTC (8 hours ago)
(HTM) web link (rabexc.org)
(TXT) w3m dump (rabexc.org)
| mtmulch5092 wrote:
| Covid Discrimination / Medical / Assistance anything helps.
| https://gofund.me/05183d43
| secabeen wrote:
| A timeout of 4 or 8 hours works well for me. Enough that it's
| useful, and part of my routine when I start my workday and return
| from lunch.
| bcl wrote:
| I would also add 'Always set a timeout with -t' both to protect
| the keys from misuse, and so you don't forget your passphrase
| when you rarely type it in.
| miohtama wrote:
| Are there yer any two-factor companion mobile apps that would
| increase SSH agent security locally (asks permission to use the
| agent key) or remotely (extra factor of authentication when
| login)?
| benlivengood wrote:
| https://www.stavros.io/posts/u2f-fido2-with-ssh/ goes over
| using FIDO2 devices with ssh, including storing the secret keys
| on the hardware. In that sense the passphrase becomes the
| second factor I guess.
| phonethrowaway wrote:
| I've seen PAM modules for otp/totp, but that really only adds
| security if authenticating against a remote machine, if you
| validate the second factor locally doesn't that still open you
| to mitm or other exploits? Can you trust your own environment?
| InvaderFizz wrote:
| For Mac users, there is this:
| https://github.com/TimidRobot/mac-ssh-confirm
|
| Doesn't add 2FA so much as it prompts you for each agent use.
|
| On the remote end, you can enable 2FA for logging into the
| server with libpam-google-authenticator.
| metafunctor wrote:
| There's also this to use a key in the Secure Enclave and
| Touch ID to confirm authentication:
| https://github.com/sekey/sekey
| johnklos wrote:
| First, the author writes as if shell servers with multiple people
| don't exist. Please see, for example, https://sdf.org/
|
| Second, if you're going to exclude every server on which anyone
| else has root, you're essentially excluding _all_ hosting (except
| colocation), since essentially that means all computers you don
| 't physically manage.
|
| There are many scenarios where a physically local computer is
| only trustworthy for the moment, and where this could change at
| any time. Windows computers, for instance, aren't trustworthy in
| the long term. Work computers may have nefarious software on
| them. Computers which are shared with multiple people (think of a
| family) may have users who aren't as careful.
|
| A shell on a trustworthy provider such as SDF may be safer as a
| place to store keys and from which to run ssh-agent, so this
| scenario shouldn't be discounted.
|
| Of course, this means nothing if your access to your shell on a
| trustworthy server is compromised, but wholesale discounting this
| is not helping people.
| pmoriarty wrote:
| _" Work computers may have nefarious software on them.
| Computers which are shared with multiple people (think of a
| family) may have users who aren't as careful."_
|
| Even a computer you manage yourself could have nefarious
| software on it, as most people don't usually manage their
| operating system and the operating system provider could serve
| up malicious software (intentionally or unintentionally),
| either originally or in an update. Same with the hardware of
| the machine, which could also compromise your keys or grant
| unauthorized people access.
|
| I would not feel safe merely because I physically managed my
| own machines and knew something about security.
|
| Really, a computer needs to be completely offline and with no
| ability to get online. Safest is not to use a computer at all.
| burnished wrote:
| The author makes it pretty plain they do everything from a
| laptop that is in their sole control. I don't think it is a
| reasonable critique that every article is pertinent to every
| kind of user.
| encryptluks2 wrote:
| Why not use your PGP key for SSH authentication? Seems like there
| should be a way to integrate with Git, so that rather than having
| to specify the SSH command or setting up a complicated global
| config you can just make sure that your right GPG key is added to
| the project?
|
| https://wiki.archlinux.org/title/GnuPG#Using_a_PGP_key_for_S...
| maddyboo wrote:
| I like to use GPG-agent's SSH agent emulation [1]. I start the
| agent with a systemd user service and have the keys expire after
| something like 10 minutes. A benefit is that it uses a GUI
| pinentry dialog to ask for your password if the requesting
| program doesn't have stdin from a terminal, e.g. if I try to git
| push from Fugitive inside vim. I find that GPG-agent is more
| intuitive and less finicky than SSH-agent.
|
| [1]: https://wiki.archlinux.org/title/GnuPG#SSH_agent
| throwdecro wrote:
| Is ssh-agent even worth the trouble?
| johnklos wrote:
| Yes.
| inetknght wrote:
| No. I have not found a single use case where an ssh-agent is
| worth the security problems it adds.
| dataflow wrote:
| How do you push/pull a private GitHub repo on a remote
| machine you're SSHed into?
| janci wrote:
| Deploy keys
| dataflow wrote:
| So you leave a copy of a key that can _push_ to your repo
| on the machine? How in the world is that supposed to be
| more secure than forwarding an agent that only
| authenticates you when you 're actually connected? At
| least you don't leave a copy of the key itself on another
| machine.
| janci wrote:
| Sorry, did not notice the push part. But it solves the
| pull part nicely.
| dataflow wrote:
| Even for pulling I fail to see why having the deploy key
| sitting on the machine is supposed to be more secure than
| having it in your agent.
| janci wrote:
| You have a key on a single machine that can only read a
| single repository with no additional hassle about
| securing the agent to not give out all your secrets at
| once, while it does not add any additional risk, as the
| remote machine already has full copy of the repo, so
| there is almost nothing to gain with the key if attacker
| had compromised the machine already.
| dataflow wrote:
| If someone lifts the key they get perpetual access to
| your entire repo without any further need to have access
| to your machine. If they lift the repo then they get a
| snapshot of the branch(es) you have have in it at that
| moment in time - they'll need continued access to the
| machine if they want continued access to the data. There
| can be a nontrivial difference here right?
| inetknght wrote:
| Being SSH'd into a machine doesn't matter.
|
| You can create a new key _on that machine_ and authorize
| _that key_ for the specific purpose you need.
|
| Or you can also just clone the repo on your local machine
| and add the remote machine as a git repo remote. Then you
| proxy all commits between github and the remote machine.
|
| If you don't want to proxy commits between three repos
| (github, your local, your remote) then you could install
| sshfs on your local machine and sshfs-mount your remote
| machine.
|
| Regardless; if you're running git on the remote machine
| then the root user of that remote machine would have
| access to the key. Why let them have access to _your_ key
| when they're only administering a machine for that
| repository? Let them have access to a shared key.
| 0x000000001 wrote:
| My Yubikey requires physical touch to authorize an SSH connection
| so it doesn't matter if I forward my agent to malicious servers
| as their attempts to hijack my socket will result in timeouts
| from my not authorizing their use with my physical key
| blibble wrote:
| unless they do it at the same time as you logging in to
| something else?
| 0x000000001 wrote:
| They'll only get one hop and I'll get a push notification
| immediately upon login to my server anyway
| danieldk wrote:
| If you have a Mac with Touch ID, you can also use secretive,
| which requires fingerprint authentication:
|
| https://github.com/maxgoedjen/secretive
|
| Extra nice with the new Apple Magic Keyboard with Touch ID.
| justincormack wrote:
| Yes, not using software keys is much the safest approach.
| They can't be stolen from your laptop oe remote forwarding.
| pmoriarty wrote:
| Biometrics have their own set of problems.
| 0xCMP wrote:
| Nice, I'd been looking for an alternative to sekey
| unfortunately.
| keithwinstein wrote:
| ObPlug for Guardian Agent, which is basically "safe" ssh-agent
| forwarding (and works with Mosh and SSH):
| https://github.com/StanfordSNR/guardian-agent
|
| The basic story is that ssh-agent really just exposes a primitive
| of "please sign this challenge," which is useful locally, but the
| protocol wasn't designed to be forwarded. If requests are coming
| from a semi-trusted intermediary host, the protocol doesn't tell
| the agent (a) "what remote server is being authenticated to
| [i.e., who generated the challenge?]", or (b) "what command is
| going to be executed?" It doesn't even really know (c) "what
| (semi-trusted) host forwarded the challenge and is asking to
| authenticate to the remote server?" (although this one you can
| approximate today by running lots of agents and giving each local
| ssh command a different agent to forward requests to).
|
| Guardian Agent is a sort of hack that allows the agent to know
| (a), (b), and (c) before deciding whether to grant or deny the
| request, so the user can set up policies like, "I'd like to allow
| `semi-trusted host x` to use <SSH identity i> to run "git pull
| from <repository name y>" when talking to `git server z`, but
| that's it." The basic ssh-agent protocol just doesn't have enough
| info to be able to do something like that.
| 3np wrote:
| > Too many keys, github, and friends
|
| This right here is what has been bugging me recently and the what
| is really selling me on the author's approach. Given that
| exposing a series of public keys to an SSH server acknowledges
| their connection, pervasive use of git hosting like
| Github/Gitlab, separating private and professional personas...
| How else do you keep maintain that consistently?
|
| It's only mentioned in passing in the end but really, it's an
| underappreciated issue I haven't seen better solutions to.
| sillystuff wrote:
| > 3. Only forward your agent connection to machines you trust.
|
| You can get the convenience of agent forwarding without the
| negatives by using openssh's ProxyJump (or, in old versions
| ProxyCommand). Either allows you to transparently forward your
| ssh connection via another host (or chain of hosts).
| jffry wrote:
| ProxyJump can also be pretty magic. If you have machines all on
| a subnet (in my example below, 10.1.0.0/24) that you need to
| use the same SSH jumpbox to reach, you can easily set up a
| wildcard to transparently proxy jump to any of them:
| Host jumpbox-10.1.0.x HostName jumpbox.example.com
| Port ... User ... Host 10.1.0.*
| ProxyJump jumpbox-10.1.0.x
|
| Then you can just run any random command like ssh 10.1.0.4 and
| it will just transparently jump through the jumpbox without you
| needing to specify it!
|
| (Of course, if you have a local subnet that collides and you
| are also trying to SSH to local hosts then this won't be the
| right approach for you).
| throwaway984393 wrote:
| There are a couple solutions to "too many keys".
|
| The simplest and best solution is don't use SSH. For Git remotes
| using HTTPS, use personal access tokens / API tokens. For each
| repository you check out, change the _git remote_ URL to include
| the username, like _git remote add
| originhttps://username@github.com/user/repo.git_. Then configure
| Git to use your system 's credential keychain and store your
| token there with the hostname and username. Or use a _.netrc_
| file. The correct access token will be selected based on the
| hostname and username.
|
| If you do use SSH, you can configure a Git repo to use some
| specific SSH arguments to specify the key file, like _git config
| core.sshCommand "ssh -i ~/.ssh/id_ed25519_clientX"_. Or you can
| configure your SSH client to have a custom _Host_ entry for a
| fake host that specifies the SSH key to use, and use that fake
| host for your Git ssh remote URL.
| maccolgan wrote:
| Using hostnames like a.github.com and b.github.com and in your
| ~/.ssh/config and adding Host entries with IdentityFiles
| pointing to the right private keys is the cleaner solution imo.
| bodyfour wrote:
| I've seen several systems that wrap the ssh binary to allow
| different agents to be forwarded to different hosts. Personally I
| think this is unwieldy -- it really should be something which is
| built into ssh directly.
|
| Running multiple agents is also a bit ugly, especially if you are
| trying to consolidate your keys with an agent integrated with
| your desktop environment, which I think is the most common use
| case.
|
| FWIW my proposal for fixing it is
| https://github.com/openssh/openssh-portable/pull/233 but it isn't
| the most elegant solution either I guess. It doesn't seem to have
| picked up much interest so I don't think it's likely to ever be
| merged (at least in its current form) which is fine. Hopefully
| _some_ tamed version of agent forwarding appears directly in
| openssh someday, either as a simple key filter or something more
| complicated like guardian-agent
| metafunctor wrote:
| No need to wrap the binary for that, just something like this
| in ~/.ssh/config: Host *.foobar.com
| IdentityAgent ~/.ssh-agent-for-foobar.ssh
|
| Of course, you still need to run a separate agent for each
| security domain you wish to keep separate.
| inetknght wrote:
| Better: IdentitiesOnly yes # Only use the
| identity specified by IdentityFile instead of any presented
| by an agent ForwardAgent no # Don't forward to a
| remote server. IdentityAgent none # Don't use an
| agent. AddKeysToAgent no # Don't add any unlocked
| keys to an agent. Host *.foobar.com
| IdentityFile ~/.ssh/path/to/private/key
| rfjakob wrote:
| From man ssh-add: -c Indicates that added
| identities should be subject to confirmation be-
| fore being used for authentication. Confirmation is performed by
| ssh-askpass(1). Successful confirmation is signaled by a zero
| exit status from ssh-askpass(1), rather than
| text entered into the re- quester.
|
| I'm a bit surprised that this is not mention in the article, as
| this seems very useful to make exploits more difficult.
| metafunctor wrote:
| Yep, or put this in your ~/.ssh/config
| AddKeysToAgent confirm
___________________________________________________________________
(page generated 2021-09-18 23:00 UTC)