5 ms·

Why would people copy a private key around? Generate the public/private pair on the client machine and the public key is the one you put on other machines to S

• th0ma5 17y ago
  if you want to set up seamless logins of an account to anywhere from anywhere, you need to copy around both because any node could either be on the client or server side of the challenge and response.
  • lenni 17y ago
    So, you're saying that people paste their key online so they don't have to carry it around on a USB stick? Wow.
    • Legion 17y ago
      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.
      • lenni 17y ago
        That's what I meant. I simply could't believe that someone would do this.
  • axod 17y ago
    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.
    • ax0n 17y ago
      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.
      • deleted 17y ago
        [deleted]
      • dedward 17y ago
        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...
        • ax0n 17y ago
          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.
    • fragmede 17y ago
      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.)
      • xilun666 17y ago
        Doing so, you expose yourself in propagating penetration from a compromised server to a previously secure one.
  • frodwith 17y ago
    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.
    • mbreese 17y ago
      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.
      • barrkel 17y ago
        Automating ssh, however, is surprisingly painful.
        • rcoder 17y ago
          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.
      • jsn 17y ago
        For obvious reasons, you're much better off generating a new keypair for that (not reusing any existing private keys).
      • wizard_2 17y ago
        With python you have Fabric and paramiko which makes automating ssh very strait forward.
      • danieldon 17y ago
        Why wouldn't you just generate a new key pair?
  • arethuza 17y ago
    Isn't that a pretty broken design? Copying private keys around sounds like a really bad idea.
  • deleted 17y ago
    [deleted]
  • danieldon 17y ago
    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?
    • ars 17y ago
      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.
      • dedward 17y ago
        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.
  • philf 17y ago
    Or create a pair for each...
  • bluesmoon 17y ago
    ssh-agent?
  • avolkov 17y ago
    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.
  • lsc 17y ago
    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.