Multiple private keys - SSH

This is a discussion on Multiple private keys - SSH ; Hi, I've been using ssh to access a remote server (server A) from my workstation. The admin of server A do not provide me a password, he prefers to use "shared secrets" for access control -- he creates a userid ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Multiple private keys

  1. Multiple private keys

    Hi,

    I've been using ssh to access a remote server (server A) from my
    workstation. The admin of server A do not provide me a password, he
    prefers to use "shared secrets" for access control -- he creates a
    userid for me, generates a key pair, puts the public key in ~/.ssh/
    authorized_keys, provides me the userid and the private key; I copy
    the private key into id.rsa on my workstation, and I then ssh into
    server A. No password prompt appears.

    Now I need to access another server (server B) from my workstation.
    The admin of server B also uses the "shared secrets". The admins
    won't use the same keys.

    Is there any way to switch back and forth between the two private keys
    on my workstation, short of replacing the id_rsa file every time I
    want to access A or B?

    ed




  2. Re: Multiple private keys

    efair wrote:
    >Is there any way to switch back and forth between the two private keys
    >on my workstation, short of replacing the id_rsa file every time I
    >want to access A or B?


    save them as id_rsa_A and id_rsa_B, and in your ssh_config file put
    Host A
    IdentityFile $HOME/.ssh/id_rsa_A

    Host B
    IdentityFile $HOME/.ssh/id_rsa_B

    Or just use 'ssh -i id_rsa_A A' when you connect.
    --
    Mark Rafn dagon@dagon.net

  3. Re: Multiple private keys

    >>>>> "efair" == efair writes:

    efair> Hi, I've been using ssh to access a remote server (server A)
    efair> from my workstation. The admin of server A do not provide me a
    efair> password, he prefers to use "shared secrets" for access control

    Btw, this terminology is wrong -- this is not a shared-secret technique,
    but rather public key (the whole point is that there *is* no shared secret
    here).

    efair> -- he creates a userid for me, generates a key pair, puts the
    efair> public key in ~/.ssh/ authorized_keys, provides me the userid
    efair> and the private key; I copy the private key into id.rsa on my
    efair> workstation, and I then ssh into server A. No password prompt
    efair> appears.

    .... and little security appears, either. First, you should generate the
    key yourself and send him the public part; there is no need for him to
    ever see your private key. Second, if this is for interactive use
    consider using ssh-agent instead:

    http://www.snailbook.com/faq/no-passphrase.auto.html

    efair> Now I need to access another server (server B) from my
    efair> workstation. The admin of server B also uses the "shared
    efair> secrets". The admins won't use the same keys.

    efair> Is there any way to switch back and forth between the two
    efair> private keys on my workstation, short of replacing the id_rsa
    efair> file every time I want to access A or B?

    efair> ed

    --
    Richard Silverman
    res@qoxp.net


  4. Re: Multiple private keys

    efair wrote:
    > Hi,
    >
    > I've been using ssh to access a remote server (server A) from my
    > workstation. The admin of server A do not provide me a password, he
    > prefers to use "shared secrets" for access control -- he creates a
    > userid for me, generates a key pair, puts the public key in ~/.ssh/
    > authorized_keys, provides me the userid and the private key; I copy
    > the private key into id.rsa on my workstation, and I then ssh into
    > server A. No password prompt appears.
    >
    > Now I need to access another server (server B) from my workstation.
    > The admin of server B also uses the "shared secrets". The admins
    > won't use the same keys.
    >
    > Is there any way to switch back and forth between the two private keys
    > on my workstation, short of replacing the id_rsa file every time I
    > want to access A or B?


    Yes, of course. You can create an "ssh-agent" that stores both keys dynamically, or you can tell your SSH client to use a specific key to make its connections. How you do this depends on your client, but Putty and Pageant for Windows has nice support for both, and various UNIX/Linux tools like "keychain" work quite well.

  5. Re: Multiple private keys

    Richard E. Silverman wrote:
    >>>>>> "efair" == efair writes:

    >
    > efair> Hi, I've been using ssh to access a remote server (server A)
    > efair> from my workstation. The admin of server A do not provide me a
    > efair> password, he prefers to use "shared secrets" for access control
    >
    > Btw, this terminology is wrong -- this is not a shared-secret technique,
    > but rather public key (the whole point is that there *is* no shared secret
    > here).
    >
    > efair> -- he creates a userid for me, generates a key pair, puts the
    > efair> public key in ~/.ssh/ authorized_keys, provides me the userid
    > efair> and the private key; I copy the private key into id.rsa on my
    > efair> workstation, and I then ssh into server A. No password prompt
    > efair> appears.
    >
    > ... and little security appears, either. First, you should generate the
    > key yourself and send him the public part; there is no need for him to
    > ever see your private key. Second, if this is for interactive use
    > consider using ssh-agent instead:


    Well, it's not such an uncommon technique. There are some advantages: the administrator can always re-publish the key to the same user, and assure that the key has a passphrase, or is the correct RSA or DSA or whatever format they demand, and the admin can use the same key for testing things on their end.

    But yeah, I agree that it's not ideal. The only big advantage is that you can make *sure*, if you're the admin publishing the key, that it has a passphrase at least to start.

  6. Re: Multiple private keys

    Nico Kadel-Garcia writes:

    > Well, it's not such an uncommon technique. There are some advantages:
    > the administrator can always re-publish the key to the same user, and
    > assure that the key has a passphrase,


    That is true initially, but the user can change or even remove the
    passphrase from the private key. In fact, in that situation I would
    expect the user to change the passphrase.

  7. Re: Multiple private keys

    On Dec 28, 9:04 pm, "Richard E. Silverman" wrote:
    > >>>>> "efair" == efair writes:

    >
    > efair> Hi, I've been using ssh to access a remote server (server A)
    > efair> from my workstation. The admin of server A do not provide me a
    > efair> password, he prefers to use "shared secrets" for access control
    >
    > Btw, this terminology is wrong -- this is not a shared-secret technique,
    > but rather public key (the whole point is that there *is* no shared secret
    > here).
    >
    > efair> -- he creates a userid for me, generates a key pair, puts the
    > efair> public key in ~/.ssh/ authorized_keys, provides me the userid
    > efair> and the private key; I copy the private key into id.rsa on my
    > efair> workstation, and I then ssh into server A. No password prompt
    > efair> appears.
    >
    > ... and little security appears, either. First, you should generate the
    > key yourself and send him the public part; there is no need for him to
    > ever see your private key. Second, if this is for interactive use
    > consider using ssh-agent instead:
    >
    > http://www.snailbook.com/faq/no-passphrase.auto.html
    >
    > efair> Now I need to access another server (server B) from my
    > efair> workstation. The admin of server B also uses the "shared
    > efair> secrets". The admins won't use the same keys.
    >
    > efair> Is there any way to switch back and forth between the two
    > efair> private keys on my workstation, short of replacing the id_rsa
    > efair> file every time I want to access A or B?
    >
    > efair> ed
    >
    > --
    > Richard Silverman
    > r...@qoxp.net



  8. Re: Multiple private keys

    Richard,
    You are right about the terminology, the admin actually calls it
    "preshared keys", not "shared secret". My mistake.

    ed

    On Dec 28, 9:04 pm, "Richard E. Silverman" wrote:
    > >>>>> "efair" == efair writes:

    >
    > efair> Hi, I've been using ssh to access a remote server (server A)
    > efair> from my workstation. The admin of server A do not provide me a
    > efair> password, he prefers to use "shared secrets" for access control
    >
    > Btw, this terminology is wrong -- this is not a shared-secret technique,
    > but rather public key (the whole point is that there *is* no shared secret
    > here).
    >
    > efair> -- he creates a userid for me, generates a key pair, puts the
    > efair> public key in ~/.ssh/ authorized_keys, provides me the userid
    > efair> and the private key; I copy the private key into id.rsa on my
    > efair> workstation, and I then ssh into server A. No password prompt
    > efair> appears.
    >
    > ... and little security appears, either. First, you should generate the
    > key yourself and send him the public part; there is no need for him to
    > ever see your private key. Second, if this is for interactive use
    > consider using ssh-agent instead:
    >
    > http://www.snailbook.com/faq/no-passphrase.auto.html
    >
    > efair> Now I need to access another server (server B) from my
    > efair> workstation. The admin of server B also uses the "shared
    > efair> secrets". The admins won't use the same keys.
    >
    > efair> Is there any way to switch back and forth between the two
    > efair> private keys on my workstation, short of replacing the id_rsa
    > efair> file every time I want to access A or B?
    >
    > efair> ed
    >
    > --
    > Richard Silverman
    > r...@qoxp.net



  9. Re: Multiple private keys

    Graham Murray wrote:
    > Nico Kadel-Garcia writes:
    >
    >> Well, it's not such an uncommon technique. There are some advantages:
    >> the administrator can always re-publish the key to the same user, and
    >> assure that the key has a passphrase,

    >
    > That is true initially, but the user can change or even remove the
    > passphrase from the private key. In fact, in that situation I would
    > expect the user to change the passphrase.


    I'd hope so, but relying on a non-technical community to do so is.... like asking them to change their passwords regularly and not share them with anyone else. You *know* they're going to ignore the rules.

+ Reply to Thread