Shell How to enter ENTER key in a script

NULL passwords​

Check that all accounts use a password for authentication. Don't allow any account to have a null or blank password. Setting up key pairs is a good defense against null passwords. Remove any instances of the "nullok" option in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords.
Click to expand...
from
www.redhat.com

Sysadmin security: 8 Linux lockdown controls

How to lock down your Linux system from unwanted access locally and across the network.
www.redhat.com www.redhat.com

Looks like the problem is not new to others.
Question is if this is a "well known problem" that can be coped with a hardened configuration by a responsible sysadmin?
 
getopt I guess we have to differentiate. No doubt, having "null" (or empty) passwords at all is a bad idea. Just don't do it.

Still, handling them should work as expected. Being able to store both a hash of the empty string or nothing at all in passwd(5) to represent an empty password is a technical fact unfortunately, no way to fix that...

In your quote, the recommendation is to remove nullok everywhere to prevent logins with empty passwords. That makes sense, but our pam_unix(8) would still allow a login with an empty password when it is stored as a hash of the empty string ... might actually be a security issue :what:. Of course, you can also avoid it by just never ever using an empty password.

The second issue (and the only one I was thinking about previously) is just consistency. IMHO, it should be consistent between tools how empty passwords are stored (and I think the empty filed, so no hash at all, makes more sense). But now I've seen in my experiments that OpenSSH seems to expect a hash of the empty string instead. Oh my ....
 
zirias@ said:
Our SSH is OpenSSH, so upstream is OpenBSD, it's imported into our tree here: https://cgit.freebsd.org/src/tree/crypto/openssh

OpenBSD doesn't use PAM but has "BSD authentication" instead ... just maybe this adds to the confusion ... :-/ of course, the "portable" version of OpenSSH supports PAM, it's also used in (most?) Linux distributions for example.

In a nutshell, all this mess probably boils down to the fact that you have two possibilities for storing an empty password in passwd(5), and it looks like there's no common agreement which one is the "correct" one. I could still try to at least "fix" the inconsistency in our pam_unix(8), but this would still lead to "surprising" results with e.g. OpenSSH :(
Click to expand...
Is there any way to get this to work?

Code: 
pw usermod -n root -h 0 << 'EOT'
[ENTER]                               
EOT

I don't know how to formulate 'ENTER' in this context. And do we know that it definitely won't create a blank, rather than 'null' password?
 
I thought it was clear enough by now that this is neither your problem nor your solution. Bottom line is still: don't ever use empty passwords. If really needed, password-less logins via SSH should be done with keys.
 
Watch how PAM behaves when you are getting close to it (credits to Michael W. Lucas):
View: https://youtu.be/-CXp3byvI1g?t=590



The way OpenBSD authenticates users is quite different from other Unix-like operating systems. Most other systems like AIX, Solaris, Linux, the other BSDs, and MacOS, use a framework called Pluggable Authentication Module (PAM). The two main implementations are Linux PAM and OpenPAM. PAM modules are created as dynamically loaded shared objects, which communicate using a combination of common and implementation specific interfaces (Linux-PAM and OpenPAM). It's configured using the pam.d directory and pam.conf file. While it can be flexible, it's highly complex and very easy to mis-configure, leaving you open to strange and hard to track down authentication bugs. On top of that, the fact that it's a shared library means that any vulnerability in a poorly vetted authentication module gives attackers direct access to the internals of your application. Author Michael W. Lucas said it best when he described PAM as unstandardized black magic.
Click to expand...

How BSD Authentication Works

A walkthrough of OpenBSD's BSD Authentication framework
blog.lambda.cx blog.lambda.cx
 
I am out of my scope here but I would like to mention one area of possible investigation.

With FreeBSD installer Images and ISO's you have a LiveCD mode.

This drops to shell with 'root' user and no password prompt.

I am assuming this is a function of bsdinstall scripts but it is odd a login with user only.
 
Looking at /etc/pam.d/system and wondering while we have a pam_ssh(8) why is it commented out by default there?

# $FreeBSD$
#
# System-wide defaults
#

# auth
auth sufficient pam_opie.so no_warn no_fake_prompts
auth requisite pam_opieaccess.so no_warn allow_local
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
auth required pam_unix.so no_warn try_first_pass nullok

# account
#account required pam_krb5.so
account required pam_login_access.so
account required pam_unix.so

# session
#session optional pam_ssh.so want_agent
session required pam_lastlog.so no_fail

# password
#password sufficient pam_krb5.so no_warn try_first_pass
password required pam_unix.so no_warn try_first_pass
Click to expand...
 
getopt said:
Looking at /etc/pam.d/system and wondering while we have a pam_ssh(8) why is it commented out by default there?
Click to expand...
It would be a massive POLA violation (possibly even with security implications) when just generating some password-protected SSH key would magically enable a login to the owner's account using the password of that key. The purpose of the password is normally just to unlock/decrypt this specific key (and then most likely use that key to access a different account/machine with SSH where it's listed in authorized_keys), pam_ssh(8) repurposes it, which might or might not be a nice thing you want, but should certainly be activated explicitly.
 
getopt said:
But removing nullok there would be advisable, right?
Click to expand...
Probably. But, OTOH, a bit pointless as it would currently only prevent logins when the hash is empty, not when there's a hash of the empty string. I still consider this a bug, but regarding all the mess and confusion around it, I have no good idea what to actually do. "Just don't ever set an empty password on any account" certainly avoids all problems. ?
 
zirias@ said:
I still consider this a bug, but regarding all the mess and confusion around it, I have no good idea what to actually do.
Click to expand...
Discussing this problem in the reviews or on a mailing list may help. Or just write a PR and see what feedback comes?

Edit: And as it may affect security talking to the FreeBSD security team may also be a way to go.
 
zirias@ said:
No doubt, having "null" (or empty) passwords at all is a bad idea.
Click to expand...
There may be cases where it is sensible. I know a few. One is ancient: On a VAX with a line printer, we had an account named "feed" with no password. All the account would do is issue a form feed to the printer. This was useful when people printed a partial page, walked (several hundred meters) to the printer, and wanted to tear it off the printer, but the giant (I think IBM-made) 1403 printer didn't have a "form feed" button. So we put an old VT52 terminal next to it, and everytime you entered "feed" at the login prompt, another page came out.

On my home server, I have an account named "date", again with no password. The room the server is in has no wall clock, and if you want to know what time it is, you just type "date" and look at the screen. If someone was logged in (I typically leave root logged in on the console!), you now know how late it is. If nobody was logged in, the date account simply displays date and time on the console, and logs back out.

Yes, our house is physically secure enough that I leave my wallet on a little table by the front door (which is only locked if we leave for several weeks), and they key to the car on the seat of the car. Having root logged on the console is not a security problem in our environment. Matter-of-fact, on the Raspberry Pi that is inside our little pump station, I auto-login a user (cunningly named "plumber") when booting, and it automatically starts an equipment monitoring display program that has a shell exit. So there are use cases for both passwordless login and auto-login, but they are uncommon, and need to have their security implications thought through.
 
Talk about derailing a topic. Let's get back on topic and stop picking on OP.

How do you put the Enter key in a script?

I have a need for this. I want to setup my rsync script to wait a few moments then send my password and the "Enter" key, same need as op. Sending whatever the terminal requires that my keyboard sends when I press the Enter key.

Yes I know you pedantics are going to argue about this terminology, you've already done so and shown your intellectual superiority, let's move on and address the question shall we?
 
thedaemon said:
How do you put the Enter key in a script?
Click to expand...

If passing "\n" doesn't work, then you might want to try the ^M character.

Two approaches to generate this char in a terminal (and terminal text editor):
  • Hold ctrl, press 'v' then press 'm', then release ctrl.
  • Hold ctrl, press 'v', then release ctrl, then press enter
It looks a bit weird but you can generally add this to scripts. I use it to automate fdisk and (n)vi key mappings, etc.
 
kpedersen said:
If passing "\n" doesn't work, then you might want to try the ^M character.

Two approaches to generate this char in a terminal (and terminal text editor):
  • Hold ctrl, press 'v' then press 'm', then release ctrl.
  • Hold ctrl, press 'v', then release ctrl, then press enter
It looks a bit weird but you can generally add this to scripts. I use it to automate fdisk and (n)vi key mappings, etc.
Click to expand...
This is the puzzle:-

Code: 
pw usermod -n root -h 0 << 'EOT'
[ENTER]                               
EOT

I guess some other short script would do check for [ENTER] but can't think of one at the moment...

It doesn't really matter so much about pw usermod so much at this point.
 
thedaemon said:
Talk about derailing a topic. Let's get back on topic and stop picking on OP.

How do you put the Enter key in a script?
Click to expand...
You're "derailing" it in the same way the original XY-problem did. It's getting boring, but again: you can't do that. All you can do in a script is simulate a key press in various ways, depending on the environment (like "raw" terminal, X11, ...). And also once again, this is almost certainly not a sane solution for whatever problem you actually have.

thedaemon said:
Yes I know you pedantics are going to argue about this terminology, you've already done so and shown your intellectual superiority, let's move on and address the question shall we?
Click to expand...
So, if you didn't understand the technical details, getting aggressive isn't all too helpful.

balanga said:
This is the puzzle:-
Click to expand...
This is wrong in yet another way: pw(8) will never accept an empty password. That's why it has a dedicated method for setting one (-w none). And it stores it as an empty password hash field. If my second review above gets accepted, passwd(1) will do exactly the same thing when the user just hits enter.
 
zirias@ said:
So, if you didn't understand the technical details, getting aggressive isn't all too helpful.
Click to expand...
I'm being the opposite of aggressive, lol. I'm also not insulting anyones intelligence... I only said others were intellectually superior. I won't feed the trolls anymore, as the question was answered.
 
Paul Floyd said:
”expect” can interact with ttys.
Click to expand...
That's interesting, I didn't "expect" that ?.

So, to get the whole picture here, it would currently be possible to set an empty password (stored as a hash of the empty string) with passwd(1) automated with expect. It wouldn't help with pw(8) though, which takes a password from a simple input stream, not a terminal, and just refuses an empty password there.

The dilemma with this thread is: The actual question asked by the OP is certainly interesting in itself. It's still not suitable to solve the problem that motivated that question. ?‍♂️
 
You must log in or register to reply here.
Back
Top