[02:44] <Bummed> got a ubuntu slice  on Amazon EC2 .. as well as other Centos slices
[02:44] <flaccid> for real
[02:44] <Bummed> I can ssh between slices
[02:44] <flaccid> i believe they are called instances
[02:45] <Bummed> I can ssh using the same key from my laptop  to  Centos ..  but it fails going to the ubuntu instance
[02:45] <flaccid> check the ssh configuration
[02:45] <Bummed> falls all the way back to asking for a password
[02:45] <flaccid> you can debug with ssh -v on the client and /etc/init.d/ssh restart debug
[02:48] <Bummed>   /etc/init.d/ssh restart debug  fails with extra argument
[02:48] <flaccid> let me check, that was a guess
[02:50] <flaccid> use /etc/init.d/ssh restart -d
[02:51] <flaccid> see also man sshd
[02:52] <Bummed> laptop runs completely through  connection attempt and doesn't log anything on the server.. which probably means my existing connection is holding the port open
[02:53] <flaccid> sounds like you need to reach the instance properly first
[02:54] <Bummed> the only way to currently get there is  laptop -> centos instance -> ubunut instance
[02:54] <flaccid> basic networking troubleshooting. tracert, nmap, ping, telnet etc.
[02:55] <flaccid> err traceroute. been watching nextgenhacker101 too much hehe
[02:57] <flaccid> oh and obviously ec2 security groups
[02:58] <Bummed> nothing  at Amazon returns info to traceroute
[02:59] <flaccid> i think thats normal for most routes
[03:01] <Bummed> have the security group set to allow port 22
[03:04] <Bummed> what is driving me nuts is that  instance to instance works with the same key that doesn't work from laptop to ubuntu instance
[03:06] <flaccid> check ssh configuration
[03:06] <flaccid> but thats no good if you aint even hitting the sshd
[03:06] <Bummed> I've gone so far as copy the Centos  sshd_config to the Ubuntu instance .. same results
[03:09] <flaccid> if its not coming up in sshd -d then its not reaching it
[03:13] <Bummed> true.. but then where is all the debug output  coming from
[03:14] <flaccid> sshd
[03:15] <Bummed> yes.. but where am I connecting to sshd if -d doesn't provide any details  .. that is the question
[03:16] <flaccid> um see your network admin heh. traceroute could get some hops at least
[03:16] <flaccid> though if this ec2 internal, problem could be security groups or network issue
[03:22] <Bummed> nmap  shows port 22 open on my ip ?
[03:22] <Bummed> nmap  shows port 22 open on my ip
[03:23] <flaccid> if you telnet to it and the port stays open and nothing on sshd end then yeah its reaching a different host
[03:24] <Bummed> sshd is answering my  telnet
[03:25] <Bummed> shows right hostname and IP
[03:32] <flaccid> ok then troubleshoot the handshake
[03:33] <Bummed> debug1: Host is known and matches the RSA host key.
[03:33] <Bummed> debug1: ssh_rsa_verify: signature correct
[03:33] <flaccid> right thats the host key
[03:34] <Bummed> then it falls through to asking for a password
[03:34] <flaccid> it will give more details than that
[03:34] <flaccid> it should try keys
[03:38] <Bummed> got a favorite pastebin ?
[03:38] <flaccid> dpaste.org
[03:40] <Bummed> http://www.dpaste.org/QW5g/
[03:43] <Bummed> http://www.dpaste.org/UOwd/   << better pasted.. fumbled fingered the original
[03:43] <flaccid> check the auth/secure logs. problem could be debug2: key_type_from_name: unknown key type '-----BEGIN'
[03:43] <flaccid> i don't really have time to look into it properly. someone else here might
[03:44] <Bummed> no problem .. I've been beating my head against the wall for the last week .. so I'm just out of ideas
[03:44] <Bummed> I believe that is the check for rsa1 key
[12:49] <superxgl> [root@CLC cloud]# euca-run-instances -n 1 -k mykey -t m1.small emi-CD7E14B8
[12:49] <superxgl> FinishedVerify: Not enough resources (0 < 1: vm instances.Not enough resources (0 < 1: vm instances.
[12:50] <superxgl> hiiiiiiiii,all ,what 's the problem that i can not run instances ????
[12:50] <superxgl> AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
[12:50] <superxgl> AVAILABILITYZONE        |- m1.small     0002 / 0002   1    256     2
[12:50] <superxgl> AVAILABILITYZONE        |- c1.medium    0002 / 0002   1    256     5
[12:50] <superxgl> AVAILABILITYZONE        |- m1.large     0001 / 0001   2    512    10
[12:50] <superxgl> AVAILABILITYZONE        |- m1.xlarge    0001 / 0001   2   1024    20
[12:50] <superxgl> AVAILABILITYZONE        |- c1.xlarge    0000 / 0000   4   2048    20
[12:51] <superxgl> but " euca-describe-availability-zones verbose" shows that i should can run m1.small
[14:03] <TeTeT> superxgl: did you check the nc.log on the node controller when trying to start an instance? Maybe libvirt-bin has not properly started/not properly connected to the nc
[14:18] <superxgl> TeTeT : i  found the problem., becuase i set the dom0_MEM= 350M , so it did not have enough memory to start i think,  after i removed the line dom0_MEM=350M , then i can start the instance now
[14:19] <superxgl> but i don't know i should not limit the dom0's memory ?
[14:48] <superxgl> also now i get into another problem , i use "SYSTEM" network mode, when i start an instance, it did get an ip address, but when i start the second instance, it can not get the ip address , what 's  the problem???
[14:51] <TeTeT> superxgl: no idea, I doubt anyone tests UEC with SYSTEM mode
[14:57] <superxgl> why?
[14:57] <superxgl> hmm...
[14:58] <superxgl> but i now use CentOS 5.5 + euca 2.0
[15:05] <superxgl> and both two instance used the same image
[15:06] <Bummed> any thoughts on why an Amazon EC2 instance of Ubuntu 10.10  will not accept  a keyed ssh connection from outside of the Amazon cloud ?
[18:58] <smoser> Bummed, i suspect your security groups
[18:59] <Bummed> I have  22 open for tcp in the security group .. what else might I need?
[20:10] <mhall119> Bummed: did you give it a subnet to accept connections on 22 from?
[20:11] <Bummed> 0.0.0.0
[20:11] <mhall119> Bummed: you gave it a public key?
[20:11] <Bummed> works from other instances in the Amazon cloud .. just not from outside aka my laptop
[20:11] <Bummed> yes
[20:11] <Bummed> several ..
[20:11] <mhall119> hmmm...
[20:12] <mhall119> is openssh-server maybe just binding to the internal IP, not the external?
[20:12] <Bummed> everytime I start debugging.. whomever I'm talking with says "create a new key"
[20:12] <Bummed> hmm.. let me go check
[20:12] <Bummed> hadn't thought about that possibility
[20:13] <Bummed> tcp        0      0 *:ssh                   *:*                     LISTEN
[20:13] <Bummed> from netstat -a
[20:13] <mhall119> hmmm
[20:13] <mhall119> are you using elastic ip or some form of load balancing?
[20:14] <mhall119> connecting as a different username from your laptop than you are from the other amazon instances?
[20:14] <Bummed> intersting that my origination is from the private ip of the instance I'm passing through to the public ip of the target
[20:14] <Bummed> elastic ips
[20:15] <Bummed> same user names and keys .. regardless of point of origin
[20:15] <mhall119> okay, I'm not familiar with them, can you watch the logs and see if it's even seeing you try to connect?
[20:16] <mhall119> you can also try connecting to the public hostname instead of the elastic ip
[20:16] <Bummed> with sshd_config set to DEBUG3 ..   I see nothing in the auth.log file and ssh -vv shows it finding  the appropriate key, but then falling down to asking for a password which is disabled
[20:17] <mhall119> huh
[20:18] <mhall119> it sounds like your ssh client isn't actually talking to that server
[20:18] <Bummed> give me a moment to look up my amazon ip
[20:18] <mhall119> which raises the question, what is it talking to?
[20:18] <Bummed> the ssh -vv log shows it is pointing at the right elastic ip
[20:20] <Bummed> kewl.. progress..  it works correctly the the public amazon ip.. just not to the elastic ip
[20:20] <Bummed> now the question is what does that tell me
[20:21] <mhall119> that the elastic IP isn't pointing to the right box?
[20:22] <Bummed> nope .. according to elasticfox   instance details ..  both the public dns name and the Elastic IP point to the same ip
[20:23] <Bummed> time to dig the public dns name
[20:23] <mhall119> and that 'same ip' you can ssh into directly?
[20:23] <Bummed> correct ..
[20:24] <Bummed> so what you have helped me figure out . is   ssh to public dns name works ... ssh to elastic ip  fails .. both point to the same ip
[20:24] <mhall119> maybe you have some old DNS cache?
[20:26] <Bummed> well. my cache on my laptop is correct,  which implies the at least OpenDNS has the right info
[20:26]  * mhall119 is running out of ideas
[20:27] <mhall119> I'm guessing it's something to do with elastic ip, but I've never used them, and I'm not even really sure what they are/what they do
[20:27] <Bummed> that's where I've been for the last week  .. but know that the public dns works will allow my team to get back to work as temporary work around
[20:28] <Bummed> basically, from what I can tell,  it lets you masquerade as an alternative host name .. instead of ec2-<IP>.compute-1.amazonaws.com   you can be  your.company.com
[20:29] <Bummed> and that can be on any instance in the amazon cloud.. the ip moves with you
[20:29] <mhall119> ok
[20:30] <mhall119> does the elastic ip get different firewall settings maybe?
[20:31]  * mhall119 is just guessing now
[20:35] <Bummed> the real kicker is why will it work to  as it to Centos instance, but fail to my Ubuntu instance
[20:37] <mhall119> if you're not seeing the login attempts to sshd when connecting to the elastic ip, it's not even getting to the OS
[20:37] <mhall119> it's got to be a configuration issue in AWS
[20:39] <Bummed> but who or what is answering  ssh ?
[20:41] <Bummed> if I can figure that out .. then maybe I can figure out why things are so squirelly
[20:57] <jmgalloway> anyone know why I get a connection closed error when I try to ssh into an instance?
[20:57] <Bummed> firewall blocking
[20:58] <jmgalloway> firewall?
[20:58] <jmgalloway> I am using a security group when I start the vm...and open port 22, still doesnt work
[20:58] <Bummed> is sshd running ?
[20:59] <jmgalloway> on the vm?
[20:59] <Bummed> on the target
[20:59] <jmgalloway> I am just running the 10.04 desktop image that came with uec
[21:00] <Bummed> check that sshd is running .. check that you have reasonable rules in iptables
[21:00] <jmgalloway> check that sshd is running where?
[21:01] <Bummed> uec instance
[21:01] <jmgalloway> how?
[21:01] <Bummed> how did you start the instance?
[21:02] <jmgalloway> on a remote machine
[21:02] <jmgalloway> using euca2ools..a linux remote desktop.  I see that it's running, but cant connect to it.
[21:03] <Bummed> ok. .. I do everything with elasticfox... don't know much about euca2ools... does it offer a login action ?
[21:04] <jmgalloway> no, it just says running.
[21:05] <Bummed> ok.. beyond my ability to help