I haven't logged on to my EC2 recently in a few months. Last time I did, it seems like the RDP file that I downloaded had the password in it. That laptop died.
Today, it seems like AWS/EC2 has changed how things work. I'm able to download the RDP file, but it is prompting for a password. When I try to decrypt the password, it wants me to paste or browse to a file on my disk, which I don't have.
Is there a way to re-download my key info? On security then "Key Pairs", I see the key for this server. Can I download that to my disk, or open it somehow?
I see these steps, but they look overwhelming, i.e. I don't have time for that now; I have real work to do:
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ResettingAdminPassword_EC2Config.html
I was able to create a new key pair, but not sure if I can associate it with the instance.
When I click "Get Password" this screen appears:
UPDATE 1: I did find my .pem file, so I was able to use that to logon.
Had I not found it, what would I do?
UPDATE 1: I did find my .pem file, so I was able to use that to logon. Had I not found it, what would I do?
Not much really! This is by design. AWS doesn't store your encryption key, and this prevents AWS personnel to access your instance. That's why you get such an ominous warning when pem file is generated: this is your one and only opportunity to see it - don't lose it.
That said, there are several however.
If you changed your Windows password in windows, or created a new AMI and launched a new instance from it - the pem file won't really help. You can probably create 2 administrator accounts; so if one forgets their password, you can reset it with another one.
Second - if your EBS is not encrypted, you can detach it, launch another instance, and attach EBS to new instance. You won't get your instance back, but you will get the data from that drive.
Finally, the "overwhelming" steps from the link that you posted. Follow good security posture, and you won't need them. But if you get sloppy, it may become your real work... better than polishing a resume...
Related
I have a machine which I want to find where my password hash is stored.
the set command returns details about the account and shows that it is connected to a domain however it doesn't show in net user. As well as this on advanced system settings -> User profiles the account shows as type: local and Status: local.
It seems to be a domain user however windows doesn't think it's on a domain.
Because of this searching for hashes has only brought up dead ends. They aren't in the SAM file and they aren't in SECURITY. I also tried password recovery software and the account simply didn't show.
I could see the correct hash through sekurlsa::LogonPasswords full - specifically serkurlsa::msv with mimikatz but now I would like to know where they are stored.
I know they are cached somewhere as I can login without internet, so I think I'm specifically looking for this file.
A brief search of the command suggests they are in the SAM database but I know they aren't.
Any assistance would be appreciated.
I'm working on a tool that generates .rdp files and then invokes them using Microsoft RDP Client. This tool is running on Mac OS.
Everything works well, the only problem is that I can't figure out of how I can generate 'password 51:b' field properly. On Windows this can be done easily by using CryptProtectData method from Crypt32.dll library. How can I do the same on Mac.
Another option could be to use "rdp://" URL scheme, but it doesn't seem allow to pass password this way.
So the question is how can I implement auto-login on Mac if I use third-party RDP client.
As far as i know you can't. You can however create a "User Account" and a Server configuration and add both to the client. The connection will then be visible on the main window and you just need to double click it.
To do so, you need to add the password to the Keychain, use /usr/bin/security to do so from a script. It needs to be a generic-password and saved in com.microsoft.rdc.macos. Also be sure to generate an ID according to the RDP Clients scheme, like BFF77777-7777-7777-7777-777777777777.
You may also set the permissions to read that key using /usr/bin/security and set-generic-password-partition-list specifying the right teamid (UBF8T346G9) and again com.microsoft.rdc.macos. You need the admin password to do this step.
Then you can alter the RDP Clients config file, which is a .sqlite file located at /Users/$(whoami)/Library/Containers/com.microsoft.rdc.macos/Data/Library/Application Support/com.microsoft.rdc.macos/com.microsoft.rdc.application-data.sqlite. Add the user configuration in the ZCREDENTIALENTITY table and make sure the ZID matches the one added to the keychain.
To add a server configuration you need to alter the ZBOOKMARKENTITY table. Just add a configuration by hand using the UI and look at the table to get a feeling of how it needs to be setup. Basically you link your user configuration with the server configuratio by making sure that ZCREDENTIAL in ZBOOKMARKENTITY matches Z_PK in ZCREDENTIALENTITY of your user configuration.
I know the answer is a bit late, but it may give you a starting point. This will however not fully automate the process, you will still need to go to the UI and double click the connection you want to use.
I am testing Windows 7 file encryption. A test file was encrypted ( I see green colored file name). that file was shared across the network and it still can opened from other station. That green color file name is also viewable from other computer as well. What am I doing wrong? I admit that I don't know the encryption concept yet.
If I moved that file to shared folder of other computers, message appeared asking "Confirm encryption loss". How can I copy that file with encryption?
I know Truecrypt software but I am testing with Windows Encryption.
The NTFS file encryption is using your password hash to encrypt the file.
If you connect to the file from another computer you need to supply the user's password, which means the remote computer has the key to decrypt the file.
If you copy the file from the share to the local computer windows will save the key in the remote computer.
The whole idea in the filesystem encryption is that another user cannot use your encrypted files, or someone that get a hold on your hard-drive. But, if you're logged in, all the running applications that has been executed by you or have access to your token (for example, SYSTEM user) can access the file without ever knowing it is encrypted on the disk.
Be careful of encryption! Some encryption systems for Windows will automatically encrypt your files/folders for you. This is common in gov't/corporate computers. If you do NOT have this set, and then another user on your computer who DOES have this set accesses your file/folder, the file/folder can get encrypted with that other user's token, and then you won't be able to access your own file/folder!
This actually happened to me last week. Took a whole day to figure it out, because Windows won't tell you WHO encrypted the file, just that it wasn't done with your current token. Aaargh!
(This won't happen if permissions are set to ReadOnly, but in a collaborative environment sometimes permissions aren't set that way.)
I do the following using AWS web console:
Attach EBS volume-A to instance-A. Make some changes to data on volume-A and detach it
Launch new instance-B (in the same zone as instance-A)
Try attach volume-A to the new instance-B. But the new instance does not appear in the instances list during attach volume process (dialog box).
If I try the same attach using command line EC2 API (volume-A and instance-B), it works fine!
Do you know if this is a bug in AWS web console or am I doing something wrong in the console? Tried page refresh in Step #3 but it still would not list the new instance.
In order to attach, both volumes has to be in the same zone. So if you are going to attach a volume into a instance check the zone of the instance's attached volume. If those are not matching create a new instance with the same zone as the zone of the volume that you need to attached.
The volume and the instance have to be in the same region AND the same zone.
If you have a volume in us-east-1a and the instance in us-east-1b, you would need to move the volume to us-east-1b to make it work.
Even I had faced this problem yesterday and a day before. It looks like Amazon problem with their cache. Not sure WHY.
To bring back the stuff as is, I had to sign-out and make sure things are good. But it's always good to work with CLI, works better.
Although the user interface may not list the instance ID, you can attempt to add the volume anyway. If it's genuinely impossible (rather than a cache issue) you will get an error message.
Paste in the instance ID (i-xxxxxxx) manually then type your mount point (e.g. /dev/sdf) and click Attach.
For the benefit of others: some instance types do not support encrypted volumes, which may be why the instance doesn't appear in the list. I get the following error:
Error attaching volume: 'vol-12341234' is encrypted and 't2.medium' does not support encrypted volumes.
I lost access via ssh to my amazon ec2 instance and I need to access it NOW due to a problem with my service. I was told that there is a way to access the command-line via web with a java applet but I haven't been able to find it.
Is there a way to access the command-line without the .pem file? terminating/rebooting the instance is not feasible.
AFAIK it is not possible - Amazon does not retain private keys and once your instance has been assigned a keypair, it cannot be reassigned.
You could try to create a new instance with a separate keypair and ssh locally between them, but I don't imagine that that is possible.
If it's an EBS-based instance and you were able to stop it, you could mount the EBS volume to a new instance and copy a new key over; however, based on what you said, I don't believe it's possible. You may need to contact Amazon, but even then, there might not be anything that can be done.
Edit: on the same vein as the 2nd line, if you have other user accounts who have valid login shells, and you have sudo access on one of those accounts, you can do the same as mentioned in the last bit, where you generate a new keypair and upload the private key to ~/.ssh/authorized_keys.