Any idea if it is possible to set password for the GRUB bootloader? If set then how it is possible to enter password? What happen when auto scale without human entering password?
AWS does not provide "console access" to EC2 instances, so you can set a GRUB password the usual way, but you will not be able to enter it at boot. Your instance will become inaccessible after reboot.
If you absolutely need GRUB password (but why?) the only option is to look at other providers that allow use console (DigitalOcean, for example).
Setting a bootloader password prevents the command line boot parameters from being changed without the user providing the bootloader password. Booting the system in single user mode would therefore require the bootloader password, as single user mode requires modification of the boot entries.
You can add --unrestricted to the menu entries to allow the system to boot without
entering a password. This does away with the need to enter the bootloader password when rebooting systems (or launching new EC2 instances through an Auto Scaling Group and your custom AMI). Password will still be required to edit menu items. This primarily protects against AWS staff who may be able to get access to instance boot disks on EBS.
Related
Im a newb to AWS, so please go easy on me. We currently just spun up a custom Windows 10 instance in AWS. I was able to login via RDP successfully, but I'd like to create a new user within the instance so they can login with a different user account using RDP. Any thoughts would be much appreciated.
Okay, After your response to my first, I think I see what you are asking. Plase watch this video:
https://www.youtube.com/watch?v=rgk2w3dQGSo
Download the RDP. Save it. You can then Edit the .rdp and enter the user name and password you created in Windows.
You can create users in the User Management Console in Windows. Ensure they have the rights needed (Remote Desktop User, Administrator, etc).
Enjoy!
Once an Amazon EC2 Windows instance has been launched, it is just a normal Windows computer.
Therefore, you should use use the standard Admin tools to create the user on the Windows computer, with their own username and password.
It is also recommended that you change the random Administrator password after initial login, or (even better) connect the instance to Active Directory or whatever standard authentication system your company uses.
Technoob here. I just figured out why all of you are having trouble. You need to go to the security group the machine is a part of and open port 3389 to your public IP address (ipchicken.com works). Enjoy
If you are trying to connect from another computer then you have to change the inbound rules.
Go to the security groups of your instance. Go to the inbound rules. Add ipv4 and ipv6 as a new rule and apply it. Download the RDP File and try to connect again. It worked for me.
I'm new to AWS EC2 and I'm trying to access to a windows instance (it's an image created from another instance),
But when I click on Get password in RDP section, i got this message:
The instance was running since yesterday so why I still have this message? is this something related to missing configuration?
Thanks for your help!
Check the console output for the instance to see whether the AMI that you used to launch it was created with password generation disabled. If password generation is disabled, the console output contains the following:
Ec2SetPassword: Disabled
If password generation is disabled and you don't remember the password for the original instance, you can reset the password for this instance. For more information, see .Reset a lost or expired Windows administrator password
My secretary created a new instance in Amazon using their EC2 server but lost the .pem file. Doing research online I was able to go to the instance system settings/get system log and retrieve some type of password there. The instance system log shows something like this:
2019/04/15 12:15:19Z: Username: Username
2019/04/15 12:15:19Z: Password: <Password>
It is a very long code of random characters.
Is there any way I can use this to log in via remote desktop or is there a way to decrypt it? I tried several decryption methods online and they said this was not a valid "hash"...whatever this means. I am not a technical person so I need hopefully a response in layman terms.
It appears that you are connecting to a Windows instance. When a new Amazon EC2 Windows instance is launched, a program on the AMI (disk image) automatically generates a random Administrator password. This is done so that you can access the instance, but nobody else can.
To keep the password secret, the program encrypts the password with the keypair nominated when the instance was launched. The encrypted password is passed back to AWS via the console. That is the string of 'random characters' you saw.
To decrypt the password, you can use the Get Windows Password feature, which requires you to supply the nominated keypair. It will then decrypt the password, which can be used to login to the instance as Administrator.
Since you no longer have the keypair, you cannot decrypt the password and therefore cannot login to the server. This is good! This proves that security works, because you would not want other people to be able to login to the server.
So, can do you regain access?
Refer to the steps on: I need to reset the administrator password on a Windows Server instance in Amazon EC2
Basically, there are two methods:
If Systems Manager is enabled for the instance, you can run a "rescue" script
Otherwise, there is a series of scripts that assist with the process of:
Detaching the disk
Attaching it to another instance
Resetting a configuration on the disk
Reattaching the disk to the original instance
The second process is a bit like plugging a USB disk into another computer to change a file (except that EC2 disks are managed differently).
I have a running Windows server image on EC2.
I created an additional administrator login and have been using it login using RDP. Unfortunately I've lost the PEM file for the "Administrator" account and I've also disabled it for "safety"
Since I have access to the instance through an alternative administrative account I'm trying to figure out a few things:
Do need the "Administator" account PEM file in future?
If I get Amazon to generate a new PEM file using the same name that I currently have, how do I replace the "Administrator" key pair for the instance?
I've searched all over and can't find an answer on how to replace the key pair or add an additional key pair to a running "Windows" instance
Everything talks about shutting down and creating an new instance. I cannot shut down this server, so that must be a way to replace the key pair for the "Administrator" account.
I can't even find where Windows stores the key pair in a Windows server.
When an instance is first launched from one of the Amazon-supplied Windows AMIs, some code on the instance generates a random Administrator password. This password is then encrypted with the selected Keypair and passed back to AWS (you can actually see it in the System Log).
When you wish to first login to the instance, you will need to use the PEM to decrypt the Administrator password. You can then login to the Windows instance using that password.
It is recommended that you immediately change the Administrator password or connect the instance to Active Directory -- basically, follow your standard company security practices.
If you remember the password, you will not require the PEM file again. In fact, if you change the password, then even having the PEM will not facilitate access because it will only decrypt the original password, not the current password.
Bottom line: Ignore the PEM file. You still have administrative access to the instance, so you don't even need the Administrator account anymore. If you wish to use the Administrator account, simply use your existing administrative login to reactive it and set the password. There is no reason to panic and, actually, no reason to do anything.
What is the best way to send a password to a Windows Service? Our application needs a password in order to start. I don't care that services are "normally" supposed to run without user interaction. Its good enough for us that an operator can start the application and then log off.
On a unix system, I would just echo the password over stdin but the service has no stdin.
Currently, we use the DPAPI to just store the password using CryptProtectData. While this, works, it presents other problems that are beginning to become troublesome.
I'm guessing that I'll need to use some form of IPC between the service and the application that is sending the password but I'm not sure which method is appropriate, if any.
Thanks
Two main options:
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
Thanks for responding Rowland.
You could listen on a socket on
startup and wait for the required
password to be supplied (maybe embed
an SSH server in there, so that the
password cannot be snooped over the
wire)
I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?
My preferred option would be to read
the password from a configuration file
(that can be secured to the minimum
readership) or registry setting
(again, sufficiently secure such that
only your service and administrators
can read/change it)
We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.
You can use kerberos mutual authentication. There are few options and examples there.
But just wondering. On a compromised machine, There may be a key logger. So typing the password is never secure if you want to maintain security in this environment. The same problem exist afaik for unix terminals.
DPAPI in UserMode is really the best option, and storing the encrypted data in a protected location, e.g. registry key with limited ACL.
What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...
What exactly were the problems that
are beginning to be troublesome? Maybe
we can just solve those...
Currently, the application runs as the Local System account.
Our application stores a number of credentials in an encrypted file and uses the DPAPI (in UserMode) for the encryption.
Thus, when the application is installed, the installer is run as the Local System account. We also have a set of tools that ship with the application, some of which need access to this encrypted file and thus, they too need to run as the Local System account.
By the time the application is installed and started, we're heavily dependent on that account.
We're running into problems because one of our users wants to use the application to access a shared network drive. The Local System account has no such privileges and we can't simply run our service as a different user because our encrypted information is protected under the Local System Account.
We've tried to avoid the process of setting up a user account just for our application because it is installed across many different customers and environments, all of whom have wildly different security policies.
You can access a remote drive from a service running under system account. However, you will need to have credentials & share information to connect to the remote machine. You can use the API wnetaddconnection to gain access. Probably your encrypted file can store this credential as well.