I've created an instance of a server on EC2 based on an AMI generated from an existing server. All goes well during the create, and I specify the same key for the new server as the old. However, when I try to connect to the new server via putty, I get a "connection refused" message. Also, I'm unable to ping to the public address, although I selected the "default" group which allows ICMP. The server status is "running". Any ideas why I can't connect?
Note that an nmap probe gives this output:
PORT STATE SERVICE
22/tcp closed ssh
80/tcp closed http
2144/tcp closed unknown
10000/tcp closed snet-sensor-mgmt
I'm pretty sure this means that ssh isn't running, although the port is open. Any idea why it would be running on the system I did the AMI from, but not on the one the AMI was generated from? Shouldn't all the same services be starting?
It did turn out to be a security group/permissions issue. The default security group looks open, but actually shuts everything down, per this post:
https://serverfault.com/questions/245916/why-cant-i-ssh-or-ping-my-brand-new-amazon-ec2-instance
as you are taking the existing AMI you have to delete all the old entries from authenticated file except new entry.
because while the coping the AMI old entries are still present in new instance so once you will delete it you may able to login into the instance.
One Reason i found is entry in WLAN in current working network i.e. of my office. you may have restrictions.try contacting network admin.
alternatively you can try for adding entry to inbound rule of your current ip address.
Related
I created a SQL Server RDS Instance in AWS and it seems to be up and running, but if I try to connect to it using Management Studio I get this error:
Here is the text of the error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - The wait operation timed out.) (Microsoft SQL Server, Error: 258)
I initially tried with the default security group that was created with the instance, but when that didn't work I created a new security group and modified the instance to use it.
Here you can see the details:
I tried this connection setup to connect:
Server Type: Database Engine
Server Name: valuationdlsdev.ck1qvjqhglyg.us-west-2.rds.amazonaws.com,1433
Authentication: SQL Server Authentication
Login: the Master User Login I created when creating the RDS Instance
Password: the Master User Password I created when creating the RDS Instance
I was kinda at my wits end and so I changed the setting on the Security Group to All traffic just to see if that would work, so here are all the settings on the security group:
At this point I'm wondering if port 1433 is not open, because I feel like I've tried everything. Could someone please help me.
Thanks.
In my case I opened the VPC Security group associated with my database
In the EC2 Security groups dashboard I selected Edit Inbound Rules from the actions dropdown and chose edit inbound rules.
At first, I looked at the inbound rules and thought everything was OK since this was the current setup
After all - if it was allowing all traffic, then what could possibly be wrong?
On a whim I added a rule for TCP port 1433. Ending up with this simple setup
Then it immediately started working for me.
Make sure it is publicly accessible, there is a radio button you have to check to make it publicly accessible.
Also add MS SQL inbound rule in inbound tab.After making the change wait for sometime so that the settings are updated in the instance.
In my experience this was counter-intuitive. With the options I selected, all ports and IPs seemed to be open, but after editing the inbound and outbound rules in the security group to have MS SQL for anywhere, I was able to connect.
For inbound rules, go to the VPC Security group of your database instance
In Inbound tab click modify
In column source change ip 0.0.0.0 by your IP by "My IP" or "Anywhere"
I had the same issue.
I ended up deleting the security group inbound rules, and just added a new inbound rule for port 1433, source being: 0.0.0.0
Image attached.
inbound rules
Thanks for the discussion here. Just post my finding in case anyone needs help in the future.
I initially followed this guide https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToMicrosoftSQLServerInstance.html.
then, I got some ideas from this post and figure out my particular issue in the end. https://forums.aws.amazon.com/thread.jspa?messageID=845682 The poster really did wonderful troubleshooting steps which could help fix most of the general Error 258 problems already. In the end I used the suggestion from the answerer to find out my problem.
In terms of my case of encountering error 258, I tried to connect to RDS SQL server 2016 inside a secure network from my workplace. When I switched to use the public network served by some Telecomm vendor, the connecting was succeeded.
If you want to access from different network were the instance was created, you'll need to open access to the IP range of where you want to access, by going to the "security group" assigned to your DB instance, and then adding the rule for your IP range.
PD. AWS by default only allow access from the IP range of the machine where you activated "public access" to the instance.
I was also not able to access it from my office laptop, but I was able to access it from my personal laptop. I think it is because of some company firewall rules.
In case anyone comes across this post looking for an answer, I just wanted to updated and make sure it's there if anyone needs it. The issue here turned out to be that I misunderstood the way "Publicly Accessible" works and set it to "Yes". Apparently it should have been set to "No". "Yes", however does work for the SQL Server Express version.
I'm trying to clone an EC2 instance so that I can test some things. I created an AMI and launched an instance and it seems to be running ok. However, I cannot connect to it with ssh or putty.
My live instance, which I'm making the copy of, has various users who can all log in happily with their private key. But they cannot log in with the exact same credentials to the cloned instance. I just get:
Disconnected: No supported authentication methods available (server sent: publickey)
Is there more to do than to just change the IP address from the live instance to the cloned instance?
I also cannot connect to the ec2-user login, using the private key I created during launch. One slight quirk of my live server is that I had to change the AuthorizedKeysFile setting in /etc/ssh/sshd_config in order to deal with some SFTP problems I was having. Is this likely to have messed up the connection for a cloned server? Surely all the settings are identical?
The answer was to do with the AuthorizedKeysFile setting after all. I undid the edit I made in /etc/ssh/sshd_config, took another snapshot, made another AMI, launched another instance and all was well. I didn't even need to restart the sshd service, so this didn't mess up my configuration on my live server.
I'm not entirely sure why this caused a problem, but the lesson here is that EC2 needs the AuthorizedKeysFile to be set to the default location or I guess it doesn't know where to look for the public key.
I had a perfectly running remote redis-server on my LAN (# x.x.x.x:p). I was able to use the RedisDesktopManager to view the server contents. However, there were a lot of dangling connections to my server from different clients (subscribed to channels) which I wanted to close so I used the SHUTDOWN command from the console of the desktop manager. Since them, I am unable to connect to the remote server. The desktop manager is running and lets me add a new redis-server connection but I am not able to connect to the previous server connection. Whenever I try to connect to the server # x.x.x.x:p, the desktop manager terminates. I have not made any configuration changes to the previously running server so I am sure that I am not making any mistake with port bindings. Any help on what I am missing will be really appreciated.
Thanks in advance!
The problem was with the configuration binding. The bind line in the configuration file was originally
bind 132.168.131.129 127.0.0.1 0.0.0.0. I changed it to bind x.x.131.129. The server connection was restored.
I have an AWS instance running Apache server.
Apache is running when accessed from the local machine.
RDP connection through the elastic IP is working.
Port 80 is open for the security group
However, the elastic IP is not accessible from the browser.
Any ideas?
It could be a Security Groups is not configured to allow HTTP.
Go to http://aws.amazon.com Sign in.
Click on EC2. Then click on Security Groups. Click on the Security Group that your instance is using.
Click on Inbound tab. Click on Edit button.
In here, add you IP address (or Anywhere) for HTTP.
Unfortunately, that is not enough information for me to provide a definitive answer.
Here are some questions you can ask to help you figure out what may be wrong, however:
What happens when you run telnet 50.40.30.20 80 (where
50.40.30.20 is your EIP)?
You mention that RDP is working, is this a Windows instance (which requires port 3389 to be open for RDP)? or is it a Linux instance that requires port 22 to be open for SSH?
If Linux, is SELinux running? If so, you may find
this helpful
in disabling it temporarily or permanently to see if it has an impact on your ability to hit Apache.
RabbitMQ starts up just fine, but the shovel plugin status is listed as "starting".
I'm using the following rabbitmq.config:
Each broker is running on a separate AWS instance. The remote server is windows 2008 server, the local server is Amazon Linux.
[{rabbitmq_shovel,
[{shovels,
[{scrape_request_shovel,
[{sources, [{broker,"amqp://test_user:test_password#localhost"}]},
{destinations, [{broker, "amqp://test_user:test_password#ec2-###-##-###-###.compute-1.amazonaws.com"}]},
{queue, <<"scp_request">>},
{ack_mode, on_confirm},
{publish_properties, [{delivery_mode, 2}]},
{publish_fields, [{exchange, <<"">>},
{routing_key, <<"scp_request">>}]},
{reconnect_delay, 5}
]}
]
}]
}].
Running the following command:
sudo rabbitmqctl eval 'rabbit_shovel_status:status().'
returns:
[{scrape_request_shovel,starting,{{2012,7,11},{23,38,47}}}]
According to This question, this can result if the users haven't been set up correctly on the two brokers. However, I've double-checked that I've set up the users correctly via rabbitmqctl user_add on both machines -- have even tried it with a different set of users, to be sure.
I also ran an nmap scan of port 5672 on the remote host to verify is was up and running on that port.
UPDATE Problem isn't solved but this does appear to be a result of connection problems with the remote server. I changed "reconnect_delay" to 0 in my config file, to avoid having shovel infinitely re-try the connection. Highly recommend others with this problem do this as well, as it allows you to get error messages out of rabbit_shovel_status. In my case I got the following error:
[{scrape_request_shovel,
{terminated,
{{badmatch,{error,access_refused}},
[{rabbit_shovel_worker,make_conn_and_chan,1},
{rabbit_shovel_worker,handle_cast,2},
{gen_server2,handle_msg,2},
{proc_lib,init_p_do_apply,3}]}},
{{2012,7,12},{0,4,37}}}]
Answering my own question here, in case others encounter this issue. This error (and also a timeout error if you get it, {{badmatch,{error,etimedout}}, ), is almost certainly a communications problem between the two machines, most likely due to port access / firewall settings.
There were a couple of dumb things I was doing here:
1) Was using the wrong DNS for my remote EC2 instance (D'oh! really dumb -- can't tell you how long I spent banging my head against the wall on this one...). Remember that stopping and starting your instance generates a new DNS, if you don't have an elastic IP associated with the instance.
2) My remote instance is a windows server, and I realized you have to open up port 5672 both in windows firewall and in EC2 security groups -- there are two overlapping levels of access controls here, and opening up the port in the EC2 management console isn't sufficient if your machine is windows server on EC2, as you also have to configure the windows server firewall.