Seems like that's a serious edge case. Most times (IMHO) you'd be going one direction.

And if you do require both directions, you should generate separate keys on each host and just exchange the public ones.

You're absolutely correct, but it's actually pretty common to distribute that public key all over hell and then start shuffling the private one around between the ones you find yourself ssh-ing off of. At my last job, this practice among wayward sysadmins caused me a lot of gnashing of teeth.

Wrong move though - really there should be one key per machine - and then ssh-agent set up properly to take care of the intermediate machines so you can bounce around. Using the same private key on multiple machines is just asking for trouble when you need to revoke something...

Oh, believe me, I know. That's why I said it caused me much gnashing of teeth. SSH, particularly OpenSSH, is such a thing of beauty. It's a shame most sysads that I've dealt with abuse it like it's rsh and telnet.

I'd agree that uni-directional transfer is an edge case when you have only one server.

Unfortunately for network security, that seems less and less the case these days. I definitely find myself ssh'd into two remote systems relatively often and have a need to copy files between the two. (Swapping arguments to scp is not good enough.)

Doing so, you expose yourself in propagating penetration from a compromised server to a previously secure one.

In that case, use an ssh-agent and agent forwarding. Then you only need your private key on the box you're actually sitting at.

Unless you want to use headless logins...

An example would be a cron job that copies files to a backup server via scp or rsync over ssh. However, this should also be accompanied by host filters in the authorized_keys file to restrict access to specific hosts.

Using pastebin for this is wrong on so many levels.

For obvious reasons, you're much better off generating a new keypair for that (not reusing any existing private keys).

Automating ssh, however, is surprisingly painful.

This is why Net::SSH and Paramiko are so wonderful. Using the OpenSSH binaries through a pair of pipes is certainly a pain, but if you grok the protocol, either of those libraries can make it really easy to wire up secure pipes between machines.

Why wouldn't you just generate a new key pair?

With python you have Fabric and paramiko which makes automating ssh very strait forward.

Isn't that a pretty broken design? Copying private keys around sounds like a really bad idea.

Wow, wait, I don't get it. You can copy from anywhere to anywhere with just one set of public private key.

for example, copy file from local machine:

scp some_file.tar.gz alex@remote_ip:~/

now copy the same file from a remote to the local machine:

scp alex@remote_ip:~/some_file.tar.gz ~/

But seamless logins form anywhere to anywhere in the way you described seems like a bad idea, unless you are willing to implement kerberos, ldap and nfs4, in this way you can just log in into a client machine using your existing credentials (see PAM) and if you have your home directory property mounted you can have public/private keypair on that machine. But this is a lot of work.

Ugh. don't do that. if you /must/ have a system like that (and it's never a great idea) keep your private keys on one box, and enable agent forwarding. It's not as good as just enabling the one-way ssh, but it's not nearly as bad as scattering your keys.

Why does everyone seem to think it's okay to build a system where any one compromised box can compromise the rest of the system? this 'jelly doughnut security' is really popular among the PHB types, because it's easy, but it just seems really, really dangerous.

I feel like I'm missing something here. Why would someone copy around a single private key instead of generating a new key pair for each user@host?

You don't need to generate a new keypair - just copy your (single) public key to the authorized_keys file on each machine.

I can't think of any reason at all to copy the private key though.

No that's backwards - the reason is laziness.

Sysadmin has two worksations - say a laptop and a desktop. He wants to SSH into all his remote boxen from either. The default reaction might be to just copy his already-authorized private key to his other machine just for ease of use - the proper solution would be to generate a new keypair on the new machine and then copy it to the required remote machines as well, so either can be revoked and tracked separately.

So, you're saying that people paste their key online so they don't have to carry it around on a USB stick? Wow.

He didn't say it was the right way to do it. He didn't even say what he was describing was a good idea. He just offered an answer to the question, "Why would people copy a private key around?". Obviously, people are doing it for some reason, misguided as the reason may be.

That's what I meant. I simply could't believe that someone would do this.

ssh-agent?

Or create a pair for each...