On Sat, 9 Apr 2022, ffuentes wrote:
What I really don't know is how to
create the account and allow it to connect to my server without an
identity file. Never read anyone who did this.
Actually, this is a very old-school configuration which is
disabled by default nowadays due to an abundance of (*sigh*)
script kiddies and their use of remote password brute-force tools.
It could be enabled: the relevant OpenSSHd configuration keys are `PasswordAuthentication` and `PermitEmptyPasswords`.
You would NOT want these to be enabled for every accounts however,
so you would have to use a conditional block in order to apply that
to a very specific one.
In case when the guest user in question is named "guest"
(which must be created beforehand, and like you described
with empty password), the relevant stanza in OpenSSHd configuration
would theoretically be:
Match User guest
PasswordAuthentication yes
PermitEmptyPasswords yes
Note that this conditional block will not terminate until there is another `Match` line or the end of configuration file; so you probably want
to specify this at the very end of your OpenSSHd configuration.
This is the easiest part of the endeavor; other devils are in the details...
I was wondering whether it was possible and safe to make an anonymous
account for people to explore the server.
What you said so far seems to imply a singular "guest" user,
which got me thinking:
1. What would happen when there are more than one guests
trying to use the system at the same time? Or do you plan to make sure
that there is only one SSH connection possible under user "guest";
and if so, do you plan to limit the connection time of this
single "guest" and how?
2. How/when would you manage/clear/isolate the data in the "guest" account's
home directory? (You know, because having read-only $HOME could cause
some software's function to be duds or unadjustable)
And how/when you would do that when there are multiple login on "guest"
at the same time?
And if it's not read-only, would it considered to be okay
for later "guest" to have access to the earlier
(or other concurrent) "guest"'s files?
3. What happens when a guest tries to set a password with `passwd`
or other related information via `chsh` and `chfn`?
4. How do you plan discern multiple "guest" apart in audit logs
if an abuse occurs? (Just in case, it might or might not relevant;
I don't really have an experience in dealing with Unix audit trails)
You could go all laissez-faire about these of course, but I think
issue 2 and 3 are still important to consider even in that case.
There is another approach used by some purpose-specific shell server:
create guest accounts dynamically, then disable, kill, and wipe it out
after a timeout (or last logout). This is an advanced approach
which requires you to seriously write programs to orchestrate the actions,
but will allow you to sidestep all the concurrent-related issues above.
You can also make it in a way that guest account could even be requested
via SSH too, which new guest user could invoke it, something like:
$ ssh
guest@example.org create
Which you can write it to prompt to confirm account creation, set password, etc; and it would terminate when an account is created. Then, user could
start a normal SSH session like:
$ ssh
guest01@example.org
To actually use the account, until the timeout reached or last connection logged out. (Which further login will be disabled, user kicked,
all associated processes killed, account removed, and home directory nuked;
in that order)
Of course, this is an advanced things that only minority of full-time
"advanced professionals" would do. I'm merely suggesting it
as a possibility, because I have actually used something like that
in the wild.
In principle it shouldn't have access to the internet
I'm curious as well, how one could do this in OpenBSD?
(On GNU/Linux, I know that I could add policy routing with `iptables`
to drop/reject everything originated from "guest" user that tries
to go to anywhere other than the loopback/localhost or the machine's own
public IP address; combined with blanket reject rules on incoming TCP connect [and dropping rule for all incoming UDP] on all but select ports)
Take this with a grain of salt,
~xwindows
(Just another GNU/Linux user)
--
xwindows' gallery of freely-licensed artworks
https://tilde.club/~xwindows/ http://tilde.club/~xwindows/ gopher://tilde.club/1/~xwindows/
--- Synchronet 3.19a-Linux NewsLink 1.113