[Slack 8.1/PureFTPD] authentication probleem

[Verwijderd]

Ik heb vanmiddag op me machientje pureftpd geinstalleerd, vrij standaard compile:

code:

./configure --with-quotas --with-virtualhosts --without-inetd

Maar.. daarna.. ineens..... kan ik ineens niet meer inloggen via SSH, ik mag me username & password opgeven, maar dan krijg ik meteen een Connection closed by remote host melding. Als ik dan in /var/log/syslog kijk:

code:

Jan  8 17:44:54 localhost sshd[7395]: fatal: login_get_lastlog: Cannot find account for uid 1000

Ook FTPen werkt niet meer. Telnet & pop3 werken dan weer wel. Uiteraard gecontroleerd of user ok was in group/passwd/shadow, maar ziet er ok uit, kan ook inloggen via telnet.

Systeem draait op Slackware 8.1 icm kernel 2.4.19. Standaard slackware installatie.

Enig idee?

[ Voor 7% gewijzigd door Verwijderd op 08-01-2003 17:56 ]

[Verwijderd]

eeehhh, je hebt toch nog wel een root shell openstaan he? Heb je met PAM lopen klooien? Mischien toevallig je /etc/passwd of je /etc/shadow stukgemaakt?

[Verwijderd]

Titel gefix0red

[Verwijderd]

Waarschijnlijk gebruikt pureftpd /etc/passwd en dergelijke files en heeft die aangepast aan z'n users ofzo. Je kunt beter een ftpd gebruiken die een eigen passwd en group file heeft zoals glftpd. http://www.glftpd.com

[Verwijderd]

Verwijderd schreef op 08 januari 2003 @ 18:12:
Waarschijnlijk gebruikt pureftpd /etc/passwd en dergelijke files en heeft die aangepast aan z'n users ofzo. Je kunt beter een ftpd gebruiken die een eigen passwd en group file heeft zoals glftpd. http://www.glftpd.com

jah ok, maar daar is mn probleem niet mee opgelost

Verwijderd schreef op 08 January 2003 @ 18:00:
eeehhh, je hebt toch nog wel een root shell openstaan he? Heb je met PAM lopen klooien? Mischien toevallig je /etc/passwd of je /etc/shadow stukgemaakt?

niks gedaan met PAM, zoals gezegd, ik kan nog wel inloggen met telnet en su'en naar root...., dat is het vreemde...

[Verwijderd]

Sorcerer: Zie de feature list van PureFTPd. Als je geen PAM wilt gebruiken, kun je gebruik maken van hun eigen database, ldap of mysql. Mocht dat allemaal niet genoeg zijn, PureFTPd heeft ook nog eens een simpele api waardoor custom authentication methodes gemakkelijk geimplementeerd kunnen worden. (als je kunt proggen that is )

Verwijderd schreef op 08 januari 2003 @ 18:57:
niks gedaan met PAM, zoals gezegd, ik kan nog wel inloggen met telnet en su'en naar root...., dat is het vreemde...

Hmz, idd. Probeer anders voor de grap eens sshd in debugging mode te starten en ssh -v -v -v gebruiken. Mischien dat er in de debugging output nog iets interesants staat. Mocht ook dat niet genoeg zijn kun je mischien eens gaan spelen met struss (op je sshd process) om zo te kijken waar die precies foutgaat.

[ Voor 7% gewijzigd door Verwijderd op 08-01-2003 22:11 ]

[Verwijderd]

Verwijderd schreef op 08 January 2003 @ 21:48:
Sorcerer: Zie de feature list van PureFTPd. Als je geen PAM wilt gebruiken, kun je gebruik maken van hun eigen database, ldap of mysql. Mocht dat allemaal niet genoeg zijn, PureFTPd heeft ook nog eens een simpele api waardoor custom authentication methodes gemakkelijk geimplementeerd kunnen worden. (als je kunt proggen that is )


[...]

Hmz, idd. Probeer anders voor de grap eens sshd in debugging mode te starten en ssh -v -v -v gebruiken. Mischien dat er in de debugging output nog iets interesants staat. Mocht ook dat niet genoeg zijn kun je mischien eens gaan spelen met struss (op je sshd process) om zo te kijken waar die precies foutgaat.

gedaan, de sshd in debug geeft dit (layout-verneukerij):

code:

debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD
debug3: mm_request_receive_expect entering: type 11
debug3: mm_request_receive entering
debug3: monitor_read: checking request 10
debug3: mm_answer_authpassword: sending result 1
debug3: mm_request_send entering: type 11
Accepted password for dignus from 212.129.176.134 port 32819 ssh2
debug1: monitor_child_preauth: dignus has been authenticated by privileged process
debug3: mm_get_keystate: Waiting for new keys
debug3: mm_request_receive_expect entering: type 24
debug3: mm_request_receive entering
debug3: mm_auth_password: user authenticated
Accepted password for dignus from 212.129.176.134 port 32819 ssh2
debug3: mm_send_keystate: Sending new keys: 0x8093ef0 0x8092eb0
debug3: mm_newkeys_to_blob: converting 0x8093ef0
debug3: mm_newkeys_to_blob: converting 0x8092eb0
debug3: mm_send_keystate: New keys have been sent
debug3: mm_send_keystate: Sending compression state
debug3: mm_request_send entering: type 24
debug3: mm_send_keystate: Finished sending state
debug3: mm_newkeys_from_blob: 0x8099d20(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Waiting for second key
debug3: mm_newkeys_from_blob: 0x8099d20(118)
debug2: mac_init: found hmac-md5
debug3: mm_get_keystate: Getting compression state
debug3: mm_get_keystate: Getting Network I/O buffers
debug3: mm_share_sync: Share sync
debug3: mm_share_sync: Share sync end
debug2: User child is on pid 29045
debug3: mm_request_receive entering
debug1: permanently_set_uid: 1012/100
debug1: newkeys: mode 0
debug1: newkeys: mode 1
debug1: Entering interactive session for SSH2.
debug1: fd 7 setting O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
login_get_lastlog: Cannot find account for uid 1012
debug1: Calling cleanup 0x805f9c8(0x0)
debug1: channel_free: channel 0: server-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 server-session (t10 r0 i0/0 o0/0 fd -1/-1)

debug3: channel_close_fds: channel 0: r -1 w -1 e -1
debug1: Calling cleanup 0x806b684(0x0)

Het is niet alleen sshd, dus ook ftp, alles wat met encrypted passwords lijkt te gaan. Telnet en POP3 werken nog wel namelijk....

[Mark]

code:

login_get_lastlog: Cannot find account for uid 1012

Ik vermoed een rotte passwd file. Staat er toevallig geen spatie achter die regel in de passwd file ?

[Verwijderd]

Mark schreef op 09 januari 2003 @ 11:12:

code:

login_get_lastlog: Cannot find account for uid 1012

Ik vermoed een rotte passwd file. Staat er toevallig geen spatie achter die regel in de passwd file ?

nop, ik heb ook al een backup van passwd teruggezet, en account opnieuw aangemaakt. Maar ik kan ook inloggen met telnet...... dus account is in orde... Alle encrypted passwords willen dus niet ... SSH & FTP ... plain passwords dus wel : telnet & pop3...

[Mark]

FTP password is ook niet encrypt, dus het probleem ligt niet specifiek bij encryptie. Start je telnet en POP3 vanuit inetd en SSH en FTP als standalone ?

[Verwijderd]

Mark schreef op 09 January 2003 @ 13:38:
FTP password is ook niet encrypt, dus het probleem ligt niet specifiek bij encryptie. Start je telnet en POP3 vanuit inetd en SSH en FTP als standalone ?

POP3, telnet en FTP worden van uit xinetd gestart, SSH is standalone ja.

[Mark]

Verwijderd schreef op 09 January 2003 @ 14:23:
[...]


POP3, telnet en FTP worden van uit xinetd gestart, SSH is standalone ja.

code:

./configure --with-quotas --with-virtualhosts --without-inetd

Volgens mij heb je hem FTP dan sowieso al op de foute manier gecompileerd. Als je --without-inetd doet dan heb je geen support meer voor super-servers (wat xinetd ook gewoon is).

Wat gebeurd er trouwens als je probeert in te loggen als een andere user (dus niet met uid 1012) ? Wat voor meldingen krijg je dan als je sshd in debug mode draait en probeert in te loggen met ssh -v -v -v.

[Verwijderd]

Mark schreef op 09 januari 2003 @ 14:44:
[...]

code:

./configure --with-quotas --with-virtualhosts --without-inetd

Volgens mij heb je hem FTP dan sowieso al op de foute manier gecompileerd. Als je --without-inetd doet dan heb je geen support meer voor super-servers (wat xinetd ook gewoon is).

Wat gebeurd er trouwens als je probeert in te loggen als een andere user (dus niet met uid 1012) ? Wat voor meldingen krijg je dan als je sshd in debug mode draait en probeert in te loggen met ssh -v -v -v.

ik wilde pureftpd ook standalone. Ik draai na het probleem de oude installatie van proftpd, deze wel vanuit xinetd.

Andere user geeft zelfde result. En voor de debug meldingen, zie boven.

[Verwijderd]

Verwijderd schreef op 08 januari 2003 @ 18:12:
Waarschijnlijk gebruikt pureftpd /etc/passwd en dergelijke files en heeft die aangepast aan z'n users ofzo. Je kunt beter een ftpd gebruiken die een eigen passwd en group file heeft zoals glftpd. http://www.glftpd.com

PureFTPd gebruikt meerdere authenticatie methodes.

Dit is uit mijn pure-ftpd.conf:

code:

# LDAP configuration file (see README.LDAP)

LDAPConfigFile                  /etc/pureftpd-ldap.conf


# MySQL configuration file (see README.MySQL)

# MySQLConfigFile               /etc/pureftp-mysql.conf


# Postgres configuration file (see README.PGSQL)

# PGSQLConfigFile               /etc/pureftp-pgsql.conf


# PureDB user database (see README.Virtual-Users)

# PureDB                        /etc/pureftpd.pdb


# Path to pure-authd socket (see README.Authentication-Modules)

# ExtAuth                       /var/run/ftpd.sock


# If you want to enable PAM authentication, uncomment the following line

# PAMAuthentication             yes


# If you want simple Unix (/etc/passwd) authentication, uncomment this

# UnixAuthentication            yes

[ontopic]my thoughts: deze moet aan, de rest uit. PAM iig uit, Slack heeft geen PAM![/ontopic]

# Please note that LDAPConfigFile, MySQLConfigFile, PAMAuthentication and
# UnixAuthentication can be used only once, but they can be combined
# together. For instance, if you use MySQLConfigFile, then UnixAuthentication,
# the SQL server will be asked. If the SQL authentication fails because the
# user wasn't found, another try # will be done with /etc/passwd and
# /etc/shadow. If the SQL authentication fails because the password was wrong,
# the authentication chain stops here. Authentication methods are chained in
# the order they are given.

[Verwijderd]

Geen idee hoe het is gekomen, maar ergens zijn m'n

/etc
/usr
/usr/bin
/usr/sbin
/sbin
/usr/local/bin
/usr/local/sbin

chmod 700 geworden.... vreselijk vaag... ik weet dat ik het niet geweest ben, en me collega is op vakantie ... nu is het wel opgelost! mijn dank voor jullie hulp!

[ Voor 11% gewijzigd door Verwijderd op 09-01-2003 16:25 ]

[Verwijderd]

ROFLMAO, vergeet niet die collega een schop te geven