Password-free sftp

[wethackrey]

Hello folks - I have a need to configure an OS X server to support password-free sftp connections. So far I have:
1) verified that sshd.config contains:
#RSAAuthentication yes and
#PubkeyAuthentication yes.
(They're commented out which indicates that yes is the default value.)
2) generated a keypair using ssh-keygen with no password specified in the key
3) placed the private key in the user's .ssh directory as the file authorized_keys with permissions set to 600. This user (call him "testguy" is the user that will be logging in via ssh or sftp - ssh testguy@theserverinquestion.com
4) placed an entry in the client computer's known_hosts file prefaced by the host name and ip address

I continue to get a password request when trying to connect. If I change one of the keys to break the authentication process, I see a key fingerprint that does not match the key in ~/.ssh/authorized_keys. It appears to be the fingerprint from a my server's /private/etc/ssh_host_rsa_key file. How do I force a user logging in via ssh to use the ~/.ssh/authorized_keys key file for authentication?

[baf]

add an entry in his machines /etc/ssh/ssh_config or similiar or his ~/.ssh/config (which probably doesnt exist) like this

host 192.168.56.* *.v
PubkeyAuthentication yes

after host can follow ip-address or name and may as you see in my example include * as wildcard. so in my example my ssh/scp would use keys for any machine in the domain v or any ip int 192.168.56.0/24

[acme.mail.order]

You dont 'force' it - if it's not working you've done something wrong.

When you used ssh-keygen did you specify a type? `ssh-keygen -t RSA` ?

Did you do this as that user? I don't think user A can create keys for user B.

And it looks like you didn't put the keys in the right place.
* .ssh/id_rsa goes in the user's home folder on the client (the place you want to type `ssh testguy@theserverinquestion.com` from

* the CONTENT of .ssh/id_rsa.pub goes in the user's home folder on theserverinquestion.com in the ~/.ssh/authorized_keys file (create it if it's not there). This file is VERY picky about linebreaks - one key, one line. pico likes to add new lines where you don't want them.

* You don't need to do anything with known_hosts, it's taken care of the first time you log in.

[wethackrey]

When you used ssh-keygen did you specify a type? `ssh-keygen -t RSA` ?

No but RSA is the default and, looking at the public keys, it's prefixed by "ssh-rsa". I'll try that though to see if it makes a difference.

Did you do this as that user? I don't think user A can create keys for user B

I don't think you can either. I created the key on the server logged in as the "testguy" user.

And it looks like you didn't put the keys in the right place.
* .ssh/id_rsa goes in the user's home folder on the client (the place you want to type `ssh testguy@theserverinquestion.com` from

You're saying the PRIVATE key, which is generated on the server side while logged in as "testguy" get's transferred to the user's ~/.ssh/id_rsa file on the CLIENT side?

* the CONTENT of .ssh/id_rsa.pub goes in the user's home folder on theserverinquestion.com in the ~/.ssh/authorized_keys file (create it if it's not there).

And the PUBLIC key remains on the server (theserverinquestion.com) in the ~/.ssh/authorized_keys file for "testguy"?

Is this correct? I guess my natural inclination is to key the private key private to the machine that generated it and distribute the public key.

[acme.mail.order]

The private key IS private to the machine that generated it, and it's private to the machine that you intend to use ssh from, not to.

Generate your keys from the client, leave the private key (id_rsa) alone and add id_rsa.pub to the authorized_keys file on the server.

Think of it this way: you must keep the private key secret, the public key can be distributed far and wide on as many servers as you wish. It would make no sense to generate this key on the individual servers.

[wethackrey]

@ acme.mail.order

OK. That makes sense to me. I've now done this:

1) On the client machine, while logged in as the user that will be doing the ssh connection, (this is a test client, our oem client will need to do the same) I have done ssh-keygen -t rsa (used lower case here instead of RSA since upper case returned an error). The passphrase was left blank.

2) transfered the id_rsa.pub file to the "theserverinquestion.com" server, placed it in the ~/.ssh/ directory of the "testguy" user and renamed it "authorized_keys" (since I have only one at the moment).

3) permissions on the id_rsa key files on the client machine were unchanged. Permissions on authorized_keys were changed to 600.

When running ssh testguy@theserverinquestion.com I continue to get a password request. Entering testguy's password on theserverinquestion.com granst access correctly to testguy's home directory.

Any ideas why the server is still looking for a password?

Also... just to confirm a technical question... the key authentication from client to host, which results in the addition of theserverinquestion.com's public key (from /private/etc/hosts_rsa_key.pub) being placed in known_hosts on the client, is a different ssh key authentication than the one we're discussing using the authorized_keys file? Is that right?

[acme.mail.order]

The known_kosts keyfile just checks that the server hasn't been replaced by another one.

First, I would check that the authorized_keys file on the server doesn't contain any linebreaks. 'ssh-rsa', the key, and your username MUST be on the same line.

If that doesn't work, wipe out the .ssh folders on client and server and start again.

[tw]

isn't password free sftp just plain old vanilla ftp? why do you need to specify a secure format (sftp->secure file transfer protocol) when you don't want to use any security?

[wethackrey]

isn't password free sftp just plain old vanilla ftp? why do you need to specify a secure format (sftp->secure file transfer protocol) when you don't want to use any security?

We DO want to use security, that's the whole point. Working properly, SFTP can establish a secure interchange with both server and client identities authenticated by RSA keypairs. Elimination of the password handshaking arguably doesn't reduce the level of security but it does make automating server-to-server data interchange easier to implement since the security is all handled by ssh.

Having said all of this, we still haven't been able to get this connectioon to work without being prompted for a password. I'm wondering if it's a sshd_config issue.

[acme.mail.order]

Did you also restore your config files to the default? This DOES work straight out of the box on 10.3-10.5