current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 0 down vote favorite

Something is not clear to me with SSH authentication.

I have a Talend job which connects to sFTP (using SSH protocol) and on the property page of the component, I have the choice between: 1. Password authentication 2. Public key authentication

When I choose Password authentication the data to enter are username and password. but when I choose Public key authentication the data to enter are username, password, private key path and private key passphrase.

I though when a public key authentication is set on a server there is no need for a password.

Is the SSH enables an authentication using public key and password in the same time as a security enforcement or it is just a fallback which means if the public key is not authorized, the standard username/password will be used (if the sshd server permits it)?

share|improve this question
    
You could show verbose output log from such ssh session... – Jiri Xichtkniha Nov 7 '13 at 14:02
    
I have only access to my own machine for testing purpose and I use a public key auth without password; but I do not have access to the real servers. The question was just to know if it is possible or not to have both authentication. – ruffp Nov 7 '13 at 15:19
    
They can hack dual-password themself with ForceCommand and their own cooked scripts as well... – Jiri Xichtkniha Nov 8 '13 at 8:06
up vote 1 down vote accepted

OpenSSH 6.2 introduced multiple authentication methods. See sshd_config(5).

share|improve this answer
    
Then if they want both authentication, they must have (at least) this version of sshd on the server side, right? – ruffp Nov 7 '13 at 15:21
    
Obviously...... – Jiri Xichtkniha Nov 8 '13 at 8:06
up vote 0 down vote

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.

share|improve this answer
    
You might want to double-check the "in the clear" statement. RFC 4253 (among others) state that the two systems involved in an ssh connection first exchange identification strings. Immediately afterwards they exchange keys and an encryption algorithm and key will be negotiated during the key exchange. When encryption is in effect, all packet payloads must be encrypted. All this happens before you ever see a login: prompt. – Doug O'Neal Nov 7 '13 at 17:36
    
You are correct, updating answer. – coteyr Nov 7 '13 at 17:57
    
"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." --> unfortunately it is not my responsibility to choose what method, it is external providers sFTP who choose what is the best for them and we have to fit their choices. Some providers also have firewall rules to enable only our (and others authorized companies) IP(s). – ruffp Nov 8 '13 at 8:55
    
"So the key you generate on your local machine can have (and does by default) a password to decrepit it" --> I guess you are talking about the passphrase here. I made the distinction between password (to connect to the remote server) and the passphrase (to enable key extraction). – ruffp Nov 8 '13 at 8:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.