# [SOLVED] Failed ssh authentication creates a user account?

## phajdan.jr

Today I noticed a lot of new entries in /home in one of my boxes. After examining the logs here's the likely cause:

 */var/log/auth.log wrote:*   

> 
> 
> Oct 11 03:10:54 hq sshd[27684]: Invalid user xenia from 61.63.11.93
> 
> Oct 11 03:10:54 hq sshd[29351]: pam_tally(sshd:auth): pam_get_uid; no such user
> ...

 

Here are possibly relevant pieces of configuration:

 */etc/pam.d/sshd wrote:*   

> 
> 
> auth       include      system-remote-login
> 
> account    include      system-remote-login
> ...

 

 */etc/pam.d/system-remote-login wrote:*   

> 
> 
> auth            include         system-login
> 
> account         include         system-login
> ...

 

 */etc/pam.d/system-login wrote:*   

> 
> 
> auth            required        pam_tally.so onerr=succeed
> 
> auth            required        pam_shells.so 
> ...

 

 */etc/pam.d/system-auth wrote:*   

> 
> 
> auth            required        pam_env.so 
> 
> auth            required        pam_unix.so try_first_pass likeauth nullok 
> ...

 

It obviously looks very weird, and my first thought was a break-in. However, with so much noise (and all those new users have disabled passwords), I'm not so sure. It might be a configuration issue. What do you think?

----------

## nativemad

Hi Pawel, 

i just had a look at my testbox, and the only difference i see in these pam-files is that mine is using pam_tally2.so in system-login.

I could also think of some weird nss failure!? 

This is my default /etc/nsswitch.conf, but even with "compat" for example proftpd could create homedirs (of course for valid users only via ftp [i use this for ldap-users]).

Maybe it could be worth a try to set it to "files" instead of "compat" to get a little closer!? 

```
# /etc/nsswitch.conf:

# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd:      compat

shadow:      compat

group:       compat

# passwd:    db files nis

# shadow:    db files nis

# group:     db files nis

hosts:       files dns

networks:    files dns

services:    db files

protocols:   db files

rpc:         db files

ethers:      db files

netmasks:    files

netgroup:    files

bootparams:  files

automount:   files

aliases:     files
```

Or did you got a very screwed sshd_config!?   :Rolling Eyes: 

For the record... The only difference in your log is the invoked useradd command

```
Oct 11 03:10:54 hq useradd[29915]: new group: name=xenia, GID=5856 

Oct 11 03:10:54 hq useradd[29915]: new user: name=xenia, UID=5856, GID=5856, home=/home/xenia, shell=/bin/bash 
```

...i would suggest rkhunter and maybe aide for the future!?

Good luck!

----------

## avendesora

I wouldn't be too surprised if this was linked to the pam_smbpass.so module somehow.

----------

## pjp

Wow... if samba is causing accounts to automatically be created, that's a huge security hole.  I'd poke at some more logs to see if it looks more like hacking.

----------

## phajdan.jr

Okay, I think I know what's going on (maybe not entirely, but to a reasonable degree).

pam_smbpass turned out to be indeed responsible for the mess. I was suspecting it since the beginning, but I don't understand why it didn't "break" before. However, I was updating that box shortly before it happened, and I remember some PAM updates, so maybe it was just a weird config file merge, or a change of PAM/samba behavior. Anyway, for last few days everything was fine. I have done some other checks about the box, but I'm not going to reinstall because it was really too noisy for a "hack", and I think the explanation and fix I have found sounds reasonable (right?).

Here's the change I have made to fix it. "required" doesn't prevent further modules from executing if it fails, but "requisite" does.

 */etc/pam.d/system-auth wrote:*   

> 
> 
> auth required pam_env.so 
> 
> auth requisite pam_unix.so try_first_pass likeauth nullok 
> ...

 

----------

