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).
Related
I have an EC2 server on AWS. I created a key pair upon first time connecting to the server (following whatever default steps on the console).
Now I want to login to the same server from a different machine. What is the best way to do so? Do I have to email my public key to the other machine?
I tried to create more key pairs on the AWS console, but can't figure out to additional key pairs to the server. Is that even possible?
Update:
This is not a duplicate question. My goal is not to associate two key pairs with one server. I am trying to find a way to login to a server from a different computer, whether to use the same key pair, another key pair or even a different user.
When an Amazon EC2 instance is launched from an Amazon Linux AMI (and several other Linux AMIs, too), the public half of the keypair selected at launched will automatically be copied to:
/home/users/ec2-user/.ssh/authorized_keys
When you later attempt to login to the ec2-user by providing the private half of the keypair, the two halves will be compared and, if they match, you will be permitted to login as that user.
You can allow another person to login to the ec2-user by either:
Giving them the same private keypair (bad for security), OR
By creating a keypair for them (via ssh-keygen) and adding the public half of that keypair to the above file
Alternatively, you could create a new user on the machine for them, then add the keypair to the above file within their user directory.
See: Add New User Accounts with SSH Access to a Linux Instance
So, to login to that EC2 instance from a different computer, you will need the private keypair on that different computer. It's just like a password.
Or, you could create a new keypair on that computer and copy the public keypair to the authorized_keys file on the target instance.
All of this is really Linux stuff, rather than something specific to Amazon EC2.
It is not possible to create multiple key pairs for an ec2 server; however you can create multiple users and through that give access.
Id advice creating multiple users and giving access via ssh with key authentication. I have included a link below with the walkthrough.
With that being said you Create a new user, then
allocate permissions and privileges. Next you generate a key - certificate. And finally, you associate the certificate to the user.
https://debian-administration.org/article/530/SSH_with_authentication_key_instead_of_password
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.
I have a batch script on SERVER A that activates a scheduled task on SERVER B using the 'schtasks' command. This command requires a userrname and password to access the other server, but we don't want to store this data in plain text. Is there a way to save this password in a non-plain-text format? Even if the password is passed to the 'schtasks' command in plain text, that would be better than storing it in the batch script itself.
Couldn't you use Kerberos?
If you can't, try to give a look at this Different ways to store a password variable in a Java web application? option 3. You could use a key, and share the key to decrypt the credentials you need, but it is still poorly secured.
If you can use Kerberos, just check on SERVERB if the Kerberos token is one you allowed. It could be a local user on SERVERA or a domain user. For example, you start the 'SCRIPT.bat' through 'schtasks' as Script_User_A on SERVERA; Script_User_A is a domain user, with low privileges. SERVERB starts a challenge/response with SERVERA as soon as it receives any first request, asking Script_User_A to prove its identity. Script_User_A will do it, SERVERB is happy, and everything works. If Malicious_User tries to execute 'SCRIPT.bat', SERVERB will send a challenge that Malicious_User will not be able to "response", and SERVERB will know the 'SCRIPT.bat' is executed by someone else.
With Kerberos this challenge/response mechanism comes for free: you need to study the Microsoft TechNet and the API a bit, but it is worth the effort, especially if you are used to develop on Windows.
Since version 5.50 the Bitvise SSH Server allows connected client to authenticate to Windows user account without providing this user's Windows password. See here: https://www.bitvise.com/ssh-server-version-history
I've checked it myself - it does indeed.
My question is of pure curiosity: what kind of sorcery is this? Is there any WinAPI that allows such thing or is this some kind of clever hack? I always thought it is impossible to impersonate as other user without a password (as even when configuring Windows service or scheduled task to "run as user" it is neccessary to provide one).
IIRC, the SSH server in Cygwin does the same thing.
If you have the appropriate privileges you can create an access token with ZwCreateToken, no password required. Such a token has some limitations. For example, you can't access network resources without a password and some encrypted material isn't accessible.
There's an explanation and some sample code here.
Since version 5.50, Bitvise SSH Server comes with a Windows authentication package. An authentication package can enhance the Windows logon process in custom ways. When the SSH server needs to log you in, but does not have a password (e.g. because you logged in with a public key), it calls the authentication package to construct a logon token which closely resembles the logon token that would have been created by Windows. As arx has noted, a session created this way does not contain your authentication credentials, so side effects are that you can't access things like network resources and EFS.
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.