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.
I was going to add ssh key for the machine I ssh so I do not have to enter password every time, but when I hit ssh-keygen I got this prompt
Enter file in which to save the key (/Users/sanjeevkumar/.ssh/id_rsa):
I decided to accept I thought it will create new file mentioned in parentheses, but I got message saying
/Users/sanjeevkumar/.ssh/id_rsa already exists.
Overwrite (y/n)?
now I am little cautious that where did the existing file come from and for what the existing file is storing the key for.
If I choose to overwrite I don't want to be in situation where there tools stop working !
If you're not sure if you're already using that SSH Key for anything, you should make a back-up copy and then overwrite the key in order to check if anything is broken. (And if it is, just restore this back-up)
Other thing you could do is using your current key as your main one for this other machine.
I'm working on a shell script where it zips up a file then uploads it to a server i have.
So far i have it so it asks for the server password and then keeps that variable. After it does that the script zips up a folder with a bunch of files in it. Then it dose the "scp" command to send it to my server.
Now, this is where i need help... I want it to fill in the password that was provided earlier in the script when it asks for the server password. I'm sure your asking "why doesn't just put in the password when the "scp" command asks for it. The reason being is that the file i have is going to be large, and i dont want to sit around and watch it zip up. So thats why i provide the password early on.
here are the steps:
1) user provides server password which is saved as the variable "password"
2) the script zips up the file
3) the script sends the file to the server (when i run this part in the script it asks for the password. i have to put in the password variable here.)
Any ideas on how to do this? thanks so much, will,
Step 1 is flawed, for several reasons, both security-related and technical.
What you should do is to create a "null" SSH session in the background that generates a master connection (see the ControlPath and ControlMaster options in the ssh_config(5) man page). Using the same control settings for the subsequent SCP operation will use this connection without having to ask for the password. Don't forget to kill the null session once the script is done.
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?
in my ruby script I need to pass user name and
password as a plain text in a form in order to log in. Both user name and password are currently stored in my script.
I have no control over the server I log in from the script. The script is localy working fine and in the future I want to move to onto my
webhosting provider and run it from there (I have ssh access)
using cron. Is there any way/method how to
protect the password in case somebody gets access to this script by any chance?
The more I think about this, the more I think you must trust your hosting service. I would make sure the hosting service has "skin in the game": That is, that they host enough "high profile" accounts that being found untrustworthy would be very costly to them (in lost accounts and sales).
And whether or not you think the hosting service is trustworthy, you ought have a plan in case the target account is compromised. Who will you notify, how will you get that account deactivated, etc.
The only technological solution I can think of--you log on manually, capture the cookie, and provide that cookie to the script--protects the password, but presumably a hostile host could use that cookie to do any damage he wanted on the target system using whatever privileges are attached to that cookie, including changing your password. So it's no solution at all.
Oh, speaking of privileges: Can the task you need to automate be accomplished with a target account that has lowered privileges, such as a read-only account, or one that cannot make any changes to its profile? Having only your low-privilege credentials on the hosting service would lower your risk (or "exposure," as the polysyllabic crowd likes to say).
Prior answer, found to be unworkable, below the line.
You can encrypt the user id and password using yet another password. In order to run, the script has to be provided with it's password. It uses that password to decrypt the web service's user name and password. Make sure that the script's password doesn't get stored anywhere, but only held in memory and only for long enough to decrypt the ultimate user id and password.
If it really matters, make sure your connection to run the script is crypto (ssh, ssl, etc.), and make sure the script only uses https to log on.
That doesn't make you invulnerable to someone with root privileges on the box (at some point, the plaintext user-id and password will be in memory, and therefore vulnerable), but it does make it take more work for them to be able to get the user-id/password.
Updated: The requirement that this be automated makes the above solution no good.
If an automated script needs to run something with a password, then you either have to have it readable by the script (which opens up the possibility of someone else reading it) or else not provide it in automation.
The trick is to bypass the "Automation" part by having a one time startup: run the script as a small continual process that will wake up periodically and run. Have the process ask for the password on startup or via some other kind of API request (not on the command line!).
If the server reboots, the password is lost until you log in and enter the password again. This way, the password is only in memory, not on the file system.
You might want a cron job to check on the process and alert you if it is not running.
If you need to pass the password onwards to a form that you presumably can't alter to use a more secure scheme, there's little you can do besides obfuscate the password so that it's not immediately obvious. However, anyone with access to the script itself can simply find where it is passed to to the form and insert a command to print the password there — it needs to be “decrypted” at that point for you to pass it on, no matter what.
To protect it from non-programmers, you could XOR it with something or rotate the letters by some amount, but I wouldn't spend too much time on this as it will be futile against pretty much anyone with a rudimentary understanding of programming. Instead, protect the script itself from other users (set file access rights properly, don't put it in a web-visible directory, etc). And if you do not trust the server's administration, do not upload it there!
You should store a hashed version of the password in your database. A hash is a one way encryption, so it is impossible to use logic to guess the password from the hashed password.
Create a method to hash the password, and do something like this:
require "digest/sha1"
class User
attr_accessor :password
def initialize(password)
#password = hash_password(password)
end
def hash_password(password)
Digest::SHA1.hexdigest(password)
end
def valid_password?(password)
#password == hash_password(password)
end
end
u = User.new("12345")
p u.password # => "8cb2237d0679ca88db6464eac60da96345513964"
p u.valid_password?("not valid") # => false
p u.valid_password?("12345") # => true
When you get the plain text password from the form, you pass it to your valid_password? method. This will do the same one-way encryption as it did when the password was stored. So the one way encrypted passwords are compared. This means that you never store a reference to the actual password anywhere, which is a big win.