在 bash 中混淆存储的密码
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9828202/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Obfuscating stored passwords in bash
提问by Rodrigo
I have a bash script that I need to write my password to run a program. Other people can see it. Are there a way to write the password in a not too obvious way? Even if he can do the same command in bash and get the password, he can't read it in text.
我有一个 bash 脚本，我需要输入密码才能运行程序。其他人可以看到它。有没有办法以不太明显的方式编写密码？即使他可以在bash中执行相同的命令并获得密码，他也无法以文本形式阅读。
Today I do this:
今天我这样做：
PASSWORD="1234567"
program --pass=$PASSWORD
I want to do this
我想做这个
PASSWORD="10101001001010010101010100101" #binary or other code
NEW_PASS=`decrypt $PASSWORD`
program --pass=$NEW_PASS
Any idea?
任何的想法？
采纳答案by Charles Duffy
What you're asking for is not only evil -- it simply won't work.
你所要求的不仅是邪恶的——它根本行不通。
All a user has to do to see your password is to run bash -x your_scriptand the output will include
用户要查看您的密码所要做的就是运行bash -x your_script，输出将包括
+program '--pass=decrypted-password-here'
...no matter how effective the obfuscation might have been.
...无论混淆多么有效。
What's the actual program you're trying to call that needs a password? Can you hide your password behind a setuid wrapper, such that the wrapper can read the password file even if the user who runs it can't? Can you (borrowing DigitalRoss's suggestion) set up a user account which has a copy of the stored password (or, better, a certificate or keypair), configure it only to be able to run your script and nothing else over SSH, and give the users who should be able to run the script permissions to SSH as that user (or sudo to that user for only the single command, or so forth)?
您尝试调用的需要密码的实际程序是什么？您能否将您的密码隐藏在 setuid 包装器后面，这样即使运行它的用户不能读取密码文件，该包装器也可以读取密码文件？您能否（借用 DigitalRoss 的建议）设置一个用户帐户，该帐户具有存储密码的副本（或者更好的是证书或密钥对），将其配置为仅能够通过 SSH 运行您的脚本而没有其他任何内容，并提供应该能够以该用户身份运行 SSH 脚本权限的用户（或仅针对单个命令对该用户执行 sudo，等等）？
Etc.
等等。
In short: Aim for real security, not obfuscation.
简而言之：旨在实现真正的安全性，而不是混淆。
Now, if you didwant obfuscation -- the traditional approach is ROT-16:
现在，如果您确实想要混淆——传统的方法是 ROT-16：
obfuscated_password="qrpelcgrq-cnffjbeq-urer"
real_password="$(tr a-zA-Z n-za-mN-ZA-M <<<"$obfuscated_password")"
...but if it's a password you actually care about whatsoever, don't obfuscate -- use one of the approaches given above to avoid storing a password in a user-readable manner at all.
...但如果它是您真正关心的密码，请不要混淆 - 使用上面给出的方法之一来避免以用户可读的方式存储密码。
回答by DigitalRoss
You could use uuencode and uudecode,which are often installed (and always easily available via packages) on Unix systems. Since the encoding will be meaningless it might prevent an observer from easily memorizing the password, i.e., stealing the password via shoulder-surfing.But a well-chosen random clear-text password would accomplish about the same thing without the false illusion of security.
您可以使用uuencode 和 uudecode，它们通常安装在 Unix 系统上（并且总是可以通过软件包轻松获得）。由于编码将毫无意义，它可能会阻止观察者轻松记住密码，即通过肩冲浪窃取密码。但是一个精心挑选的随机明文密码可以完成同样的事情，而不会产生虚假的安全错觉。
This exact problem is faced by everyone in DevOpsthese days as automated configuration management becomes more and more necessary.
如今，随着自动化配置管理变得越来越必要，DevOps 中的每个人都面临着这个确切的问题。
Here are some better solutions:
这里有一些更好的解决方案：
have a secretsfile on the system your script runs on. The script can read its secret at runtime out of the file. This way you can check the script in to source-code control without broadcasting the password, and you can use user permissions to protect the secrets file. You can reuse the script without propagating a password.
use no-passphrase ssh public key authentication to get to the remote system
use a combination of the above approaches with a role-restricted user. I usually create a user on the target system that can't do anything except what the script wants to do. Modern versions of ssh help with this, as they can ignore the incoming command (see forcecommand in sshd_config or use something like ssh-forcecommand) and just always do a specific thing.
authenticate the management agent client via a server-signed certificate. Real configuration-management systems like Puppetand Chefwill do this for you.
if you are connecting to a web page, you may still be able to create a role-restricted user or at least one that's expendable. Perhaps you could log in by hand once and establish a persistent session. Curlcan use cookies and cooperate with this approach.
在您的脚本运行的系统上有一个秘密文件。脚本可以在运行时从文件中读取其秘密。这样您就可以在不广播密码的情况下将脚本签入源代码控制，并且您可以使用用户权限来保护机密文件。您可以在不传播密码的情况下重复使用该脚本。
使用无密码 ssh 公钥认证访问远程系统
对受角色限制的用户使用上述方法的组合。我通常在目标系统上创建一个用户，除了脚本想要做的事情外，它什么也做不了。现代版本的 ssh 对此有所帮助，因为它们可以忽略传入的命令（请参阅 sshd_config 中的 forcecommand 或使用类似 ssh-forcecommand 的内容）并且始终执行特定的操作。
如果您正在连接到一个网页，您可能仍然能够创建一个角色限制用户或至少一个可消耗的用户。也许您可以手动登录一次并建立持久会话。 Curl可以使用 cookie 并配合这种方式。
回答by Greg Hewgill
A "not too difficult" way is to use ROT13:
“不太难”的方法是使用ROT13：
PASSWORD=cnffjbeq
REAL_PASSWORD=`echo $PASSWORD | rot13`
If you don't have a rot13program, using tr a-z n-za-mworks just as well.
如果您没有rot13程序，使用tr a-z n-za-m也同样有效。
Keep in mind that this provides absolutely no security whatsoever. However, it may be sufficient for your "casual viewing" purposes.
请记住，这绝对不提供任何安全性。但是，它可能足以满足您的“休闲观看”目的。
回答by pizza
Putting the key under the door mat isn't security. But the fact that 'program' needs to take --pass ..... means anyone doing 'ps -ef' can see it. If 'program' has a form that can read the password from a pipe, then you should use it instead. e.g. program --pass=- ... < /home/me/.something and make the file only readable to you.
把钥匙放在门垫下面是不安全的。但是，'program' 需要使用 --pass ..... 的事实意味着任何执行 'ps -ef' 的人都可以看到它。如果“程序”有一个可以从管道中读取密码的表单，那么您应该使用它。例如 program --pass=- ... < /home/me/.something 并使文件只对您可读。
