Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I would like to be able to ssh into my node and then run software that for its own purposes, ssh's into other machines and itself. It assumes that ssh keys are set up already so it cannot take the -i flag and use that.

I have a working Xen setup where this works fine: all I had to do was scp my private key to .ssh/id_rsa and the public part to .ssh/id_rsa.pub (which I can recover in EC2 since it's in .ssh/authorized_keys).

This same setup simply doesn't work in EC2. I've verified that /etc/ssh/sshd_config and /etc/ssh/ssh_config are the same on my Xen box that works and the EC2 box that does not.

The base AMI I'm using is ami-1774927e, the Alestic.com image containing a fresh Ubuntu Hardy install. Naturally, port 22 is open in my security group for ssh traffic.

Any ideas on what I'm doing wrong?

EDIT: Based on womble's advise and advise on the Amazon EC2 forums, here's extra information that may be helpful:

sshd_config and ssh_config are the same on my Xen and EC2 boxes (and are the default ones shipped with the Alestic ami specified earlier), and I'm not using any command line options. ssh-agent isn't running, and there are no other ssh keys on the machine. I'm only logging in as root, and most importantly, I can log into my EC2 box from the same box if I use -i when the keyname isn't id_rsa.

When I use the -i flag, the tail end of ssh -v looks like this:

debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
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
debug1: Next authentication method: publickey
debug1: Trying private key: ec2scale.key
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Mon Jul  6 23:42:49 2009 from 127.0.0.1
Linux (none) 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:34:28 EST 2008 x86_64
... and so on ...

But when I don't use the -i flag, I get this:

debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
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
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

I've diff'ed the keys and they are identical, and I can see that the server accepts my id_rsa key above but just that the auth doesn't go through. Checking out /var/log/auth.log shows just this when I log in:

Jul  6 23:46:09 ip-10-244-50-159 sshd[1354]: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106)

Which I can use openssl to see the error code of:

root@ip:~# openssl errstr 0407006A
error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01

But I'm not sure how I can use that to help my problem.

share|improve this question

2 Answers 2

Well, without the contents of the auth logs to see what the SSH server thinks is going on, and the output of a verbose run of the SSH client, the only guess I can offer is that something is misconfigured.

EDIT: So, unless I'm misunderstanding you, you can login to the EC2 machines fine, except when you don't use the correct key?

share|improve this answer
    
Hmm, I'll have to check it out. Do you know the usual location of where the auth logs are stored? –  Chris Bunch Jul 4 '09 at 17:45
    
/var/log/auth.log by default on Debian-based systems. –  womble Jul 5 '09 at 4:50
    
Ah, thanks for the info. I've updated the post with more info based on that, and I can confirm that it happens on other Xen boxes, so it's not just an EC2 thing. –  Chris Bunch Jul 7 '09 at 3:21
up vote 1 down vote accepted

After much work on the Amazon EC2 forum, the "solution" was to simply name the key anything other than id_rsa. Since the only other keyname that could be used that would be taken automatically was id_dsa, I named the key that and it worked. This thread shows the steps taken to debug the problem, which are reproduced here in case a future reader runs into similar problems.

  • contents of /etc/ssh/sshd_config
  • contents of /etc/ssh/ssh_config
  • contents of $HOME/.ssh/authorized_keys
  • contents of $HOME/.ssh/config
  • permissions of directories and files
  • command line options you are using (e.g., -I and -A)
  • user names you are using
  • SSH_* environment variables
  • ssh-agent status and what keys have been ssh-add'ed
  • ssh -v -i $HOME/.ssh/id_rsa <REMOTE>
  • ssh -v <REMOTE>
  • strace ssh -v -i $HOME/.ssh/id_rsa <REMOTE>
  • ran sshd with the debug flag -d
  • resolved by copying id_rsa to id_dsa, ensure there is no id_dsa.pub (or it won't work)
share|improve this answer

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.