have ForwardAgent turned on in your ssh_config file, or
are using the -A flag to ssh itself, say as part of a shell alias
then you are giving the remote host you connect to access to the private keys in your SSH agent, often in a fashion where you will not even be informed that the remote host has accessed those keys. This is not to say that this SSH-based service is doing so, but it is good to understand the potential security implications of using SSH to connect to things that you do not own or control.
To better understand the security implications: the remote host has access to ask the agent to use the private keys to sign some message; the remote host does not have access to retrieve the private keys.
In some situations, these are equivalent; especially if there’s no server nonce challenge or time stamp embedded in the data to be signed, so that a malicious actor can pre-sign tens of thousands of messages. In current implementations of how SSH requires messages to be signed, they’re not equivalent and the malicious actor needs ongoing access to the agent, to get specific messages signed.
Thus, quite frankly, I’d rather ssh from a secure box to a “less secure” box where I still want some onwards-connection to happen, but don’t trust every piece of software on that “less secure” box, than require that all the software be run locally, especially since we don’t have widespread usable capability systems to constrain local actors (although we’re slowly getting there, with things like Capsicum).
None of which protects you in the slightest if the initial box is a laptop where you also run a web-browser. Game over.
I would further recommend not doing that even when connecting to hosts you do control, in case they are compromised.
You can add keys with ssh-add -c (or use something that does it automatically) to be prompted before any remote host is able to use your forwarding agent, and also only enable ForwardAgent for specific hosts in ~/.ssh/config with the default being off.
You can do full VPN type stuff using SSH as well (no need for “poor man” type setups):
SSH-BASED VIRTUAL PRIVATE NETWORKS
ssh contains support for Virtual Private Network (VPN) tunnelling using the tun(4) network pseudo-device, allowing two networks to be joined securely. The sshd_config(5) configuration option PermitTunnel controls whether the server supports this, and at what level (layer 2 or 3 traffic).
Note that the keystroke-by-keystroke traffic generate a high-bandwidth timing side channel that can be used to infer a substantial amount of what you are typing.
I think it’s important to call out that if you:
ForwardAgentturned on in your ssh_config file, or-Aflag to ssh itself, say as part of a shell aliasthen you are giving the remote host you connect to access to the private keys in your SSH agent, often in a fashion where you will not even be informed that the remote host has accessed those keys. This is not to say that this SSH-based service is doing so, but it is good to understand the potential security implications of using SSH to connect to things that you do not own or control.
To better understand the security implications: the remote host has access to ask the agent to use the private keys to sign some message; the remote host does not have access to retrieve the private keys.
In some situations, these are equivalent; especially if there’s no server nonce challenge or time stamp embedded in the data to be signed, so that a malicious actor can pre-sign tens of thousands of messages. In current implementations of how SSH requires messages to be signed, they’re not equivalent and the malicious actor needs ongoing access to the agent, to get specific messages signed.
Thus, quite frankly, I’d rather ssh from a secure box to a “less secure” box where I still want some onwards-connection to happen, but don’t trust every piece of software on that “less secure” box, than require that all the software be run locally, especially since we don’t have widespread usable capability systems to constrain local actors (although we’re slowly getting there, with things like Capsicum).
None of which protects you in the slightest if the initial box is a laptop where you also run a web-browser. Game over.
I would further recommend not doing that even when connecting to hosts you do control, in case they are compromised.
You can add keys with
ssh-add -c(or use something that does it automatically) to be prompted before any remote host is able to use your forwarding agent, and also only enableForwardAgentfor specific hosts in~/.ssh/configwith the default being off.Yes. Never, ever do that.
You can do full VPN type stuff using SSH as well (no need for “poor man” type setups):
from ssh(1)
Previous thread on ssh-chat, if anyone is curious: https://lobste.rs/s/lwmnsg/ssh_chat_shazow_net
Note that the keystroke-by-keystroke traffic generate a high-bandwidth timing side channel that can be used to infer a substantial amount of what you are typing.
Very interesting, I did a search and found this paper if anyone else is interested:
http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf
Changed the title to “Why aren’t we using SSH for everything?” if anyone wants to update it. :)
Done.
The tag makes no sense, either. This should be security and maybe networking; go isn’t featured at all.
ssh-chat is written in go
Thanks kyle!
[Comment removed by author]