[clug] Remote Authentication for Linux

[Bob Edwards]

On 1/9/21 2:55 pm, jm via linux wrote:
> This is a planing issue. Here's more of the gory details I was hoping to
> spare people from.
> 
> It's more a "everything is out of date before it sees the light of day"
> problem. My work creates an IoT (for want of a better word) device.
> These can spend several months in a warehouse or someone's ute before
> getting install. The device gets powered on and then sits around
> sometimes for weeks before the person doing the installation decides to
> do the installation. In the meantime, the software is out of date and
> the disk has filled up. The user accounts to get into the device are out
> of date (staff churn). I'm the only one now who has an account that is
> in the pre-installed image on the device before installation is
> complete. The remote management software won't run with a full /var
> partition so someone has to log into the device to free up the disk
> space. The management software will then make changes to stop the disk
> filling as part of the installation process as well as other things.
> 
> There are two changes I'm trying to make,
> 
> 1) Remove the bug in future pre-installed images so that the disk
> doesn't fill, and,
> 
> 2) Remove the dependency on local accounts in case something like this
> happens again and to future proof it against staff churn.
> 
> It's this second one I'm hoping that someone has a good suggestion on
> how to do. I'd rather avoid a shared user account as that could be a
> point of weakness.
> 
> Jeff.

If I were doing this (don't know about how it will work with /var full),
I'd consider the wretched phone-home solution.

Set up a cron job on the device to regularly open an SSH connection,
using SSH keys, to a secure maintenance server with a well-known,
long-lasting DNS name, or IP address. Do this with a port-forward and,
say, once a day or so for a short period of time (eg. 5 mins).

Then, when you need to do some maintenance, do an SSH back into the
device over the port-forward, so it can only be accessed from your
(secure) maintenance node, again using SSH keys.

Alternatively, slightly more complex, consider doing it using SSH
over web-sockets over HTTPS, which will/should pass through more
firewalls.

You end up with a simple situation where each end must trust the other
before any access is granted.

cheers,
Bob Edwards.

> 
> 
> On 1/9/21 14:37, steve jenkin wrote:
>> Is this a “What if” planning problem or a “Holy Crap!” Operational Problem?
>>
>> Specifically, are you trying to get an admin shell (ie. ’super user’) access to a machine that’s in trouble with a full /var?
>>
>> ==============
>>
>> <mode type=“pendant"> There’s no such thing as ‘a remote login’ on Unix-based systems. </mode>
>>
>> There are only tty-based sessions, spawning a command (typically a shell with ‘-l’ flag) to a particular UID’s - not even usernames, though multiple usernames can have the same UID.
>>
>> Any application that's allowed to accept incoming network connections can spawn any executable with it’s own UID.
>> If the application has the “setuid” bit set and is owned by UID 0, it can spawn a process with any UID - exactly the same as login / getty used to create user shells.
>>
>> In BSD, this was how “inetd” was used as a ‘remote access’ equivalent to “init”, with control file (/etc/inetd.conf) modelled on /etc/inittab and /etc/init.d + /etc/rc.d.
>> The original Unix "inetd" was derived from “init”, which rate-limited login attempts - from serial ports. Getty would be “respawned” as fast as the system would allow.
>> There were simple mis-configurations of ports & cables that could create this issue and the system would hit 100% CPU respawning getty.
>>
>> Early “inetd” had this hard-coded respawn limit, which proved a problem with high-performance machines receiving lots of connection requests.
>>
>> ==============
>>
>> Simple answer, assuming you’re dealing with an operational problem"
>>
>> 	If you’ve got still SSHD got running, I presume you’ve got a series of non-admin (UID > 1000) usernames already setup.
>> 	Some of those usernames must have the ability to become super-user, ie. entires in “sudo” (/etc/sudoers) or equivalent.
>>
>> 	You need to find one of those special accounts that has "private key” authentication setup.
>> 	Ideally your existing username is also in /etc/sudoers or is allowed to execute ‘/bin/su’ and you know the super-user password
>>
>> If you haven’t preplanned remote shell access, your only option is to get to the console to login, or power cycle the system.
>>
>>
>> ==============
>>
>> I don’t know how SSHD copes with not being able to log logins (to /var/log/auth.log and/or /var/log/secure. others? unsure)
>> 	See /etc/sshd_config for locations
>>
>> With normal partition mapping, a full /var will stop logging in /var/log
>>
>> Something to note:
>> 	In BSD-based UFS filesystem, writes/creat's by _non-admin_ users would return a Filesystem Full error when filesys was 95% full.
>> 	Super-user (maybe other admin users) were the only processes that could completely fill a filesystem (to 100%)
>>
>> 	I’m not sure of the detail of non-priviliged processes using “syslog” facility to write via syslogd (runs privileged) to typically write in /var/log
>>
>> 	Web-servers normally are run with minimum privileges (even the ’nobody’ UID) for ’security’ reasons.
>> 	A side effect was the web-server would stop logging to /var/log directly, but if it’s writing via “syslog”, that could fill /var.
>>
>> ==============
>> 	
>>
>>> On 1 Sep 2021, at 12:22, jm via linux <linux at lists.samba.org> wrote:
>>>
>>> Does anyone know of a list of (or can suggest) an authentication method
>>> that will work with debian? The requirements is that it can do the log
>>> in procedure for someone trying to log into the machine remotely, most
>>> likely via ssh, who may never have logged in when the clock may be
>>> highly skewed and the /var partition is full.
>>>
>>>
>>> Jeff.
>>>
>>>
>>>
>>> -- 
>>> linux mailing list
>>> linux at lists.samba.org
>>> https://lists.samba.org/mailman/listinfo/linux
>> --
>> Steve Jenkin, IT Systems and Design
>> 0412 786 915 (+61 412 786 915)
>> PO Box 38, Kippax ACT 2615, AUSTRALIA
>>
>> mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
>>
> 
>