Anyway, I am using scp and ssh to move files from one Linux box to another. So that I don't have to enter the password again, and again, and again, I decided to use ssh-keygen. Here's what I did so that going from workstation A to workstation B:
On workstation A:
ssh-keygen -t rsa
ssh username@B mkdir -p .ssh
cat .ssh/id_rsa.pub | ssh username@B 'cat >>.ssh/authorized_keys'
And yet, ssh and scp still ask for my password each time they interrogate workstation B. What am I missing here?
UPDATE: Thanks for the very helpful suggestions. A couple of readers pointed out:
It's very likely the permissions on your ~/.ssh directory and/or authorized_keys file on host B. They should be 700 and 600, respectively.That fixed it.
UPDATE 2: I am guessing that this is a pretty common problem, because the default setting for umask is something like 0002 or 0022, which means that the cat command above is likely to set the permissions wrong if .ssh or .ssh/authorized_keys do not already exist.
Some distributions use the file authorized_keys2. You can also check the /etc/ssh/sshd_config file to see if it's enabled.
ReplyDeleteRun with -v or -vv to get more detail, to see if an option is even being tried.
ReplyDeleteOne common initial setup problem is that your ~/.ssh or private keys are readable by group or other. OpenSSH believes in protecting you from yourself....
It's very likely the permissions on your ~/.ssh directory and/or authorized_keys file on host B. They should be 700 and 600, respectively.
ReplyDeleteUsing 'ssh-copy-id B' would setup everything correctly. But now that you've already created the directory and file, I'm not sure it will be smart enough to correct that. So on server B, do this:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
and that should fix it!
Markofafreeman: yes, this solved it! Thanks!
ReplyDeleteActually, authorized_keys in at least the OpenSSH version Debian squeeze uses doesn't have to be read protected, I've got a number of systems where they're 644 (although I'll bet changing one of those 4s to a 6 would be bad news, that would let others add to your authorized keys and then use their own private keys...).
ReplyDeletePresumably that's because they're your public keys.
(Perfect Forward Secrecy came in circa 1992 long after I got my grounding in public key cryptosystems and is something I need to learn sooner or later, so I don't know if anything might be gained by trying to keep your public key semi-private, but I suppose its possible.)
Anyway, I'm glad your in business, Clayton.
I tend to like using ssh-copy-id, which takes care of permissions and other stuff for me.
ReplyDeleteIndeed, authorized_keys does not need to have mode 600, 644 is good enough (as mentioend by hga). The problem was only in permissions of ~/.ssh itself.
ReplyDelete