1. The private key is not secure by default by putting it on a different host.
2. This still allows an evil user getting access to his original machine to SSH into any host requiring his private key.
1 should be pretty obvious. If my intention is to get a hold of the actual private key file, he just moved the target.
As for 2: We're talking about avoiding compromising a private key file stored on the client, so in order for that to be an issue in the first place, we're giving an evil user Y reading abilities on the local client. The normal user is called user X. The evil thing to do is to log into the other server on poor user X's behalf. User X used SSHProxy, and moved his private key to a raspberry pi. So, what does evil user Y do on user X's computer?
He just logs in through the SSHProxy, getting access to the remote service. Having the raspberry pi disconnect at times doesn't really matter, as that just means patience (or starting a job that keeps trying). Once logged in, evil user Y could add another key to the authorized_keys file if he wanted to.
Having a service automatically sign things with private key A stored in remote location B, as long as you provide private key B stored in "easily accessible" location A (Which we still assume due to thinking the private key was insecure) is no more secure than storing private key A in "easily accessible" location A. The only argument becomes the ability to occasionally take the pi offline, which doesn't seem to be what he touts as a reason for the project. The issue with this is essentially a reversed modified version of the ssh-agent socket issue, which is blindly signing things as well.
If you truly want to protect your private key:
* Encrypt a USB dongle
* Put a password protected private key on it
* Only plug said USB dongle in when you need it, store separately from your laptop (on your person)
* Change your password occasionally
Likewise, having a TPM be your signer doesn't change anything if you have it sign blindly. PCR's allow you to at least verify system state first, but using the TPM in this case only protects you against people stealing your filesystem without your physical machine. With access to the machine, the TPM will keep on signing things blindly. User interaction beats TPM in all areas. One of the cute features TPM was supposed to bring, that actually was going to matter (if you ask the manufacturers, that is) was Remote Attestation. Unfortunately, it wasn't any good and was never used for anything.
Also, for future reference, while it's completely okay to suggest that people are wrong or misunderstanding, there are nicer ways to say it than "You are just wrong", and "not understanding something when they criticise it". I have no idea about your qualifications, and you have no idea about mine. We're all humans, so be polite about it. No one likes being insulted.
> Also, for future reference, while it's completely okay to suggest that people are wrong or misunderstanding, there are nicer ways to say it than "You are just wrong", and "not understanding something when they criticise it".
It's useful information to me that you value pleasant phrasing over criticism that might improve your security.
It's also good to know that you completely ignored security advice from security professionals, making this a waste of time. You could say that up front as well: "I'm going to write a comment insulting you, but don't you DARE try to disprove me with logic!"
1. The private key is not secure by default by putting it on a different host. 2. This still allows an evil user getting access to his original machine to SSH into any host requiring his private key.
1 should be pretty obvious. If my intention is to get a hold of the actual private key file, he just moved the target. As for 2: We're talking about avoiding compromising a private key file stored on the client, so in order for that to be an issue in the first place, we're giving an evil user Y reading abilities on the local client. The normal user is called user X. The evil thing to do is to log into the other server on poor user X's behalf. User X used SSHProxy, and moved his private key to a raspberry pi. So, what does evil user Y do on user X's computer?
He just logs in through the SSHProxy, getting access to the remote service. Having the raspberry pi disconnect at times doesn't really matter, as that just means patience (or starting a job that keeps trying). Once logged in, evil user Y could add another key to the authorized_keys file if he wanted to.
Having a service automatically sign things with private key A stored in remote location B, as long as you provide private key B stored in "easily accessible" location A (Which we still assume due to thinking the private key was insecure) is no more secure than storing private key A in "easily accessible" location A. The only argument becomes the ability to occasionally take the pi offline, which doesn't seem to be what he touts as a reason for the project. The issue with this is essentially a reversed modified version of the ssh-agent socket issue, which is blindly signing things as well.
If you truly want to protect your private key: * Encrypt a USB dongle * Put a password protected private key on it * Only plug said USB dongle in when you need it, store separately from your laptop (on your person) * Change your password occasionally
Likewise, having a TPM be your signer doesn't change anything if you have it sign blindly. PCR's allow you to at least verify system state first, but using the TPM in this case only protects you against people stealing your filesystem without your physical machine. With access to the machine, the TPM will keep on signing things blindly. User interaction beats TPM in all areas. One of the cute features TPM was supposed to bring, that actually was going to matter (if you ask the manufacturers, that is) was Remote Attestation. Unfortunately, it wasn't any good and was never used for anything.
Also, for future reference, while it's completely okay to suggest that people are wrong or misunderstanding, there are nicer ways to say it than "You are just wrong", and "not understanding something when they criticise it". I have no idea about your qualifications, and you have no idea about mine. We're all humans, so be polite about it. No one likes being insulted.