You are here
Ortho - Mon, 2019/05/20 - 17:40
Hello,
I have tried the following:
Webmin > System > Users and Groups
Add a user:
username: user123
home directory: /var/www
Shell: /bin/bash
Normal password
Primary group: users
In groups: ssh, sudo, www-data
Move home if changed: yes
Yet, when I attempt to connect, I get access denied. What am I missing to give this user remote ssh access to the server?
Side related question: How can I increase the attempts before the server stops responding to login attempts? (this is very annoying for testing).
Forum:
A few things...
My post will cover doing this stuff from the commandline. It's likely that you could do it via Webmin instead if you prefer. I don't use Webmin though, so I'm not particularly familiar with it, so explaining via commandline is much easier (actually it's much easier in general IMO - YMMV).
So there are a few things to do re making it easier to test SSH. First up, stop fail2ban. That will block your IP from connecting after 2 (or 3?) failed login attempts. Assuming that you log in via root, to temporarily disable it until you restart the service, or reboot the server (note that if you are not logged in as root, all commands will need to be prefixed with sudo):
After your done testing, you'll likely want to re-start it:
The other thing you may also want to adjust is the default SSH settings for 'MaxAuthTries' and perhaps 'MaxSessions' too? They are in the config file /etc/ssh/sshd_config. From the commandline, nano is probably the most intuitive text editor for someone with limited command experience, so you can open it for editing like this:
If you wish to see the Debian default values, you'll find them towards the top of the file (IIRC they're all commented out). Our hardened defaults are near the bottom (and they're the ones you'll want to adjust). Once you've updated those as desired, then restart SSH:
Restarting SSH may boot you out of your current SSH session, but you should be able to log back in easily.
Before we create the new user, it's also worth noting that by default, TurnKey servers don't include sudo, so if you intend to use this new user for doing any admin tasks, you'll want to install it:
As for creating the user, there are 2 Debian commands for creating users, 'adduser' is the higher level command which is interactive by default and takes care of lots of the background stuff for adding a new user. It is generally the recommended command for creating new "standard" users. E.g. it will create a new home directory in /home/username by default.
'useradd' is a lower level command which provides much more power regarding the specifics of the new user, but also requires more detail when setting up new users. Unless you know exactly what you are doing (and 'useradd' will fulfil your aims better/easier), the 'adduser' command is almost always the one you'll want to use.
Whilst what you've done so far should have "just worked", clearly it doesn't. I'm not sure on why, so my inclination would be to delete the new user that you've already created, then recreate it from scratch. I've tested these instructions on a local (TKLDev) system I have running. So assuming that you just want a new non-root user, with a home directory of /var/www, give this a try:
The 'adduser' command will ask a number of questions regarding your new user. Other than password (and password confirmation), and the final confirmation, they can all be skipped (by hitting Enter). Now to add the new user to the required groups:
To double check that all that worked ok, here's a number of commands that can be used (and the feedback that my system gives; even if your setup is right, your results may vary slightly):
The first command ('id') shows that 'user123' is a member of the groups: user123, sudo, www-data and ssh. The second shows that user123's home is /var/www and shell is /bin/bash.
It's also worth noting, that by default /var/www is owned by the www-data user. Whilst it is also owned by the www-data group (which user123 is a member of) the default group permissions are more limited that the www-data user itself. So to ensure that user123 has full access to /var/www, you'll need to adjust the permissions. The best way to do this is not really clear as there are a few different "best practice" security models.
One is that everything should be owned by root (or 'nobody') and the www-data user only has read access, except to files/directories that it explicitly needs. In a really "locked down" scenario, that may only be a cache directory and perhaps an uploads directory (so web users can upload files). That scenario would mean that even config via the webUI would not work (which may or may not be a good thing, depending on your perspective).
So how you decide to set things up, I will leave for you. But one way to resolve the permissions issue is on an ad hoc, case-by-case basis. I.e. seeing as the user can sudo, permissions can be changed as they cause issues, then further adjusted later as needed. Another way would be to ensure that www-data owns everything and www-data group has full permissions too.
The first line below ensures that the whole file directory tree is owned by www-data user & group. The next 2 lines set the appropriate www-data permissions (user and group: read, write, execute for directories; read, write for files - everyone else: read, execute for directories; read only for files).
Now to test out the user:
The first command should drop you into user123's shell and likely it's home dir (/var/www). The second line makes sure your in user123's home, the 3rd shows the current dir (should be /var/www). The next command uses sudo to list the files in root's home (demonstrating that sudo is working). The final command exits out of the su session, back to root.
As an aside, if you want to avoid entering the password when you use sudo, you can do that by adjusting the sudoers file. I.e. add a new line to the end:
Finally, exit out of the SSH session and retry logging in as user123. Hopefully it should work now! (It does for me...).
Add new comment