How to script "disable password policy" (for ssh)?

Am building a docker image and container with SSH.

For the past couple days, I’ve manipulated /etc/ssh/sshd.config every which way I can imagine to enable

  • Either no password or an acceptable password for root
  • Disable key authentication.

This special instance relaxing security to ordinarily dangerous levels is being implemented in a Dev environment without security needs and may eventually be modified “as needed” for regular docker use.

Main objective:
Enable ssh login using password credentials only and no key authentication. Note that this also assumes that no client pub key should need to be copied to the Server. End desired result is username/password auth only, encryption would then use whatever keys the server and client are willing to negotiate.

Problem:
Minor issue - Interestingly although after disabling key authentication completely, sshd still wants keys available so I’ve generated the keys although I don’t intend to use them.

Minor issue - Corollary of above is that all available keys are offered to the User despite attempts to disable key authentication altogether.

Main issue - Passwords are failing.
Have tried empty password (see my code below as one of the tries) which succeeds in building but the User is still prompted for a password
Have tried a password which passes policy on a standard openSUSE but when the image is built by Docker, openSUSE (not anything else) is rejecting that password(offered 13579Rh and somehow openSUSE thinks in some dictionary). Error follows

Step 14 : RUN echo 'root:13579Rh' | chpasswd ---> Running in 132ee21c4001
BAD PASSWORD: it is based on a dictionary word
chpasswd: (user root) pam_chauthtok() failed, error:
Authentication token manipulation error
chpasswd: (line 1, user root) password not changed

You don’t absolutely need to read the following block of code unless you’re interested in everything I’ve tried modifying the sshd app itself (/etc/ssh/sshd.config).

Instead of posting each and every modification I’ve tried, the following is an excerpt of the commands I’ve used modifying /etc/ssh/sshd.config… The hashes of course are past modifications which have been inactivated (by commenting out) and the active commands were my latest try

RUN sed -i 's/UsePAM yes/UsePAM no/' /etc/ssh/sshd_config
RUN ssh-keygen -f /etc/ssh/ssh_host_rsa_key -q
RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -q
RUN ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -q
RUN sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication no/' /etc/ssh/sshd_config
RUN sed -i 's/#ChallengeResponseAuthentication yes/ChallengeREsponseAuthentication no/' /etc/ssh/sshd_config
RUN sed -i 's/#PermitRootLogin yes/PermitRootLogin yes/' /etc/ssh/sshd_config
# RUN sed -i 's/#MaxAuthTries 6/MaxAuthTries 2/' /etc/ssh/sshd_config
RUN sed -i 's/#MaxSessions 10/MaxSessions 2/' /etc/ssh/sshd_config
RUN sed -i 's/#X11UseLocalhost yes/X11UseLocalhost yes/' /etc/ssh/sshd_config
RUN sed -i 's/#Banner none/Banner none/' /etc/ssh/sshd_config
RUN echo 'root:13579Rh' | chpasswd
# RUN echo "root:*" | chpasswd -e
# RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config

If someone needs assistance deciphering the sed commands
sed
-i means to modify the file in place
s/ specifies the beginning of the string to be matched
/ specifies the end of the string to be matched

which is then followed by the replacement text enclosed in their own forward slashes,
followed by the file to be inspected.

In a Nutshell,
I’ve exhausted every way I can think of to disable key authentication and configure Username/Password authentication only in SSH.
So, I’m now turning to attempting to diable password policy altogether at the system OS level (not application) and would need to know where/how to do that by script.

TIA,
TSU

That might be a misunderstanding. I think you are referring to the host keys. Those are part of the protocol, and are independent of how the user authenticates. They allow the user to check whether he is connected to the correct server, rather than a bogus man-in-the-middle connection hijacker.

Beyond that, it is not clear what you are doing.

In particular, it is not clear whether you are restarting the sshd service after changing sshd_config. The running daemon only reads its configuration on startup, so your changes won’t have any effect until you restart the service.

Host keys for all three encryption methods (rsa, dsa and ecdsa) are created and available.
I only mentioned them as required and requirement fulfilled, regardless whether the User uses them for authenticating the machine or not (I do understand this machine authentication is separate from user authentication).

In docker, it’s possible to “containerize” both full OS and individual apps, but a containerized app like ssh is ordinarily built within a base OS (I’ve selected openSUSE but it can be any distro). Subsystems like systemd cannot be accessed from within a container so to a certain degree running apps/services is simply executing the binary. So, for example when building this “sshd container” I invoke ssh by binary (/usr/sbin/sshd) and not with an init script or systemctl command.

I’ve described this just to try to clarify that any concept of “service” or auto startup is not relevant here. You have to think of the function only as a manually invoked app.

But, that’s a bit off tangent to what I think I need, I need to script disabling password policy at the system level… unless someone can describe how to do that at the app level (sshd).

TSU

If anyone is that interested in my work in progress the following is my Dockerfile (think of it as an install script). Remember the following file still has the problem this thread might resolve. When a working configuration is created, I’ll post it somewhere and contribute the results as a pre-built usable image.

Generally it
Uses an openSUSE image as the base
Refreshes the zypper local cache
Installs openssh
Modifies the sshd config
Modifies and sets the root password in the container
Instructs Docker that an app in the container intends to communicate with the outside world on port 22
Starts the sshd daemon(server) app

The end result would be that a remote User should be able to ssh into this container which can either be linked to another app or os container which lacks sshd or the code can be embedded into another docker image.

# cat Dockerfile
FROM opensuse
MAINTAINER tsu
RUN zypper --gpg-auto-import-keys ref
RUN zypper --non-interactive in openssh
# RUN cat /dev/zero | ssh-keygen -q -N "" 
# RUN mkdir /root/.ssh
RUN sed -i 's/UsePAM yes/UsePAM no/' /etc/ssh/sshd_config
RUN ssh-keygen -f /etc/ssh/ssh_host_rsa_key -q
RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -q
RUN ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key -q
RUN sed -i 's/#PubkeyAuthentication yes/PubkeyAuthentication no/' /etc/ssh/sshd_config
RUN sed -i 's/#ChallengeResponseAuthentication yes/ChallengeREsponseAuthentication no/' /etc/ssh/sshd_config
RUN sed -i 's/#PermitRootLogin yes/PermitRootLogin yes/' /etc/ssh/sshd_config
# RUN sed -i 's/#MaxAuthTries 6/MaxAuthTries 2/' /etc/ssh/sshd_config
RUN sed -i 's/#MaxSessions 10/MaxSessions 2/' /etc/ssh/sshd_config
RUN sed -i 's/#X11UseLocalhost yes/X11UseLocalhost yes/' /etc/ssh/sshd_config
RUN sed -i 's/#Banner none/Banner none/' /etc/ssh/sshd_config
RUN echo 'root:13579Rh' | chpasswd
# RUN echo "root:*" | chpasswd -e
# RUN sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config


EXPOSE 22
# CMD "/usr/sbin/sshd"]
CMD "/usr/sbin/sshd", "-D"]

Then, to restart it, you need to find its process ID, and us


# kill -HUP process-id

It should then restart itself. Maybe there’s an “sshd.pid” file containing the process-id in “/run”. There isn’t on my system, but that’s probably because “systemd” calls it with the “-D” option.

If you are not restarting “sshd” after changing “sshd_config”, then that is the source of your problem.

edit: I see you are starting “sshd” after the changes. So that isn’t your problem. I probably don’t know enough about “docker” to be able to see the problem.

Thx,
In docker the concept of a “service” is the container, starting a container as a background running is the equivalent of a running service. Whatever binaries are executed in the dockerfile will run as long as the container itself is running (and you noticed I executed the sshd binary).

So, my problem isn’t how ssh is started because once started I can ssh into the container but cannot present proper credentials. After following the recommendations to allow PAM in the ssh-config unsuccessfully, then disabling PAM and still being unsuccessful, I’m now turning to see if I can disable relevant PAM modules. This should effectively modify password policy at the system level.

TSU

Have you tried doing the login with “ssh -v” or even “ssh -v -v”. Those should give additional output which might help to see what is going wrong.

You might be running into the problem that ssh/sshd will always pretend to ask for a password when it finds a problem, because it does not want to give away information about whether the account exists or not.

I think you can also run “sshd” with “-v” or similar to get its diagnostics. But this assume that there is somewhere other than “/dev/null” where it will write them.

Please show your /etc/ssh/sshd.config and output of “ssh -vvv server”.

Have posted on susepaste
http://susepaste.org/28965210

Included are the related files

  • The Dockerfile used to build the host sshd image
    Contains all the commands used to build and modify the default sshd_config
  • The ssh connection stdout.
    Don’t pay attention to the port number, although sshd is configured for port 22 in the container, it’s mapped to a different port outside the container. You’ll notice a tcp/ip connection succeeds. The last 17 lines or so provide little more hint than less verbose. Note that the build accepts only “*” as a non-dictionary password, so the client connection attempts to connect with passwords null (blank password), then asterisk, then the HostOS password with the displayed result. Note also that when I look at /etc/passwd, I see an asterisk for the password instead of the expected null. Don’t know if the asterisk is supposed to be equivalent to null which is why I tried both when connecting.
  • The** sshd_config file** as modified.
    For those who might prefer reading the actual file instead of just looking at the sed commands in the Dockerfile to see what I changed.

I also posted on susepaste the result attempting to build using a password which I wouldn’t expect should be in a dictionary (13579Rh) but was rejected for being a dictionary word (BAD PASSWORD)
http://susepaste.org/36473044

Additional note:
You might notice I disabled PAM authentication in the first susepaste, but enabled in the bottom, in both cases I disabled “ChallengeResponseAuthentication” and disabled “PubkeyAuthentication” as recommended in the sshd_config comment so that if PAM authentication is used, I should still be able to benefit from logging and other benefits.

If someone actually wants to re-run what I’ve described, I can post the full steps although I don’t know that’d be necessary to troubleshoot, I think all the raw info to analyze has been provided.

TIA,
TSU

On 2014-09-15 17:06, tsu2 wrote:

> I look at /etc/passwd, I see an asterisk for the password instead of the
> expected null.

Manual page passwd(5)

If you create a new login, first put an asterisk (*) in the
password field, then use passwd(1) to set it.

password This is either the encrypted user password, an
asterisk (*), or the letter ‘x’. (See pwconv(8) for an explanation of ‘x’.)

If the encrypted password is set to an asterisk (*), the user
will be unable to login using login(1), but may still login using
rlogin(1), run existing processes and initiate new ones through
rsh(1), cron(8), at(1), or mail filters, etc. Trying to lock an account
by simply changing the shell field yields the same result and
additionally allows the use of su(1).


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

Makes sense,
The method to simply set and leave asterisk as the password was found on a not-so-official website.
So, it appears that asterisk simply fails the login instead of prompting for a new password.

Still exploring this avenue of thought while also exploring pam config possibility as described in my other post in the Applications forum.

BTW - of course I’ve also tried simply removing the asterisk in /etc/passwd forcing a null field, but that doesn’t work, either.

TSU

On 2014-09-15 19:26, tsu2 wrote:

> BTW - of course I’ve also tried simply removing the asterisk in
> /etc/passwd forcing a null field, but that doesn’t work, either.

Only some specific chars are allowed in that field, each one with a
meaning. I have seen a list of them all in a short paragraph somewhere,
but not in a man page. I’d post it if I remembered where. As it is, each
char appears to be described on different man pages all over the place.
Un-findable. Google perhaps? I’m not good at searching specifics with
google… :frowning:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)