You try to connect via SSH to a newly created Amazon EC2 instance and get one of the following error
messages:
“Network error: Connection timed out” or “Error connecting to [instance], reason: -> Connection
timed out: connect,”
You have confirmed that the network and security group rules are configured correctly and the instance is
passing status checks. What steps should you take to identify the source of the behavior? Choose 2 answers
A.
Verify that the private key file corresponds to the Amazon EC2 key pair assigned at launch.
B.
Verify that your IAM user policy has permission to launch Amazon EC2 instances.
C.
Verify that you are connecting with the appropriate user name for your AMI.
D.
Verify that the Amazon EC2 Instance was launched with the proper IAM role.
E.
Verify that your federation trust to AWS has been established.
Explanation:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
A and C
0
0
ac
0
0
AC
0
0
C is not correct answer. IMOH is D
Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
If you connect to your instance using SSH and get any of the following errors, Host key not found in [directory], Permission denied (publickey), or Authentication failed, permission denied, verify that you are connecting with the appropriate user name for your AMI and that you have specified the proper private key (.pem) file for your instance. For MindTerm clients, enter the user name in the User name box in the Connect To Your Instance window.
0
0
Sivakamur,
I cant see any indication anywhere why d will be right. In order to connect to instance IAM roles while creating instance is not necessary. IAM role while creating the instance is used if your instance needs to interact with other aws services.
and you are absolutely right about C as well. In that case i consider there is no second answer.
However
Error connecting to your instance: Connection timed out
If you try to connect to your instance and get an error message Network error: Connection timed out or Error connecting to [instance], reason: -> Connection timed out: connect, try the following:
Check your security group rules. You need a security group rule that allows inbound traffic from your public IP address on the proper port.
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the navigation pane, choose Instances, and then select your instance.
In the Description tab, next to Security groups, choose view rules to display the list of rules that are in effect.
For Linux instances: Verify that there is a rule that allows traffic from your computer to port 22 (SSH).
For Windows instances: Verify that there is a rule that allows traffic from your computer to port 3389 (RDP).
If your security group has a rule that allows inbound traffic from a single IP address, this address may not be static if your computer is on a corporate network or if you are connecting through an Internet service provider (ISP). Instead, specify the range of IP addresses used by client computers. If your security group does not have a rule that allows inbound traffic as described in the previous step, add a rule to your security group. For more information, see Authorizing Network Access to Your Instances.
[EC2-VPC] Check the route table for the subnet. You need a route that sends all traffic destined outside the VPC (0.0.0.0/0) to the Internet gateway for the VPC.
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the Description tab, write down the values of VPC ID and Subnet ID.
Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Internet Gateways. Verify that there is an Internet gateway attached to your VPC. Otherwise, choose Create Internet Gateway and follow the directions to create an Internet gateway, select the Internet gateway, and then choose Attach to VPC and follow the directions to attach it to your VPC.
In the navigation pane, choose Subnets, and then select your subnet.
On the Route Table tab, verify that there is a route with 0.0.0.0/0 as the destination and the Internet gateway for your VPC as the target. Otherwise, choose the ID of the route table (rtb-xxxxxxxx) to navigate to the Routes tab for the route table, choose Edit, Add another route, enter 0.0.0.0/0 in Destination, select your Internet gateway from Target, and then choose Save.
[EC2-VPC] Check the network access control list (ACL) for the subnet. The network ACLs must allow inbound and outbound traffic from your public IP address on the proper port. The default network ACL allows all inbound and outbound traffic.
Open the Amazon VPC console at https://console.aws.amazon.com/vpc/.
In the navigation pane, choose Your VPCs.
On the Summary tab, find Network ACL, choose the ID (acl-xxxxxxxx), and select the ACL.
On the Inbound Rules tab, verify that the rules allow traffic from your computer. Otherwise, delete or modify the rule that is blocking traffic from your computer.
On the Outbound Rules tab, verify that the rules allow traffic to your computer. Otherwise, delete or modify the rule that is blocking traffic to your computer.
If your computer is on a corporate network, ask your network administrator whether the internal firewall allows inbound and outbound traffic from your computer on port 22 (for Linux instances) or port 3389 (for Windows instances).
If you have a firewall on your computer, verify that it allows inbound and outbound traffic from your computer on port 22 (for Linux instances) or port 3389 (for Windows instances).
Check that your instance has a public IP address. If not, you can associate an Elastic IP address with your instance. For more information, see Elastic IP Addresses.
Check the CPU load on your instance; the server may be overloaded. AWS automatically provides data such as Amazon CloudWatch metrics and instance status, which you can use to see how much CPU load is on your instance and, if necessary, adjust how your loads are handled. For more information, see Monitoring Your Instances Using CloudWatch.
If your load is variable, you can automatically scale your instances up or down using Auto Scaling and Elastic Load Balancing.
If your load is steadily growing, you can move to a larger instance type. For more information, see Resizing Your Instance.
0
0
Thank you fun4two!
I agree with you Also, i doubt on A as it will throw permission error like connection refused if we are not using proper private key (.pem) file for your instance.
0
0
B and E
Here goes my somewhat meaningful theory
Just open your putty type a random IP and click open, You will get the error mentioned in the question “Network error: Connection timed out” think carefully this is not a permission denied error or wrong user related error so A and C are wrong answers.
why u get above error is when that instance itself doesn’t exist or not launched properly.
Answer D is wrong IAM role is nothing to do with launching or connecting an instance(Tell me if i am wrong).
so the user got wrong policy given to him which caused to failure of the instance launch properly.
But if the user is a federated user may be some trust related permission should be given to launch instance properly not sure on this.
since i eliminated A,C,D i am choosing B and E.
If anybody still think A and C are right, Can u explain it with ur theory that how u will get Network error: Connection timed out” error by using wrong key\user.
0
0
None of the available answers is correct for the scenario.
You can find this exact scenario in the AWS user guide and none of the answers listed are among the recommended troubleshooting steps: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectionTimeout
However, the available responses do match the troubleshooting steps for a completely different scenario further down in that same document: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm
I think that whoever created this question got mixed up halfway through and combined the description of the “Connection timed out” scenario with the troubleshooting steps from the “Host key not found” scenario.
1
0
Perfectly Explained … 5 Star Answer *****
0
0
I agree, this question doesn’t make sense.
It talks about connection and no authentication.
When You try to connect with the wrong KEY for example, You can connect but can’t authenticate.
0
0
Yup, agreed.
0
0
precisely mate
0
0
B and D
I agree with LazyGuy,A and C are wrong answers.
Source: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
if A and C, there will be other error message, like “Error: User key not recognized by server”, “Error: Host key not found, Permission denied (publickey), or Authentication failed, permission denied” etc.
E. federation trust to AWS is not needed.
0
0
You can restrict the IP address by using the IAM role, so ssh will fail if ssh client is not in the permitted IP address.
0
0
Since its a network timeout and the network configuration is in place, it can only mean the instance isnt running.
So B and D
0
0
AC
0
0
AC
IAM role used to communicate with other AWS service like s3 when it is up and running, the problem is Network error so it may be related to key pair or IMG user (ubuntu, root and ec2)
0
0
Here , options are incorrect.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html
0
0
This question should be deleted.
0
0
I agree!
0
0
this is network timeout and permissions are set correctly so
B – instance is not started so timeout
D – role used to by the instance is preventing you to ssh
I go for B and D
0
0
A and C are the right answers as they are the only ones that have to do with SSH access even if the error messages are not exactly what you’ll get.
B is wrong since the questions says that instance is passing status check so it must have already started.
D is wrong since AIM role has to deal with EC2 instance’s access to AWS services but not to SSH access to the instance itself.
E is wrong since federation allows you to access AWS services but not login into EC2 instance.
1
0
You meant to say IAM role, not AMI role, at point D.
0
0
A and C are correct. If you read the question carefully, the user is trying to SSH to the EC2 instance. The only parameters involved in trying to connect via SSH are : the private key, user, IP address and SSH port 22. From the options, only User and private key are correct.
0
0
Having the wrong private will never time out your connection. But having the improper IAM role will.
0
0
meant Private Key
0
0
Timeout is always connected to blocking on a firewall,so it must be a security group or network ACL.If private key is wrong , there should be this response:
[root@ip-10-0-1-32 ec2-user]# ssh -i vpc2.pem ec2-user@10.0.2.12
Permission denied (publickey).
I think somebody making this question messed the response.
0
0
just done the exam, scored 100% on this part.
it is and A and C, although it does not make sense.
The only reason it does make sense (according to amazons logic) is:
– the text says the EC2 instance was created (thus no permission/iam/role problems)
– security/acl checked (thus no problems with the network)
only options left are those above, although the “connection timed out’ makes no sense at all.
So for you exam, just learn it as this: AC
0
0
Thanks
0
0
I got this question in my Exam I answered it as A&D. But after visiting this page the ans seems to be AC
0
0
Verify that the private key file corresponds to the Amazon EC2 key pair assigned at launch.
Verify that your IAM user policy has permission to launch Amazon EC2 instances. (there is not need for a IAM user and just need ssh keys)
Verify that you are connecting with the appropriate user name for your AMI. (Although it gives different error seems the only other logical choice)
Verify that the Amazon EC2 Instance was launched with the proper IAM role. (role assigned to EC2 is irrelevant for ssh and only controls what AWS resources EC2 can access to)
Verify that your federation trust to AWS has been established (federation is for authenticating the user)
0
0
explanation for C:
Verify that you are connecting with the appropriate user name for your AMI. Enter the user name in the Host name box in the PuTTY Configuration window.
For an Amazon Linux AMI, the user name is ec2-user.
For a RHEL AMI, the user name is ec2-user or root.
For an Ubuntu AMI, the user name is ubuntu or root.
For a Centos AMI, the user name is centos.
For a Fedora AMI, the user name is ec2-user.
For SUSE, the user name is ec2-user or root.
Otherwise, if ec2-user and root don’t work, check with the AMI provider.
0
0
A and C are the right answers
0
0
Amazon Route 53 also supports alias resource record sets, which allow you to route queries to a CloudFront distribution, an Elastic Beanstalk environment, an ELB Classic or Application Load Balancer, an Amazon S3 bucket that is configured as a static website, or another Amazon Route 53 resource record set. Aliases are similar in some ways to the CNAME resource record type; however, you can create an alias for the zone apex. For more information, see Choosing Between Alias and Non-Alias Resource Record Sets.
0
0
The question shall be “Error: User key not recognized by server”, then A and C is correct answer.
Check this page with this error message section:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectionTimeout
Error: User key not recognized by server
If you use SSH to connect to your instance
0
0
this doesn’t make sense at all. Connection timed out wrong username or key is something complete different. Technicaly you get “the server refused our key” when you use a wrong key or username
For A (wrong key):
login as: ubuntu
Server refused our key
For C (wrong username):
login as: ubunta
Server refused our key
0
0