I have been trying to connect from one EC2 instance to another using ssh public keys and have been having a very tough time.
Here is the scenario: I need to have box 2 scp a file from box 1 in a script. This script will need to be able to scp without a password so I need to setup public keys.
On box 2 I ran ssh-keygen –t rsa
and generated id_rsa
and id_rsa.pub
I copied id_rsa.pub
to box 1
I moved id_rsa.pub
to .ssh and ran cat id_rsa.pug >> authorized_keys
I changed permissions of all .ssh directory to 700 on both boxes and the files themselves to 600.
I have changed the sshd_config settings on box 1 to:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
And then restarted ssh
/sbin/service sshd restart
When I try to scp or ssh into box1 from box1 I get the error:
Address 67.22.33.1 maps to ec2-67-22-33-1.compute-1.amazonaws.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
tomcat@tomcat1.****.com's password:
Any ideas?
I made that change and tried scp to tomcat1 and it failed. Here is the output:
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to tomcat1.****.com [67.22.33.15] port 22.
debug1: Connection established.
debug1: identity file /home/tomcat/.ssh/identity type -1
debug1: identity开发者_Python百科 file /home/tomcat/.ssh/id_rsa type 1
debug1: identity file /home/tomcat/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
The authenticity of host 'tomcat1.****.com (67.22.33.15)' can't be established.
RSA key fingerprint is 5a:3e:fe:be:b8:0e:05:63:bf:ab:c8:4f:e5:91:db:a0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'tomcat1.****.com,67.22.33.15' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tomcat/.ssh/identity
debug1: Offering public key: /home/tomcat/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/tomcat/.ssh/id_dsa
debug1: Next authentication method: password
Your authorized keys line should be
AuthorizedKeysFile %h/.ssh/authorized_keys
The server is looking in the wrong directory for your server.
UPDATE - FIXED IT
restorecon -R -v -d /root/.ssh
This is a known issue with RH where directories get mislabelled and PAM prevends sshd from reading authorized_hosts when run as init script. You'll see the errors if you stumble across /var/log/audit/audit.log
. Rare it seems but painful when it happens!
More details at https://bugzilla.redhat.com/show_bug.cgi?id=499343
ORIGINAL POST
I've just hit what looks like exactly this problem. I had a poorly tuned VirtualBox (I hadn't told vbox to use 64bit) -- which when I cloned and restarted (in vbox RedHat 64-bit mode), started asking me for a password.
The original image was fine -- with identical settings -- so I think the suggestion of being networking-related might be relevant, or else to do with server keys.
The weird thing however is that if on the box, I kill the sshd process which autostarted, then manually run /usr/sbin/sshd as root, I can log in passwordless fine. A silly workaround, but usable.
So it is an /etc/init.d/sshd issue. But I haven't been able to track down what it is ... have tried chucking out most of the stuff in that script but it still prompts for password when invoked as /etc/init.d/sshd start
but not when at /usr/sbin/sshd
.
Maybe these comments can help, and someone can then help further!?
Try removing box1 IP from ~/.ssh/known_hosts, so it renews. Perhaps ssh disables key authentication due to possible 'man in the middle' attack.
If it won't help, add line
GSSAPIAuthentication no
in your /etc/ssh/ssh_config file.
I think this link will solve your problem and I use it to solve my ssh not login problem. The keypoint is to run ssh root@node02 'restorecon -R -v /root/.ssh' this command will fix SE http://blog.firedaemon.com/2011/07/27/passwordless-root-ssh-public-key-authentication-on-centos-6/
After following previous steps I had to set the permission to ".." in the .ssh folder:
Once I had for ~/.ssh:
drwx------ 2 build build 4096 Nov 4 14:35 .
drwx------ 6 build build 4096 Nov 4 14:34 ..
-rw------- 1 build build 400 Nov 4 14:35 authorized_keys
It worked!
Thanks. Damian
I had the exact same problem and have been scratching my head for an entire afternoon. It turned out to be a small sshd_config file issue.
first, change access mod on .ssh folder of the remote host to user access only.
chmod 700 ~/.ssh
next, go to /etc/ssh/sshd_config, change StrictModes yes
to StrictModes no
. If it's commented out, then specifically add StrictModes no
into the file.
That solved the issue.
And one more thing I just found, I had to edit the .ssh/authorized_keys file to and make hostname fully qualified. Otherwise, I couldn't use the fully qualified name in the scp/ssh command. Now both fully qualified (like "host.company.com") & the relative name ("host") work, given that both hosts are in the "company.com" domain. ssh-keygen created the public key file with just the hostname.
精彩评论