Revisions to SSH authentication by public key and password in the same time

corrected typos, improved formatting

edit approved Jan 10, 2017 at 12:14

1.8k
4
27
35

Normally, if you use PublicKeyPublicKey and PasswordPassword it is a fall back. Public KeyPublicKey is tried first because it is safer and more secure, then passwordPassword is attempted.

I STRONGLY (and I can't make that bold enough). Suggest you allow only PublicKeyPublicKey based authentication for any sshSSH servers that you have running on the internetInternet.

When the SSH connection is established using PasswordPassword authentication the password is sent to the server. Password authentication leave you wide open to the normal route of brute forcing a password. Which can and will happen, if there are enough users using that see server (one of them will pick a crappy password).

Key based authentication is much more secure, because it binds a user on a machine to a user on another machine. The key is typically generated per client machine/user pair. When I explain this to clients, I usually use the ID card example. You have one ID card but it can get you into many places.

That said, keys can be encrypted with passwords. So the key you generate on your local machine can have (and does by default) a password to decrepitdecrypt it. Meaning that your local machine will ask you for a password, decrypt your key, send it to the server, and the server will try to authenticate. (In fairness it doesn't really decrypt your key, it's that the public key is "offset" by your password).

So, If you use PublickKeyPublicKey then you will need to provide a publicKeypublic key to the user/machine combo your trying to connect to.

If you use PasswordPassword then you will need to provide a password (sent in the clear) to the server your trying to connect to.

If you use PublicKeyPublicKey and PasswordPassword then you will need to provide Either a PublicKeypublic key or a password.

Normally, if you use PublicKey and Password it is a fall back. Public Key is tried first because it is safer and more secure, then password is attempted.

I STRONGLY (and I can't make that bold enough). Suggest you allow only PublicKey based authentication for any ssh servers that you have running on the internet.

When the SSH connection is established using Password authentication the password is sent to the server. Password authentication leave you wide open to the normal route of brute forcing a password. Which can and will happen, if there are enough users using that see server (one of them will pick a crappy password).

Key based authentication is much more secure, because it binds a user on a machine to a user on another machine. The key is typically generated per client machine/user pair. When I explain this to clients, I usually use the ID card example. You have one ID card but it can get you into many places.

That said, keys can be encrypted with passwords. So the key you generate on your local machine can have (and does by default) a password to decrepit it. Meaning that your local machine will ask you for a password, decrypt your key, send it to the server, and the server will try to authenticate. (In fairness it doesn't really decrypt your key, it's that the public key is "offset" by your password).

So, If you use PublickKey then you will need to provide a publicKey to the user/machine combo your trying to connect to.

If you use Password then you will need to provide a password (sent in the clear) to the server your trying to connect to.

If you use PublicKey and Password then you will need to provide Either a PublicKey or a password.

Normally, if you use PublicKey and Password it is a fall back. PublicKey is tried first because it is safer and more secure, then Password is attempted.

I STRONGLY (and I can't make that bold enough). Suggest you allow only PublicKey based authentication for any SSH servers that you have running on the Internet.

When the SSH connection is established using Password authentication the password is sent to the server. Password authentication leave you wide open to the normal route of brute forcing a password. Which can and will happen, if there are enough users using that see server (one of them will pick a crappy password).

Key based authentication is much more secure, because it binds a user on a machine to a user on another machine. The key is typically generated per client machine/user pair. When I explain this to clients, I usually use the ID card example. You have one ID card but it can get you into many places.

That said, keys can be encrypted with passwords. So the key you generate on your local machine can have (and does by default) a password to decrypt it. Meaning that your local machine will ask you for a password, decrypt your key, send it to the server, and the server will try to authenticate. (In fairness it doesn't really decrypt your key, it's that the public key is "offset" by your password).

So, If you use PublicKey then you will need to provide a public key to the user/machine combo your trying to connect to.

If you use Password then you will need to provide a password (sent in the clear) to the server your trying to connect to.

If you use PublicKey and Password then you will need to provide Either a public key or a password.

deleted 27 characters in body

Source Link

edited Nov 7, 2013 at 17:57

coteyr

4.4k
19
24

Normally, if you use PublicKey and Password it is a fall back. Public Key is tried first because it is safer and more secure, then password is attempted.

I STRONGLY (and I can't make that bold enough). Suggest you allow only PublicKey based authentication for any ssh servers that you have running on the internet.

When the SSH connection is established using Password authentication the password is sent "in the clear" to the server. In addition passwordPassword authentication leave you wide open to the normal route of brute forcing a password. Which can and will happen, if there are enough users using that see server (one of them will pick a crappy password).

Key based authentication is much more secure, because it binds a user on a machine to a user on another machine. The key is typically generated per client machine/user pair. When I explain this to clients, I usually use the ID card example. You have one ID card but it can get you into many places.

That said, keys can be encrypted with passwords. So the key you generate on your local machine can have (and does by default) a password to decrepit it. Meaning that your local machine will ask you for a password, decrypt your key, send it to the server, and the server will try to authenticate. (In fairness it doesn't really decrypt your key, it's that the public key is "offset" by your password).

So, If you use PublickKey then you will need to provide a publicKey to the user/machine combo your trying to connect to.

If you use Password then you will need to provide a password (sent in the clear) to the server your trying to connect to.

If you use PublicKey and Password then you will need to provide Either a PublicKey or a password.

Normally, if you use PublicKey and Password it is a fall back. Public Key is tried first because it is safer and more secure, then password is attempted.

I STRONGLY (and I can't make that bold enough). Suggest you allow only PublicKey based authentication for any ssh servers that you have running on the internet.

When the SSH connection is established using Password authentication the password is sent "in the clear" to the server. In addition password authentication leave you wide open to the normal route of brute forcing a password. Which can and will happen, if there are enough users using that see server (one of them will pick a crappy password).