Return to Answer

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.

First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.

After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)

As you can imagine, in the first case the password is actually sent to the server (unless SSH would use password challenge response), in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSL traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) or has access to the server or client, your password will be known - with public-private key authentication and the challenge response model your private details will never fall in the hand of the attacker. So even if one server you connect to is compromised, other severs you use the same key for would not be!

There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise as an unencrypted password file would do, but it's easier to decrypt (on login) and use the private key. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.

Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key - There are ways around that. You can increase the usuability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type 'ssh remote-system-ip' and log in, without providing a passphrase, and do that multiple times until you log out of your session.

So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client, the server or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions and servers.

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.

First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.

After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)

As you can imagine, in the first case the password is actually sent to the server (unless SSH would use password challenge response), in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSH traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) or has access to the server or client, your password will be known - with public-private key authentication and the challenge response model your private details will never fall in the hand of the attacker. So even if one server you connect to is compromised, other servers you use the same key for would not be!

There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise as an unencrypted password file would do, but it's easier to decrypt (on login) and use the private key. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.

Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key – There are ways around that. You can increase the usability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type ssh remote-system-ip and log in, without providing a passphrase, and do that multiple times until you log out of your session.

So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client, the server or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions and servers.

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.

First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.

After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model.

As you can imagine, in the first case the password is actually sent to the server, in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSL traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) - your private details will never fall in the hand of the attacker.

There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.

Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key - There are ways around that. You can increase the usuability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type 'ssh remote-system-ip' and log in, without providing a passphrase, and do that multiple times until you log out of your session.

So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions.

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.

First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.

After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model. (In SSHv2 something a bit different but conceptually close is actually used)

As you can imagine, in the first case the password is actually sent to the server (unless SSH would use password challenge response), in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSL traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) or has access to the server or client, your password will be known - with public-private key authentication and the challenge response model your private details will never fall in the hand of the attacker. So even if one server you connect to is compromised, other severs you use the same key for would not be!

There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise as an unencrypted password file would do, but it's easier to decrypt (on login) and use the private key. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.

Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key - There are ways around that. You can increase the usuability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type 'ssh remote-system-ip' and log in, without providing a passphrase, and do that multiple times until you log out of your session.

So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client, the server or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions and servers.

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.

First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.

After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model.

As you can imagine, in the first case the password is actually sent to the server, in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSL traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) - your private details will never fall in the hand of the attacker.

There are other advantages of using a public key pair: The private key should not stored be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.

Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key - There are ways around that. You can increase the usuability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type 'ssh remote-system-ip' and log in, without providing a passphrase, and do that multiple times until you log out of your session.

So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions.

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them.

First of all, you must understand that user authentication is a different and separate process than the establishment of the secure channel. In laymans terms what this means is that first, the public key of the server is used (if accepted!) to construct the secure SSH channel, by enabling the negotiation of a symmetric key which will be used to protect the remaining session, enable channel confidentiality, integrity protection and server authentication.

After the channel is functional and secure, authentication of the user takes place. The two usual ways of doing that is by using a password or a public key pair. The password based authentication works as you can imagine: The client sends his password over the secure channel, the server verifies that this is indeed the password of the specific user and allows access. In the public key case, we have a very different situation. In this case, the server has the public key of the user stored. What happens next is that the server creates a random value (nonce), encrypts it with the public key and sends it to the user. If the user is who is supposed to be, he can decrypt the challenge and send it back to the server, who then confirms the identity of the user. It is the classic challenge-response model.

As you can imagine, in the first case the password is actually sent to the server, in the second your private key never leaves the client. In the imaginary scenario that someone intercepts the SSL traffic, and is able to decrypt it (using a compromised server private key, or if you accept a wrong public key when connecting to the server) - your private details will never fall in the hand of the attacker.

There are other advantages of using a public key pair: The private key should not be stored in cleartext in your client pc as you suggest. This of course leaves the private key file open to compromise. It should be stored encrypted, and need you to provide a usually long passphrase to decrypt it each time it is used.

Of course this means that you will have to provide the long passphrase each time you connect to a server, to unlock your private key - There are ways around that. You can increase the usuability of the system by using an authentication agent: This is a piece of software that unlocks your keys for the current session, when you log in to gnome for example or when you first ssh into your client, so you can just type 'ssh remote-system-ip' and log in, without providing a passphrase, and do that multiple times until you log out of your session.

So, to sum up, using public key pairs offers considerably more protection than using passwords or password lists which can be captured if the client or the secure session is compromised. In the case of not using a passphrase (which shouldn't happen), still public key pairs offer protection against compromised sessions.