Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
Thanks, -sv
On Thu, 2011-09-29 at 15:16 -0400, seth vidal wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
+1
i'm an Infra n00b, but definitely +1 out of good practice.
On Thu, Sep 29, 2011 at 3:21 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On Thu, 2011-09-29 at 15:16 -0400, seth vidal wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
+1
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Thu, Sep 29, 2011 at 03:16:03PM -0400, seth vidal wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
+1
-Toshio
On Thu, 29 Sep 2011 15:16:03 -0400 seth vidal skvidal@fedoraproject.org wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
+∞
kevin
On Thu, Sep 29, 2011 at 13:16, seth vidal skvidal@fedoraproject.org wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
+1 since publishing their private keys on a web page is probably not allowed.
Thanks, -sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
+1
Ramon Almeida.
On Thu, 29 Sep 2011 14:19:25 -0600, Stephen John Smoogen smooge@gmail.com wrote:
On Thu, Sep 29, 2011 at 13:16, seth vidal skvidal@fedoraproject.org wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
+1 since publishing their private keys on a web page is probably not allowed.
Thanks, -sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Thu, Sep 29, 2011 at 4:16 PM, seth vidal skvidal@fedoraproject.org wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
Thanks, -sv
+1
On Sep 29, 2011 12:16 PM, "seth vidal" skvidal@fedoraproject.org wrote:
Hi,
I'd like to put a new policy in place which goes something like this:
If you upload your private keys (encrypted or not) we will remove them, then we will remove your public keys from FAS and force you to login and give a new one in FAS.
We do the last step on the basis that your private key, being on a networked, multi-user machine is now exposed to the world and potentially compromised. So we can no longer trust it.
thoughts?
Thanks, -sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
I'm definitely saying +1. I'm guilty of putting my keys on bastion though, but I deleted them a while back.
Is there a way we can make users not able to write to that file, or have a cron job automatically sweep and delete private keys, as well as notify users that we found a private key, and it was deleted, and their public key in FAS if it was also removed, and that they have to add a new one (maybe even ensure it's different) ?
Darren VanBuren
I'm also guilty of putting private keys on bastion, but not a private key that gives access to anything else. I didn't want to do agent forwarding (and thereby giving root@bastion access to jump around to other systems I'm admining), and AFAIR I needed pubkey logins to jump to puppet01.. So I created a set of keys for usage within the fedora infrastructure. Maybe not optimal security-wise for fedora, but I didn't quite see how I would be able to do this securely for all ("ssh-add -c" being too cumbersome).
IMHO there's something lacking in the infrastructure policy. How are people supposed to do authentication between f.ex. bastion and puppet01? If we can't use passwords and can't have private-keys on bastion -- do you require agent forwarding ? I think agent forwarding is worse than keeping a private key on bastion, since it means a security breach within fedora can easily spread to other systems I manage.
Time to implement kerberos/IPA or ssh host-authentication ?
-jf
The recommended method is using agent forwarding at this time according to http://infrastructure.fedoraproject.org/infra/docs/sshaccess.txt
I agree that this is not the best solution, but it's no worse than keeping the private key on the machine, because the private key is on the filesystem for extended periods of time, while your agent is only forwarded for the duration of your shell session (which with most ISPs is cut at a certain point).
Darren VanBuren ================== http://theoks.net/
On Tue, Oct 4, 2011 at 00:27, Jan-Frode Myklebust janfrode@tanso.net wrote:
I'm also guilty of putting private keys on bastion, but not a private key that gives access to anything else. I didn't want to do agent forwarding (and thereby giving root@bastion access to jump around to other systems I'm admining), and AFAIR I needed pubkey logins to jump to puppet01.. So I created a set of keys for usage within the fedora infrastructure. Maybe not optimal security-wise for fedora, but I didn't quite see how I would be able to do this securely for all ("ssh-add -c" being too cumbersome).
IMHO there's something lacking in the infrastructure policy. How are people supposed to do authentication between f.ex. bastion and puppet01? If we can't use passwords and can't have private-keys on bastion -- do you require agent forwarding ? I think agent forwarding is worse than keeping a private key on bastion, since it means a security breach within fedora can easily spread to other systems I manage.
Time to implement kerberos/IPA or ssh host-authentication ?
-jf _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Tue, 4 Oct 2011 00:43:51 -0700 Darren VanBuren onekopaka@gmail.com wrote:
The recommended method is using agent forwarding at this time according to http://infrastructure.fedoraproject.org/infra/docs/sshaccess.txt
No, there's no need for agent forwarding, and thats hopefully not what the policy / sop says. ;)
It uses ssh -W, which basically just forwards stdout/stdin to the remote machine (or you can use nc, which does the same exact thing).
This means you authenticate to bastion, then run the command to forward things and all the rest of your communication is with whatever machine you are connecting to. No agent. No private keys stored on shared machines. No need to ssh to a machine then ssh to another one, it's all in one command.
kevin
Oh, so it's more like tunnelling SSH in SSH, similar to X11 in SSH or SOCKS through SSH?
I just remember that last time I connected I think I had to use agent forwarding. I may be wrong, I was tired while writing this email last night.
On Oct 4, 2011 6:00 AM, "Kevin Fenzi" kevin@scrye.com wrote:
On Tue, 4 Oct 2011 00:43:51 -0700 Darren VanBuren onekopaka@gmail.com wrote:
The recommended method is using agent forwarding at this time according to http://infrastructure.fedoraproject.org/infra/docs/sshaccess.txt
No, there's no need for agent forwarding, and thats hopefully not what the policy / sop says. ;)
It uses ssh -W, which basically just forwards stdout/stdin to the remote machine (or you can use nc, which does the same exact thing).
This means you authenticate to bastion, then run the command to forward things and all the rest of your communication is with whatever machine you are connecting to. No agent. No private keys stored on shared machines. No need to ssh to a machine then ssh to another one, it's all in one command.
kevin
On Tue, 4 Oct 2011 07:37:38 -0700 Darren VanBuren onekopaka@gmail.com wrote:
Oh, so it's more like tunnelling SSH in SSH, similar to X11 in SSH or SOCKS through SSH?
I just remember that last time I connected I think I had to use agent forwarding. I may be wrong, I was tired while writing this email last night.
Yeah, basically using bastion simply as a way to connect to other sshd's.
It's nice, because:
- You don't need your private key on any shared systems.
- You don't need to run ssh agent forwarding at all. (You can in rare cases when you need to copy things between internal machines).
- You don't have to ssh into a bastion then another machine, you can 'ssh foobar' and it logs you into foobar (it's using bastion behind the scenes here, but thats transparent).
- You don't need any config on the bastion host, all of it's on your local machine, so if bastion is re-installed it doesn't matter.
kevin
On Tue, Oct 04, 2011 at 08:45:22AM -0600, Kevin Fenzi wrote:
On Tue, 4 Oct 2011 07:37:38 -0700 Darren VanBuren onekopaka@gmail.com wrote:
Oh, so it's more like tunnelling SSH in SSH, similar to X11 in SSH or SOCKS through SSH?
I just remember that last time I connected I think I had to use agent forwarding. I may be wrong, I was tired while writing this email last night.
Yeah, basically using bastion simply as a way to connect to other sshd's.
It's nice, because:
You don't need your private key on any shared systems.
You don't need to run ssh agent forwarding at all. (You can in rare cases when you need to copy things between internal machines).
One time when I've found agent forwarding unavoidable is when working on development of code hosted in fedorahosted. Checkouts can be done anonymously, but pushing changes back to fedorahosted needs an authenticated ssh connection. This counts as copying things between machines but it's common enough for what I do in infrastructure that I'd love to figure out some way around it.
-Toshio
On Tue, 4 Oct 2011 08:19:55 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
One time when I've found agent forwarding unavoidable is when working on development of code hosted in fedorahosted. Checkouts can be done anonymously, but pushing changes back to fedorahosted needs an authenticated ssh connection. This counts as copying things between machines but it's common enough for what I do in infrastructure that I'd love to figure out some way around it.
Hum... not sure I understand. Which two internal machines would this be copying between?
kevin
On Wed, Oct 05, 2011 at 09:36:12AM -0600, Kevin Fenzi wrote:
On Tue, 4 Oct 2011 08:19:55 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
One time when I've found agent forwarding unavoidable is when working on development of code hosted in fedorahosted. Checkouts can be done anonymously, but pushing changes back to fedorahosted needs an authenticated ssh connection. This counts as copying things between machines but it's common enough for what I do in infrastructure that I'd love to figure out some way around it.
Hum... not sure I understand. Which two internal machines would this be copying between?
For instance, app01.dev and fedorahosted.org
-Toshio
On Wed, 5 Oct 2011 09:14:41 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Wed, Oct 05, 2011 at 09:36:12AM -0600, Kevin Fenzi wrote:
On Tue, 4 Oct 2011 08:19:55 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
One time when I've found agent forwarding unavoidable is when working on development of code hosted in fedorahosted. Checkouts can be done anonymously, but pushing changes back to fedorahosted needs an authenticated ssh connection. This counts as copying things between machines but it's common enough for what I do in infrastructure that I'd love to figure out some way around it.
Hum... not sure I understand. Which two internal machines would this be copying between?
For instance, app01.dev and fedorahosted.org
Ah, ok.
I guess the only alternative there would be copying down to your local machine and up to the other one. That could end up being a lot slower and is also two steps instead of one. ;(
One possible compromise: go ahead and use ssh agent forwarding, but after you login, do a 'ssh-add -D' to drop all your keys. Then, when/if you need to make a copy connection it should ask for your passphrase to unlock the key again. If someone tries to hyjack your agent connection, you would see the request to unlock the key and could reject it.
kevin
On Fri, Oct 07, 2011 at 09:30:00AM -0600, Kevin Fenzi wrote:
One possible compromise: go ahead and use ssh agent forwarding, but after you login, do a 'ssh-add -D' to drop all your keys. Then, when/if you need to make a copy connection it should ask for your passphrase to unlock the key again. If someone tries to hyjack your agent connection, you would see the request to unlock the key and could reject it.
To eliminate the race condition after login, the necessary key could be added with "ssh-add -c". This makes the agent ask for confirmation before using a key for authentication.
Kind regards Till
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 4 Oct 2011 08:19:55 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Tue, Oct 04, 2011 at 08:45:22AM -0600, Kevin Fenzi wrote:
On Tue, 4 Oct 2011 07:37:38 -0700 Darren VanBuren onekopaka@gmail.com wrote:
Oh, so it's more like tunnelling SSH in SSH, similar to X11 in SSH or SOCKS through SSH?
I just remember that last time I connected I think I had to use agent forwarding. I may be wrong, I was tired while writing this email last night.
Yeah, basically using bastion simply as a way to connect to other sshd's.
It's nice, because:
You don't need your private key on any shared systems.
You don't need to run ssh agent forwarding at all. (You can in
rare cases when you need to copy things between internal machines).
One time when I've found agent forwarding unavoidable is when working on development of code hosted in fedorahosted. Checkouts can be done anonymously, but pushing changes back to fedorahosted needs an authenticated ssh connection. This counts as copying things between machines but it's common enough for what I do in infrastructure that I'd love to figure out some way around it.
-Toshio
I find that i need to when staging releases, i need to rsync data from one host to another and its all done over ssh, i guess we could make some custom rsync modules on some hosts to allow me to use plain old rsync rather than rsync over ssh.
Dennis
infrastructure@lists.fedoraproject.org
-
Adam M. Dutko -
Darren VanBuren -
Dennis Gilmore -
Jan-Frode Myklebust -
Jonathan Nalley -
Kevin Fenzi -
Rafael Gomes -
Ramon Almeida -
Seth Vidal -
Stephen Gallagher -
Stephen John Smoogen -
Till Maas -
Toshio Kuratomi