On Wed, 14 Apr 2021, Stan Johnson wrote:

Hello,

I'm trying to configure Debian SID to be usable on a Mac SE/30 (16 MHz,
128 MiB memory, SCSI2SD disk). Telnet and FTP to the system initially
both timed out. I was able to set LOGIN_TIMEOUT in /etc/login.defs to
180 (the default is 60 seconds), and that allowed telnet connections to
work, but ftp connections still time out (both work fine on a Mac IIci
at 25 MHz). Of course, at only 16 MHz, SSH isn't even an option for the
SE/30 (or the IIci).

Does anyone know of a way to set the ftp login timeout? I could probably modify the ftpd source, but I would prefer to modify a configuration
file setting if possible.

I don't know about ftpd but if you install vsftpd you can control those timeouts in vsftpd.conf.

If I can get ftp working, the SE/30 will be a good low-end m68k 68030
system (perhaps the lowest end?) for testing modern Linux kernels.

I use QEMU to configure filesystems for all of my m68k systems. Linux
kernels can either be cross-compiled or compiled in QEMU. While QEMU is
a great emulator, I would still like to be able to run distributions on
real hardware, whenever possible.

Other changes to the default Debian SID installation have included
replacing systemd with sysvinit (far too many timeouts with systemd).
And by configuring a static /dev, I was able to disable udevd (again,
too many timeouts). I think my next effort will be to break PAM and
revert to old-style authentication, if possible.

You can probably test that approach by building a portable FTP or Telnet
daemon and disabling PAM support using ./configure.

You may also want to try minimal implementations of telnetd and ftpd, such
as the ones offered by busybox. If you build your own, you also get to
modify any hard-coded timeout constants.

It's interesting that I can login almost immediately using telnet or ftp using A/UX, but telnet in Debian takes about 100 seconds (and ftp still
times out).

Most of that is probably password hashing. Look in /etc/shadow and you'll probably find long password hashes. If you're not worried about weak
hashes, you could switch to DES which is probably what A/UX uses. See 'man login.defs' and 'man 3 crypt'.

BTW, if your password hashes are never leaked or your actual passwords are guessable anyway then I don't see much benefit from SHA512.

FTR, I'm not advocating guessable passwords and weak hashes. But if you
want to try it, I hear that 12345 is very popular:

$ perl -e 'print crypt("12345","xx")."\n"'
xxwddmriJc5TI

thanks for any suggestions

-Stan Johnson

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Stan,

On 15 Apr 2021, at 4:23, Finn Thain wrote:

Most of that is probably password hashing. Look in /etc/shadow and
you'll
probably find long password hashes. If you're not worried about weak
hashes, you could switch to DES which is probably what A/UX uses. See
'man
login.defs' and 'man 3 crypt'.

BTW, if your password hashes are never leaked or your actual passwords
are
guessable anyway then I don't see much benefit from SHA512.

FTR, I'm not advocating guessable passwords and weak hashes. But if
you
want to try it, I hear that 12345 is very popular:

$ perl -e 'print crypt("12345","xx")."\n"'
xxwddmriJc5TI

When I had similar problems on a Mac LCII, I've switched the password
hashing scheme from SHA512 (5000 Rounds) to MD5 with

ENCRYPT_METHOD MD5

in /etc/login.defs and

password [success=1 default=ignore] pam_unix.so obscure md5

in /etc/pam.d/common-password

After changing this setting, make sure to set a new password for the
users that you use. The password string in /etc/shadow should now look
like this

user:$1$LJE/eegi$OnIQXGTyEwh2q8rhyJssw/:18732:0:99999:7:::

instead of this (SHA512)

user:$6$ThsKWiJWXD8NRyVk$4jC4Rmn9.SoHFou7w84VOYgTshzyvbz2zIBgDbozbzC5CfYw8Dipihsrd8HC5oNob2OjTun.2dDl0KU4c5lO51:18732:0:99999:7:::

Greetings

Carsten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 15 Apr 2021, Stan Johnson wrote:

Most of that is probably password hashing. Look in /etc/shadow and
you'll probably find long password hashes. If you're not worried about
weak hashes, you could switch to DES which is probably what A/UX uses.
See 'man login.defs' and 'man 3 crypt'.

BTW, if your password hashes are never leaked or your actual passwords
are guessable anyway then I don't see much benefit from SHA512.

FTR, I'm not advocating guessable passwords and weak hashes. But if
you want to try it, I hear that 12345 is very popular:

$ perl -e 'print crypt("12345","xx")."\n"'
xxwddmriJc5TI

I've always supported security protocols that match the associated risk.
For systems that are not exposed to the public Internet and that require clear-text protocols, anyway, such as telnet and ftp, for reasonable
access, there is nothing wrong with minimal password hashes (though I
agree "12345" is still a bad idea!).

Yes. And it's not only the hashing of guessable passwords that wastes CPU cycles. If we're trying to mitigate the possible leakage of /etc/shadow
through a privilege escalation attack, and if the strong, unguessable
passwords in that file were never used elsewhere, SHA512 is still a waste
of cycles, because privilege escalation would gain access to everything protected by those passwords anyway.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)