6 ms·
One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connectio
by rvnx 3y ago
One safety tip: disable SSH Agent Forwarding before you connect, otherwise the remote server can theoretically reuse your private key to establish new connections to GitHub.com or prod servers (though this host is unlikely malicious).
https://www.clockwork.com/insights/ssh-agent-hijacking/ https://www.clockwork.com/insights/ssh-agent-hijacking/ (SSH Agent Hijacking)
- vrighter 3y agoi usually just disable ssh agent forwarding globally by default, and only enable it selectively via my ~/.ssh/config
- jolmg 3y agoDefault is disabled.
- hnarn 3y agoExactly, this tip only applies if you reconfigured ssh to automatically forward agent to all hosts, which is absolutely insane.
- bananskalhalk 3y ago*disable ssh agent FORWARDING. Which honestly should always be disabled. There are no trusted hosts.
- tichiian 3y agoThat's baby+bathwater. Just use ssh-add -c to have the ssh-agent confirm every use of a key.
- bananskalhalk 3y agoTIL. Thanks! Gonna do wonders when working at places where I can't use a hardware key with physical confirmation of use. My assessment still stands. Use proxyjump (-J) instead of proxy command whenever possible.
- tichiian 3y agoWhat can also help is specifying the right options right in ~/.ssh/config for certain hosts and domains: E.g. do "ForwardAgent no" globally, use a "Match *.my-trustworthy-company-domain.com" block and add "ForwardAgent yes" there. Also very good for other options that are useful but problematic when used with untrustworthy target hosts, like ForwardX11, GSSAPIAuthentication, weaker *Algorithms (e.g. for those old Cisco boxes with no updates and similar crap). Another neat trick is just using a ""Match *.my-trustworthy-company-domain.com" block" with an "IdentityFile ~/.ssh/secret-company-internal-key" directive. That key will then be used for those company-internal things, but not for any others, if you don't add it to the agent.
- yjftsjthsd-h 3y agoWhenever possible, yes, but AIUI it's not always possible; the one use case for which I believe full-on forwarding is required is using your personal credentials to transfer data between two remote servers (ex. rsync directly between servers). If there's a way to do that I would actually much appreciate somebody telling me, but I have looked and not found a way.
- deeblering4 3y ago[flagged]
- tichiian 3y agoSorry, English is not my native language. I know I sometimes sound strange because most of my use of the language is around the internet and at work, not that much casual "normal" conversation.
- bee_rider 3y agoEnglish is my native language and I have no idea what that person was talking about. Your post is fine.
- hunter2_ 3y agoI think that person was talking about having had 4 out of 5 squares in a line on their bingo card already, and stumbling across "baby+bathwater" earned them bingo. The card is metaphorical though... more of a mental buffer that just overflowed.
- bee_rider 3y agoThat makes more sense than my solution. As far as I’m concerned the baby and the bath water is just a normal expression. I thought it was something about the use of “confirm,” haha.
- hoistbypetard 3y agoMine too, and I think the post is fine also, but I have some idea of what that person was talking about. For a while, in some corporate environments, it was a recurring phenomenon to hear someone dismiss an urge to be cautious by saying "You're throwing out the baby with the bathwater." So I can see where someone might count it toward buzzword bingo. But this post also offered an alternate solution when saying "baby+bathwater", so the bingo caller should refuse to score this one.
- 3y ago
- lrvick 3y agoOr use a hardware backed ssh key you have to tap once for every use, like a Yubikey or Nitrokey.
- derefr 3y ago> There are no trusted hosts. ...your own (headless) server that's in the same room as you, when you're using your laptop as a thin-client for it?
- xandrius 3y agoWith all these recent exploits, I wouldn't even be 100% sure of that.
- wolletd 3y agoBut if I can't trust even that host, I also can't trust the host I'm working on and which doesn't need agent forwarding to access my SSH agent.
- hot_gril 3y agoTrusting one host is safer than trusting two hosts.
- jethro_tell 3y agoThis is where certs are nice, sign one every morning with a 8/12 hour TTL
- quibuss 3y agoInteresting idea. Does need some automation though to make it practical irl.
- dotancohen 3y agoDepending on what it's serving, and how up to date it is, and who else is on that network and can access the server, and who else can come into that same room when you're not there, and from where you get the software that you install on that server... it might be less trustworthy than you think.
- 3y ago
- sva_ 3y agoI've found myself to be much more comfortable to just define all my private keys in ~/.ssh/config on a host-by-host basis.
- jmole 3y agoAFAIK, this doesn't solve the SSH agent problem - the problem is the agent has access to all of those keys regardless of the host you connect to. So forwarding your SSH agent means an administrator of the system you're connected to could use any of those host keys loaded in the agent to connect to their associated machine.
- deleted 3y ago[deleted]
- contingencies 3y agoDefault for the last 24 years according to https://github.com/openssh/openssh-portable/blame/385ecb31e147dfea59c1c488a1d2011d3867e60e/ssh_config#L21 https://github.com/openssh/openssh-portable/blame/385ecb31e1...
- fragmede 3y agoThe full command you want is: ssh -a -i /dev/null terminal.shop to disable agent forwarding, as well as to not share your ssh public key with them, but that's just a little less slick than saying just: ssh terminal.shop to connect.
- glennpratt 3y agoI'm curious why you added `-i /dev/null`. IIUC, this doesn't remove ssh-agent keys. If you want to make sure no keys are offered, you'd want: ssh -a -o IdentitiesOnly=yes terminal. Shop I'm not sure if the `-i` actually prevents anything, I believe things other than /dev/null will still be tried in sequence.
- ProfessorZoom 3y agoinstructions not clear, my entire drive is empty now
- fragmede 3y agoCheck for yourself with ssh -v -i /dev/null terminal.shop vs ssh -v terminal.shop What you're looking for is that there is no line that says something like debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Upon further testing, the full command you want is: ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop to forcibly disable a local identity agent from offering up its identities as well, and not just agent forwarding. Upon further testing, ssh -o IdentitiesOnly=yes terminal.shop still offers up my public key on my system (macOS, OpenSSH_9.6p1, LibreSSL 3.3.6), contrary to what StackOverflow and the Internet seems to think. Tested by hitting whoami.filippo.io, linked in child comment.
- Jenda_ 3y agoFor a cool example (deanonymization), see https://words.filippo.io/dispatches/whoami-updated/ https://words.filippo.io/dispatches/whoami-updated/ (discussed at time: https://news.ycombinator.com/item?id=34301768 https://news.ycombinator.com/item?id=34301768). Someone has crawled public keys from GitHub (tbh I was surprised that GitHub publishes them) and set up a database.
- chuckadams 3y agoI take it you mean disable ssh agent forwarding — the agent itself is fine. You should never forward your ssh agent to a box you don’t trust as much as your own.
- rvnx 3y agoMessage edited, thank you, you are absolutely right.
- LeoPanthera 3y ago"ForwardAgent no" in ~/.ssh/config will do this automatically.
- zaik 3y agoNot having "ForwardAgent yes" in ~/.ssh/config will do this automatically too.
- hombre_fatal 3y agoSeems like a ridiculous amount of hoopla over something that isn't even a default.
- orblivion 3y agoIs it "yes" by default? If so, that seems insane given what the op said about it. But other comments say it's "no" by default. If it's "no" by default, why are people alarming us by bringing this up? And why for terminal.shop in particular?
- hot_gril 3y agoMaybe there was some blanket advice in the past to enable it? Idk, this got me alarmed for nothing.
- zzo38computer 3y agoThe man page for ssh_config(5) says that it is set to "no" by default, at least on my computer.
- trallnag 3y agoIt's off by default. No idea what this fuzz is about. Gathering internet attention points maybe?
- teruakohatu 3y agoIs "Host * \n AddKeysToAgent yes" acceptable from a security POV or should that also be per host?
- nomel 3y agoIs it not standard practice to make different keys for different important services? I have a private key for my prod server, a private key for GitHub, and a private junk key for authenticating to misc stuff. I can discard any without affecting anything else that's important. If I authenticated with my junk key, would my other keys still be at risk?
- ShamelessC 3y agoIt’s a practice, but not necessarily a standard one. In any case if even one person sees that, the advice will have served its purpose.
- brandensilva 3y agoTIL, the good news I guess is I only ssh into my hosting platforms and GitHub who have a reason to protect my data since I pay them. Still I'll be sure to break up my keys more going forward and disable SSH forwarding.
- semi 3y agodisabling agent forwarding is the important bit. But if you do want to break up your keys more, make sure you specify IdentityFile and Identities Only in the per host definitions in your ssh config. By default assuming you use an ssh agent (no forwarding) with multiple keys and a default ssh config, the behavior is to just try to auth with every key in order. So if you're worried about the ssh server identifying you, you're still exposing yourself. I don't think this is much of a concern but worth noting. Slightly more important: you're wasting time during the initial connection to fail authentication a few times. This can matter more with higher latency Even more important: sshd has a configurable number of times a client is allowed to fail authentication in a session attempt. If you have too many other keys in your agent you will just fail to auth before it tries the key that is actually valid for that host.
- leni536 3y agoIt's a good practice, but it's somewhat against the grain of ssh defaults. It's not surprising that many people stick to the defaults.
- deleted 3y ago[deleted]
- thih9 3y agoThis is only a threat if you enable agent forwarding for all hosts. If you enable agent forwarding for all hosts then yes, data will be forwarded. Your link says: > Don’t enable agent forwarding when connecting to untrustworthy hosts. Fortunately, the ~/.ssh/config syntax makes this fairly simple
- binkHN 3y agoLike you noted, ForwardAgent no is the default in /etc/ssh/ssh_config.
- chrismorgan 3y agoAnd for privacy, don’t let it know your identity or username: ssh -o PubkeyAuthentication=no -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -a nobody@terminal.shop Otherwise, the remote server can probably identify who you are on platforms like GitHub.
- throwaway984393 3y ago[dead]
- abc_lisper 3y agoDang. Didn't know this was a thing. Thank you!
- gowld 3y agoThat's terrifying. I don't understand why the design requires Forwarding to work without more explicit consent from the client at use time. (That is, when the middle tier wants to make a connection, it should forward an encrypted challenge from the server that can only be decrypted, answered, and re-encrypted by the original ssh keyholder on the client, similar to how, you know, ssh itself works over untrusted routers.
- heavyset_go 3y agoUsing discoverable and non-discoverable keys via FIDO security keys will require PIN + physical confirmation, or just physical confirmation, by default if anyone tries to use your agent's keys.
- raggi 3y agoYou actually want to verify first or someone will mitm you, e.g. mitm.terminal.shop.rag.pub
- kazinator 3y agoThis feature is not enabled by default; "ForwardAgent = yes" has to be in the config file. The article you cited makes it clear that you can turn this on for specific hosts in your private SSH config (and probably should do it that way). So why wouldn't you? Turning on forwarding globally and then having to remember to disable it for some untrusted hosts with -a looks silly and error-prone to me.
- SoftTalker 3y agoSSH Agent Forwarding does not happen by default. You need to include the -A option in your ssh command, unless maybe you've enabled it globally in your ~/.ssh/config file. They can't get your private keys, but they could "perform operations on the keys that enable them to authenticate using the identities loaded into the agent" (quoting the man page). This would also only be possible while you are connected.
- arcanemachiner 3y agoThanks for the PSA. It gave me a good opportunity to double check that I hadn't enabled agent forwarding in any of my SSH scripts that don't need it.
- arghwhat 3y agoJust to be clear, ssh agent forwarding is disabled by default and enabling it is always a hazard when connecting to machines that others also have access to. Not at all specific to this.
- mercora 3y agoYou can configure the agent to confirm each key usage to have your cake and eat it too. :) It's also good to see if any malicious process tries to make use of the agent locally!
- amne 3y agohere we go again. domain and path restricted cookies anyone?
- lrvick 3y agoIf you want to use SSH forwarding reasonably safely, use a yubikey for ssh so you have to tap once for each hop. Now a MITM can't use your key for more hops without you physically consenting to each one.
- dartos 3y agoWith this one comment, you’ve convinced me that ssh apps are a bad idea