I want to disable GPG caching entirely. Ie, symmetrically encrypt a file, then have it ask for a password every time.
Specifically, I'm using GPG 2.2.14 to try to do:
gpg -c file.txt
I've tried adding a ~/.gnupg/gpg-agent.conf with default-cache-ttl and max-cache both set to 1 but this doesn't seem to work. Ive also tried encrypting with --no-symkey-cache but again, this doesn't seem to prevent password caching. The two in combination also does not prevent caching. On first attempt it asks for password, then caches it and doesn't ask again.
I want the file to be encrypted and the password to be nuked and never seen again for all users, including myself and root. Anyone know how to do this?
System is Raspbian Buster 10 running on a raspberry pi 4.
Related
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...
I am trying to create an Alfred workflow that connects to my server through ssh without asking for my password. I tried
ssh root#myServerIP ; mypswd
and many other variants, but i can't seem to be able to wait for terminal to ask me my password before the script answer it.
Is it possible, in this case and in general to pre-enter the password on a terminal command ?
Thanx a lot in advance
Jad
There is no need of ; at the end. You can just hit enter at the end of the line and it will take it as an input for next command. for your case, it would look something like this.
ssh root#myServerIP
mypswd
If it's possible, I'd try to make it so that your workflow doesn't involve using SSH as root. Storing your password in a script seems like a security risk.
What I would suggest is using public/private key pairs (tutorial here and other places) to enable passwordless login from your client to the server, and sidestep the issue entirely. It's technically possible to do this with the root account as well, but again, I wouldn't recommend it.
I am learning to use maven password encryption capabilities and I would like to know how to choose the parameter <password>. There are two things that I don't understand:
1) mvn --encrypt-master-password foobar will always give a different encrypted master password.
Since the encrypted master password is always different, I see only two possibilities:
A local property is stored somewhere so that it can be used to decrypt the encrypted master password to get the master password. That means that our encrypted server passwords can only be used locally.
Nothing is stored and the master password is useless and doesn't matter at all.
So, my questions here are:
What is stored locally? Will my master password remain safe? Is there a third possibility I didn't think of?
2) On the maven website, it is written:
Also note that the encrypted passwords can be decrypted by someone that has the master password and settings security file. Keep this file secure (or stored separately) if you expect the possibility that the settings.xml file may be retrieved.
If the settings security file is the thing to protect, why should I bother choosing a strong master password? Can't I just use foobar and keep my settings security file safe?
Also, it looks like someone with the two files (settings security file and settings file) would not need the master password to connect to the maven servers. He could use our identity without knowing the passwords. The master password is "only" needed to decrypt the servers passwords (to get them plain text). But then again, protecting the settings security file should be the way to go and the master password would remain useless.
My questions:
How important is the master password? Have I got to remember it? Can I use a long random phrase and forget it forever?
PS: I couldn't find my answer here.
First password is used to generated the master password only, then you can forget it. It is generated using encryption mechanisms and pseudo-random component. As a consequence of that, it should not be possible to decipher it. There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again.
This master password is used to cipher and decipher passwords in your settings file. It has the same value as an user-introduced password, but it is almost impossible to deduce it.
Then:
There is nothing else stored locally than your master password in your security-settings file and it won't be ever prompted or asked again. All the safety resides in the safety of the security-settings file.
The master password is not really important and you can forget immediately. You can use whatever you want.
I don't like this approach to protect my password and I would like having a real password cyphering mechanism with a real master password not stored. Public-private key with password strategies seems to be better.
I am trying to decrypt a file from the server where I have the required public key of that server. The keyring has a password protection and so when I try to decrypt a file, it asks me for a passphrase.
Is there a way to bypass that passphrase by passing the password when we try to decrypt the file.
I am using gpg-agent where the passphrase is cached for 600sec default time and for some reason I am unable to set the max-cache-ttl (It didn't work for me, I don't know y) and is availble only for that session.
Now I want to cache the passphrase for which I am using gpg-preset-passphrase. I set it in .gnupg/gpg-agent.conf as gpg-preset-passphrase --preset hex. I don't know what I am missing in this.
Can someone please let me know what I am missing in this?
I am unable to bypass the passphrase or pinentry screen, but I used gpg-agent options like default-cache-ttl to set the cache time. So that from the second attempt, the pinentry is going to retrieve the cached passphrase and will reset the timer on defaul-cache-ttl.
There is one more called max-cache-ttl option, even after the successfull retrieval of cached passphrase and reset of default-cache-ttl, this option doesn't change its timer and expires the cached passphrase after the set timeout.
For ex: If I set both of them for 10hrs (i.e., 36000sec), if I call the decrypt after 5hrs, default is going to reset its timer and now we have 10more hours. But the max is going to expire after the initial 10hours and thus removes the cached passphrase after 10hours.
One more problem I found is, session issue with gpg-agent. i.e., if I open a new session and try to decrypt, it doesn't happen and errors out that gpg-agent is not available for this session. I wrote some shell script and put it on bashrc so that it starts as soon as a new session is started
I'd like to write a shell script that does something like the following
while read line; do
echo $line
done<input.txt | ssh > output.txt
This is a bit pseudo codey at the moment (the original is at work), but you should be able to tell what it's doing. For simple applications this works a treat, but ssh checks the input to see whether it's stdin is a terminal.
Is there a way to fool ssh into thinking that the contents of my piped loop are a terminal rather than a pipe?
EDIT : Sorry for not adding this originally, this is intended to allow ssh to log in via the shell script (answering the password prompt)
ssh -t -t will do what you want - this tells ssh to allocate a pseudo terminal no matter whether it is actually running in one.
Update
This problem (after updating your question and various comments, it became clear you are looking for a way to conveniently get public key encryption into place) could perhaps be solved by 'thinking upside down'.
Instead of trying very hard to get your clients public key onto a server that doesn't yet authenticate the client, you can try to receive an authenticated identity (private key) from that server.
Simple terms: generate a keypair on the server instead of the client, and then find a way to get the keypair on the client. The server can put the public key in it's authorized_keys in advance, so the client can connect right away.
Chances are that
the problem of getting the key across is more easily solved (you could even use a 'group' key for access from various clients)
if a less-secure mechanism is chosen (convenience over security) at least only the security of the client is reduced, not as-much that of the server (directly).
Original answer:
Short answer: Nope. (it would be a security hole for ssh, because ssh 'trusts' the tty for password entry, and the tty only)
Long answer, you could try to subvert/creatively use a terminal emulator (look at script/scriptreplay for inspiration).
Why would you want to do it?