best practices: public key authentication - SSH

This is a discussion on best practices: public key authentication - SSH ; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm curious to find out what others think about pubkey authentication best practices. Assuming your private key is protected with a strong passphrase, is there any value in occasionally regenerating your keypair and replacing ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: best practices: public key authentication

  1. best practices: public key authentication

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I'm curious to find out what others think about pubkey authentication
    best practices. Assuming your private key is protected with a strong
    passphrase, is there any value in occasionally regenerating your keypair
    and replacing your public key on servers that you use pubkey
    authentication with?
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with PCLinuxOS - http://enigmail.mozdev.org

    iEYEARECAAYFAkgOHQAACgkQzIf+rZpn0oQljwCdHaLG7l5lco R0UUMQL86kMpGX
    rvYAn1ef25IKqdbGhDXu10o+LGQM7X8P
    =KHut
    -----END PGP SIGNATURE-----

  2. Re: best practices: public key authentication

    Chuck wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > I'm curious to find out what others think about pubkey authentication
    > best practices. Assuming your private key is protected with a strong
    > passphrase, is there any value in occasionally regenerating your keypair
    > and replacing your public key on servers that you use pubkey
    > authentication with?


    Yes. It helps prevent fascinating man-in-the-middle attacks if you use a
    public key for multiple remote targets, and it reminds you and others to
    discard access you don't need any longer.

    Now, I'd *love* to see a good password based web tool for generating and
    managing SSH private and public keys for shared services, like Subversion,
    Perforce, and CVS over SSH.

  3. Re: best practices: public key authentication

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Nico Kadel-Garcia wrote:
    | Chuck wrote:
    |> -----BEGIN PGP SIGNED MESSAGE-----
    |> Hash: SHA1
    |>
    |> I'm curious to find out what others think about pubkey authentication
    |> best practices. Assuming your private key is protected with a strong
    |> passphrase, is there any value in occasionally regenerating your keypair
    |> and replacing your public key on servers that you use pubkey
    |> authentication with?
    |
    | Yes. It helps prevent fascinating man-in-the-middle attacks if you use a
    | public key for multiple remote targets, and it reminds you and others to
    | discard access you don't need any longer.

    What exactly is a "fascinating" man in the middle attack and how does
    changing my keypair prevent it? I thought MITM attacks would be detected
    by the server's key changing. OpenSSH (and presumably others) warn you
    if the key of the server does not match what you've previously known it
    to be.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.5 (GNU/Linux)
    Comment: Using GnuPG with PCLinuxOS - http://enigmail.mozdev.org

    iEYEARECAAYFAkgONQ0ACgkQzIf+rZpn0oTdCwCgo6LIxrCnkg QcdmjCe7wxmfbJ
    5rwAnjmYeBLztCbvvYxnMEq7RraF2wbS
    =5O1W
    -----END PGP SIGNATURE-----

  4. Re: best practices: public key authentication

    Chuck wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Nico Kadel-Garcia wrote:
    > | Chuck wrote:
    > |> -----BEGIN PGP SIGNED MESSAGE-----
    > |> Hash: SHA1
    > |>
    > |> I'm curious to find out what others think about pubkey authentication
    > |> best practices. Assuming your private key is protected with a strong
    > |> passphrase, is there any value in occasionally regenerating your keypair
    > |> and replacing your public key on servers that you use pubkey
    > |> authentication with?
    > |
    > | Yes. It helps prevent fascinating man-in-the-middle attacks if you use a
    > | public key for multiple remote targets, and it reminds you and others to
    > | discard access you don't need any longer.
    >
    > What exactly is a "fascinating" man in the middle attack and how does
    > changing my keypair prevent it? I thought MITM attacks would be detected
    > by the server's key changing. OpenSSH (and presumably others) warn you
    > if the key of the server does not match what you've previously known it
    > to be.


    Many SSH servers have poor local security: sharing home direcotories via NFS,
    for example. Many SSH servers also have poor control over their hostbased
    private keys. With these, a man-in-the-middle attacker can theoretically
    pretend to be your SSH target, allow you to log in without password and
    especially with key-forwarding enabled, and allow you to connect to their
    man-in-the-middle, securely. They then provide an unsecured monitor in the
    middle, and pass along *ANOTHER* secured transaction to your destination host.

    Most of us would never notice such an attack. A few such leveraged attacks on
    a source code repository could create all sorts of problems for a secure
    source code repository.

+ Reply to Thread