Has anyone encountered the NLA error after changing instance type for an EC2 instance?
Getting this error after upgrading a domain joined instance (t3.2xlarge) to the recommended instance type according to Computer Optimizer (m6i.2xlarge).
Cannot RDP using the local administrator account either, same NLA error.
Also made a re:post question but no answer yet.
Kind regards,
Ken
Things I have tried:
Changing back to t3.2xlarge, connected using domain credentials OK
Changing to m5.2xlarge, connected using domain crendentials OK
Added another NIC when it was on m6i.2xlarge, NLA error on the second interface.
(Don't think this matters, the instance is HVM) Upgraded to the latest PV driver, changing instance type to m6i.2xlarge, NLA error.
Launched a m6i.2xlarge instance in a different subnet(AZ), joined domain OK, connected using domain crendentials OK; changed to t3.2xlarge, NLA error; changed back to m6i.2xlarge, connected using domain crendentials OK
Launched another m6i.2xlarge instance in the same subnet as the t3.2xlarge, swapped the root volume, NLA error. Swapped back the volumes, connected OK.
All these tests leads me to think there is incompatibility b/w gen 5 Xeon processors and gen 6, which is strange, I thought at first it was a network card issue.
Copy pasted from my own answer on RE:POST
Managed to isolate the cause after performing some rescuing via SSM.
The issue seems to stem from the upgrade from the CPU generation leap.
I had always thought each component, Storage, Compute, and Networking are separate, but the ENI config was lost during the upgrade, so the server had trouble (i.e. did not know where the DNS server is) contacting the DCs for authentication.
Without this link to the DCs, NLA will never be met.
So if you are going to upgrade to the latest generation.
While on the current instance type (while you can RDP to the EC2 instance), navigate to System Properties and go to the Remote tab.
Untick the NLA option and apply and save the change.
Shutdown the instance and change to the desired instance type.
RDP to the instance using the Administrator account.
Here you will see that the network interface configuration is empty, so add your DNS server IP address back in here.
Confirm you have a connection to the DCs by pinging or something of the sort, then repeat step 1, but this time enable the NLA option and save.
Reboot and Voilà, you should now have access to the EC2 instance using your domain logins again.
Related
First up it's nearly impossible to identify if this is a duplicate or not given the generic nature of the displayed error. This is potentially a very specific and niche scenario. Please do not falsely mark this as duplicate. It's sad that I have to type this :(
I have 2 ec2 ubuntu instances. The first one created 6 months ago and working perfectly.
I created a second ubuntu instance this morning and told it to use the same keypair as the existing instance. They're in the same zones(?) but different base vpc. I selected it from the list so I presume it should be visible to both vpc's. From what I could see that should be ok.
Both are ubuntu so the user is "ubuntu". Both are using the same key pair. I merely cloned my saved putty config and changed the public IP before attempting to connect however i'm getting the "PuTTY Fatal Error: Disconnected: No supported authentication methods available (server sent: publickey) OK: error.
Unless i'm mistaken the same .ppk should work for both instances, that's the entire purpose of keypairs. The only thing I can presume is that AWS failed to associate the key pair with the new instance.
What are the likely reasons for this happening?
AWS documentation https://aws.amazon.com/premiumsupport/knowledge-center/linux-credentials-error/
Says to check the username "ubuntu" and key pair name which are both correct.
I'm going to blow the instance away and start again but it would be nice to be able to know what AWS is doing wrong so I can avoid the issue in the future.
Update: New instance... I imported a different pub key and used that and the problem persists when I try and connect with it's associated ppk.
The issue was the AWS Amazon Machine Image (AMI) I was using. I was using the latest ubuntu??. When I switched to the other ubuntu it worked fine.
One of my EC2 instances was hacked a few days ago.
I tried logging in via SSH to the server, but I couldn't connect. I am the only one with access to the private key, and I keep it in a safe place.
Luckily, I had a backup of everything and was able to move the web app to a new instance quite fast.
My concern right now is that I don't know how my instance was hacked in the first place.
Why can't I log in via SSH using my private key? I would assume that the private key stored on the server can't be (easily) deleted.
Is there a way I can find out how the hacker gained access to the instance? Perhaps a log file that would point me in the right direction.
Should I attach the EBS volume in question to a new instance and see what's on it or what are my options in this case?
Right now, it seems I have to access at all to the hacked instance.
Thank you!
#Krishna Kumar R is correct about the hacker probably changing the ssh keys.
Next steps:
Security concerns (do these now!):
Stop the instance, but don't terminate yet
Revoke/expire any sensitive credentials that were stored on the instance, including passwords and keys for other sites and services. Everything stored on that instance should be considered compromised.
Post-mortem
Take an EBS snapshot of the instance's root volume (assuming that's where logs are stored)
Make a new volume from the snapshot and attach to a (non-production) instance
Mount and start reading logs. If this is a linux host and you have port 22 open in the firewall, I'd start with /<mount-point>/var/log/auth.log
They might have logged into your machine via password. In ssh config, check the value of: PasswordAuthentication. If it is set to yes, then users can login to the instance remotely via password. Check /var/log/secure for any remote logins. It will show up all logins (password or key based).
If someone logged in as 'root', they can modify the ssh keys.
The fact that you are unable to login to the machine does not mean that it has been "hacked". It could be due to a configuration change on the instance, or the instance might have changed IP address after a stop/start.
Do a search on StackOverflow for standard solutions to problems connecting to an instance and see if you can connect (eg recheck IP address, check security group, turn on ssh -v debugging, check network connectivity & VPC settings, view Get System Log, etc).
Worst case, yes, you could:
Stop the instance
Detach the EBS volume
Attach the EBS volume to another EC2 instance
Access the content of the EBS volume
We have a series of Amazon Web Services servers running Amazon Linux and Oracle XE, which is used by a local app. OracleXE installs and runs just fine, our app can connect to the DB, everything is great.
For one of our particular servers, we needed to shut it down and archive it. Today, I need to bring it online. This is done by setting up a new AWS instance, creating a new virtual hard drive from backup snapshot, setting up a new public IP for the server and changing DNS settings to that the old domain points to the new IP, connecting up the restored virtual drive as the main drive, and starting it up.
OracleXE doesn't want to work. Using sqlplus to connector to localhost:1521/XE produces "ORA-12514: TNS:listener does not currently know of service requested in connect descriptor".
This system was working just fine when I snapshotted it and archived it the first time, and I hadn't changed any settings since restoring it. Everything should be exactly the same, so why is OracleXE now not working?
The listener.ora and tnsnames.ora had the host defined using the server's public domain name. I tried changing that to localhost, but it's still not working.
The only things I can think of that will be different are the server's public IP address, and the "rsa2 key fingerprint" (what Putty complains about due to the SSH key being the same but it being a new AWS instance). All the advice I've seen so far is for fixing config errors for ORA-12514 when setting up a new system or after restarting, but this is a system that was working fine but has been restored from snapshot.
Most likely, your listener uses dynamic instance registration.
For that to work, your listener must be listening to the default port (1521) or your instance must use the local listener parameter that defines the address of the listener where the instance should register it's existence.
So, check your local_listener parameter, check the servers tnsnames.ora and listener.ora. Also check your clients tnsnames.ora, it should point to your new server and listener.
I'm working with marklogic database and I tried to create a cluster.
I already have a development key. The OS is the same in all the nodes (win 7 x64).
When you tried to add a node into the cluster, you need to type the host name or the IP adress. For some reason when I type de host name, marklogic sometimes can't find the node , but that doesn't matter, because with the IP, the connection is successfull.
The main problem is when continues trought the process. At the end when marklogic try to transfer cluster configuration information to the new host, the process never ends and finally a message like "No data received" appear in the web browser.
I know that this message doesnt mean that the process fails, because when I change for example the host name, the same message appear.
So, when I check the summary in the first node, the second node appears, so that means the node "joins" into the cluster, but I'm not able to start the admin interface and always the second node appears disconnected even if I restart the service.
Aditionally, I'm able to make a ping from any computer to another.
I tried to create another network, because in my school some ports are not allowed, furthermore I tried to use different development key and the same key in my nodes too,
and finally I already have all the services enabled, but the problem persist.
Any help or comments would be appreciated.
Make sure ports 7998 - 8003 are open on both computers for both inbound and outbound traffic and that you don't have a firewall (Windows firewall, or iptables) blocking these.
You can also start looking into the Logs/ErrorLog.txt file and see if something obvious shows up.
Stick to IP addresses for now as it seems your DNS isn't fully working.
Your error looks like a kind of networking connectivity problem between the hosts.
Also you might get more detailed, or atleast different, answers from the MarkLogic developer mailing list.
http://developer.marklogic.com/discuss
-David Lee
Make sure the host names in MarkLogic configuration match the DNS names at which the hosts can see each other. If those are unreliable, then simply use IP addresses as host names. Go to the Admin interface on both ends, lookup the host name, change the DNS name into IP name, try again.
Also look at DALDEI's suggestion about ports and firewalls, that could be interfering as well.
HTH!
I just set up eduroam on my laptop and this morning when I fired up my terminal, I noticed that my hostname has been changed most probably by the eduroam set up to a new value. Any ideas why or how this happens?
You're going to get a new hostname every time you join a new network (at least potentially). The hostname identifies the computer and is therefore assigned by the network that you connect to. This usually happens as part of DHCP, where you get an IP address and routing information.
This is perfectly normal and nothing to worry about. If you absolutely need a certain hostname, talk to the network administrators.