使用 crypt 密码生成的 Useradd

发布于 2024-07-25 05:26:44 字数 803 浏览 9 评论 0原文

我正在编写一个我认为非常简单的脚本，用于使用“useradd”动态创建 FTP 用户。这个过程的几个部分我不熟悉，而且一整天的研究并没有让我走得太远。这是我所拥有的：

password="pass"
pass=$(perl -e 'print crypt($ARGV[0], "wtf")' $password)
useradd -d HOME_DIR -s /bin/bash -g GROUP -p $pass -f -1 testing

注释

HOME_DIR 和 GROUP 是占位符
我对“useradd”的 home/base_dir（-d、-b）或组（-g）功能没有任何问题

主题：

为什么我的密码生成工作不起作用？
/bin/bash 是纯 FTP 用户使用的正确 shell，还是我会使用 /bin/false 或其他 shell？
默认情况下，useradd 会禁用帐户，直到他们提供自己的密码为止，我该如何绕过此操作？
我不想使用 passwd 实用程序，因为它会削弱我自动生成 FTP 帐户的能力，我找到了解决方案这里，但我不明白解决方案

如果我的做法是错误的，或者我想做的事情是否不可能，或者如果我对本文中所陈述的任何内容都存在误解。感谢您提供任何帮助。：D

原文

I am working on what I thought was a very simple script to dynamically create an FTP user using 'useradd' There are several parts of this process I am unfamiliar with, and an entire day's research has not gotten me too far. Here is what I have:

password="pass"
pass=$(perl -e 'print crypt($ARGV[0], "wtf")' $password)
useradd -d HOME_DIR -s /bin/bash -g GROUP -p $pass -f -1 testing

Notes

HOME_DIR and GROUP are placeholders
I am not having issues with the home/base_dir (-d, -b) or group (-g) functionality of 'useradd'

Topics:

Why are my password generation efforts not working?
is /bin/bash the correct shell to use for a purely FTP user, or would I use /bin/false or a different shell?
By default, useradd disables an account until they provide their own password, how do I bypass this?
I do not want to use the passwd utility as it cripples my ability to automagically generate FTP accounts, I found a solution to this here, but I do not understand the solution

Let me know if I am going about this all wrong, or if what I am trying to do is not possible or if I am misinformed about anything I have stated herein. Thank you for any help you can provide. :D

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

北音执念 2024-08-01 05:26:44

关于密码生成：

32.3 加密密码
函数：char * crypt (const char *key, const char *salt)
crypt 函数采用字符串形式的密码、key 和一个如下所述的 salt 字符数组，并返回以另一种盐开头的可打印 ASCII 字符串。人们相信，给定函数的输出，找到将产生该输出的 key 的最佳方法是猜测 key 的值，直到 key 的原始值em>找到了密钥。
salt 参数有两个作用。首先，它选择使用哪种算法，基于 MD5 的算法还是基于 DES 的算法。其次，对于试图根据包含许多密码的文件猜测密码的人来说，这会变得更加困难；如果没有salt，入侵者可以进行猜测，对其运行crypt一次，并将结果与所有密码进行比较。对于salt，入侵者必须为每种不同的salt运行crypt一次。
对于基于 MD5 的算法，salt 应由字符串 $1$ 组成，后跟最多 8 个字符，最后以另一个 $< /code> 或字符串结尾。 crypt 的结果将是 salt，如果盐不以 1 结尾，则后跟 $，后跟字母表中的 22 个字符。/0 -9A-Za-z，总共最多 34 个字符。键中的每个字符都很重要。
对于基于 DES 的算法，salt 应由字母表 ./0-9A-Za-z 中的两个字符组成，以及的结果>crypt 将是这两个字符，后面跟着来自同一字母表的 11 个字符，总共 13 个。只有键中的前 8 个字符是重要的。基于MD5的算法对所使用的密码的有用长度没有限制，并且稍微更安全。因此，它优于基于 DES 的算法。当用户第一次输入密码时，盐应该设置为一个相当随机的新字符串。要根据先前调用 crypt 的结果验证密码，请将先前调用的结果作为盐传递。

根据您的系统，可能还存在 Blowfish 或 SHA-2 系列crypt，并且出于安全原因可能会禁用传统 DES。 PAM 也可以在这里添加自己的复杂性。

     ID       |    Method
  -------------------------------
     1        |  MD5 (Linux, BSD)
     2a       |  Blowfish (OpenBSD)
     md5      |  Sun MD5
     5        |  SHA-256 (Linux, since glibc 2.7)
     6        |  SHA-512 (Linux, since glibc 2.7)

话虽如此，它

root# useradd -d / -g users -p $(perl -e'print crypt("foo", "aa")') -M -N foo
user$ su - foo
Password: foo
foo$ ^D
root# userdel foo

在我的系统上运行得很好。

关于 shell：

/sbin/nologin 对于无法登录的用户来说是传统的。您必须仔细检查 FTP 守护程序的配置，看看是否将它们排除在 FTP 访问之外。

关于禁用帐户：

如上所示，如果给出工作密码，这对我来说是有效的，正如预期的那样。

关于其他解决方案：

您对替代解决方案有什么不了解的地方？我觉得很清楚。

只需将“username:password”通过管道传输到“chpasswd”即可。

如果您想要仅限 FTP 的用户，我建议使用支持虚拟用户的 FTP 守护进程，例如 glftpd、纯 FTPd, ProFTPD，vsftpd，...实际上似乎所有常见的都是如此。这样，FTP 帐户不需要真实的系统帐户。

Regarding password generation:

32.3 Encrypting Passwords
Function: char * crypt (const char *key, const char *salt)
The crypt function takes a password, key, as a string, and a salt character array which is described below, and returns a printable ASCII string which starts with another salt. It is believed that, given the output of the function, the best way to find a key that will produce that output is to guess values of key until the original value of key is found.
The salt parameter does two things. Firstly, it selects which algorithm is used, the MD5-based one or the DES-based one. Secondly, it makes life harder for someone trying to guess passwords against a file containing many passwords; without a salt, an intruder can make a guess, run crypt on it once, and compare the result with all the passwords. With a salt, the intruder must run crypt once for each different salt.
For the MD5-based algorithm, the salt should consist of the string $1$ , followed by up to 8 characters, terminated by either another $ or the end of the string. The result of crypt will be the salt, followed by a $ if the salt didn't end with one, followed by 22 characters from the alphabet ./0-9A-Za-z, up to 34 characters total. Every character in the key is significant.
For the DES-based algorithm, the salt should consist of two characters from the alphabet ./0-9A-Za-z, and the result of crypt will be those two characters followed by 11 more from the same alphabet, 13 in total. Only the first 8 characters in the key are significant.
The MD5-based algorithm has no limit on the useful length of the password used, and is slightly more secure. It is therefore preferred over the DES-based algorithm.
When the user enters their password for the first time, the salt should be set to a new string which is reasonably random. To verify a password against the result of a previous call to crypt, pass the result of the previous call as the salt.

Depending on your system, there may also be Blowfish or SHA-2 family crypts as well, and it's possible that the traditional DES may be disabled for security. PAM can add its own complications in here too.

     ID       |    Method
  -------------------------------
     1        |  MD5 (Linux, BSD)
     2a       |  Blowfish (OpenBSD)
     md5      |  Sun MD5
     5        |  SHA-256 (Linux, since glibc 2.7)
     6        |  SHA-512 (Linux, since glibc 2.7)

That being said, the

root# useradd -d / -g users -p $(perl -e'print crypt("foo", "aa")') -M -N foo
user$ su - foo
Password: foo
foo$ ^D
root# userdel foo

works just fine on my system.

Regarding the shell:

/sbin/nologin is traditional for login-disabled users. You'll have to double-check your FTP daemon's configuration to see if that excludes them from FTP access.

Regarding the disabled account:

As seen above, works for me, as expected if given a working password.

About the other solution:

What don't you understand about the alternate solution? It seems very clear to me.

Just pipe "username:password" into "chpasswd".

If you want FTP-only users, I would recommend using a FTP daemon that supports virtual users like glftpd, Pure-FTPd, ProFTPD, vsftpd, ... actually it seems that all the common ones do. This way, an FTP account does not require a real system account.

回复收藏 0 原文