adduser and pure-ftpd
adduser and pure-ftpd
Hello, I'm playing with Wary Puppy 5.5 and pure-ftpd as ftp server. There is a problem when I add one user: the relative record added in file /etc/passwd, correspondent to new user, terminates with :/bin/bash . If you connect to ftp server and enter the right username and password, you will receive authentication error, 'cause the /bin/bash directory, relative to incoming user, does not exist. Modifying the record from :/bin/bash to :/bin/sh will solve the problem and makes the ftp server able to recognize username and password.
Various Unix/Linux applications call the getusershell() C library function to determine if a binary executable is in fact a valid user shell. Among the applications which do this are ftpd and pure-ftpd.
The getusershell() function looks at the list of valid user shells that are installed on your system. That list lives in the /etc/shells file. If that file is missing, the function assumes that /bin/sh and /bin/csh are valid shells, but no others are.
Apparently Wary 5.5 is missing the /etc/shells file. (Hmmm, I just looked at half a dozen Puppies, and none of them had an /etc/shells file: Puppy 4.3.1, Racy 5.2.2, Slacko 5.5-PAE, Precise 5.5, Precise 5.6, Wheezy 3.5.2.5-SCSI)
I don't have Wary 5.5, but I would guess that creating an /etc/shells file with the following contents would solve the problem:
If you have any other user shells in Wary 5.5, you could also list those. When editing the file, be sure to hit Enter, if necessary, to properly end the last line, or pure-ftpd may hang because it can't find the end of the /etc/shells file.
Here's what the pure-ftpd documentation says:
Documentation for pure-ftpd can be found with Menu -> Help -> Complete list of packages -> pureftpd.
Additional reading:
shells(5) - Linux man page
getusershell(3) - Linux man page
The getusershell() function looks at the list of valid user shells that are installed on your system. That list lives in the /etc/shells file. If that file is missing, the function assumes that /bin/sh and /bin/csh are valid shells, but no others are.
Apparently Wary 5.5 is missing the /etc/shells file. (Hmmm, I just looked at half a dozen Puppies, and none of them had an /etc/shells file: Puppy 4.3.1, Racy 5.2.2, Slacko 5.5-PAE, Precise 5.5, Precise 5.6, Wheezy 3.5.2.5-SCSI)
I don't have Wary 5.5, but I would guess that creating an /etc/shells file with the following contents would solve the problem:
Code: Select all
/bin/sh
/bin/bash
Here's what the pure-ftpd documentation says:
(Note that the version of pure-ftpd in Wary 5.5 may be older than 1.0.36 README file quoted above. But in Racy 5.4.91 I have pure-ftpd 1.0.22, and its README has the same paragraph.).:.PURE-FTPD .:. Documentation for version 1.0.36 wrote:Users need a shell listed in /etc/shells to get restricted or unrestricted FTP access. Alternatively, you can give them "ftp" as a shell. Users with a "ftp" shell will be able to login through FTP only: no telnet, no SSH. And there's no need (and you shouldn't do so) for an "ftp" entry in /etc/shells.
Documentation for pure-ftpd can be found with Menu -> Help -> Complete list of packages -> pureftpd.
Additional reading:
shells(5) - Linux man page
getusershell(3) - Linux man page
Can't login under vsftpd
I'm trying to get a small scale ftp server running in Precise 5.7.1 Retro. It'll be facing the net but I want it only for my use, not public use, so it needs to be fairly secure.
Vsftpd looked like a good choice and was in the Ubuntu-Precise repo. It seemed to install fine.
However, I've run into what I think is a problem similar to the one in this thread. Anonymous logins to vsftpd work, but not authenticated ones.
Vsftpd uses pam for authentication.
Using adduser, I added a user (let's call him ftpuser) and gave him a password. The user gets added to /etc/passwd and also to /etc/shadow. However, vsftpd won't allow ftpuser to connect, saying the login is incorrect.
Spot, which supposedly has a null password, also can't log in.
This command line sequence also fails:
su spot
sudo -u ftpuser sh
Sudo prompts for a password for ftpuser, but it won't accept the password I set with adduser (and then tried resetting with passwd).
As suggested here, I created a file /etc/shells containing
/bin/sh
/bin/bash
but that didn't help.
I tried setting a null password for ftpuser with passwd (dangerous, I know), but still can't sudo to ftpuser nor can I log in via vsftpd.
I tried editing /etc/shadow directly, removing the password in ftpuser's password field, so the account should have had no password. No dice.
Tried the same with /etc/passwd, removing the x that (I think) directs authentication to /etc/shadow - same result.
ftpuser can't log in, even with a null password.
I removed ftpuser with deluser and added ftpuser to /etc/passwd manually, both with and without a password, and still the same deal. ftpuser can't log in, no matter what I do.
Am I running up against an inevitable limitation of Puppy and his single-user nature?
Should I try a different ftp server? Before I try them all, does anyone have a recommendation?
Thanks, all.
Vsftpd looked like a good choice and was in the Ubuntu-Precise repo. It seemed to install fine.
However, I've run into what I think is a problem similar to the one in this thread. Anonymous logins to vsftpd work, but not authenticated ones.
Vsftpd uses pam for authentication.
Using adduser, I added a user (let's call him ftpuser) and gave him a password. The user gets added to /etc/passwd and also to /etc/shadow. However, vsftpd won't allow ftpuser to connect, saying the login is incorrect.
Spot, which supposedly has a null password, also can't log in.
This command line sequence also fails:
su spot
sudo -u ftpuser sh
Sudo prompts for a password for ftpuser, but it won't accept the password I set with adduser (and then tried resetting with passwd).
As suggested here, I created a file /etc/shells containing
/bin/sh
/bin/bash
but that didn't help.
I tried setting a null password for ftpuser with passwd (dangerous, I know), but still can't sudo to ftpuser nor can I log in via vsftpd.
I tried editing /etc/shadow directly, removing the password in ftpuser's password field, so the account should have had no password. No dice.
Tried the same with /etc/passwd, removing the x that (I think) directs authentication to /etc/shadow - same result.
ftpuser can't log in, even with a null password.
I removed ftpuser with deluser and added ftpuser to /etc/passwd manually, both with and without a password, and still the same deal. ftpuser can't log in, no matter what I do.
Am I running up against an inevitable limitation of Puppy and his single-user nature?
Should I try a different ftp server? Before I try them all, does anyone have a recommendation?
Thanks, all.
May I assume that after using adduser, you have verified that the user can login normally with login, as in the following excerpt from a bash session?ahoppin wrote:Using adduser, I added a user (let's call him ftpuser) and gave him a password. The user gets added to /etc/passwd and also to /etc/shadow. However, vsftpd won't allow ftpuser to connect, saying the login is incorrect.
Code: Select all
# mkdir -p /home
# adduser ftpuser
Changing password for ftpuser
New password:
Retype password:
Password for ftpuser changed by root
# login ftpuser
Password:
# whoami
ftpuser
#
Not just anyone can use sudo. In order to use sudo, a user should be listed in the /etc/sudoers file, or should be a member of a group that is listed in the /etc/sudoers file.
For instance, various Puppies have a sudoers file that contains this line:
Code: Select all
%users ALL=(ALL) ALL, NOPASSWD: SHUTDOWN, SYSTEM
If your sudoers file has that line, giving permission to your new user to run sudo may be as easy as adding her to the group named "users":
Code: Select all
addgroup ftpuser users
Also be aware that the password expected by sudo might not be the password of the user that is invoking sudo or the password of the user indicated by sudo's -u option. Although by default sudo does expect the password of the user that invokes it, it may want the password of the user specified by sudo's -u parameter, the password of the user defined by the runas_default option (normally root), or the password of root, if one of the targetpw, runaspw, or rootpw flags, respectively, is set in the sudoers file for the user that is invoking sudo.
(Oddly, looking at some recent Puppies and one not-so-recent Puppy (slacko-5.5-PAE, precise-5.5, precise-5.6, wheezy-3.5.2.5, and racy-5.2.2) I find this line:
Code: Select all
Defaults:users runaspw, passwd_tries=1
For more details see the man page for sudoers.