Neuer Benutzer und Rootlogin verbieten

[Mario1981]

Hallo

und zwar suche ich schon die ganze Zeit verzweifelt nach einer Lösung.

Zu meinem Problem:

Ich will bei meinem Vserver denn Rootlogin verbieten, also erstmal mit Putty verbinden und als root einen neuen Benutzer angelegt.

useradd -g users -d /home/benutzer -s /bin/bash benutzer

dann Passwort gesetzt

passwd benutzer

So nun hab ich ein neuese Fenster aufgemacht in Putty und nun werde ich gefragt

login as:

gebe meinen Namen ein und danach das Passwort.

So das Problem ist, das ich jedes mal ein Access denied vor den Kopf bekomme.

Name und Passwort stimmen zu 100%

Ich hab schon im Netz geschaut aber was wirklich brauchbares finde ich nicht.
Ich weiß nicht an was es noch liegen kann.

Alles andere klappt wunderbar Apache2, Mysql, ispcp usw. nur diese Problem bekomme ich nicht in denn Griff.

Wäre für jede Hilfe dankbar

Gruss
Mario1981

 

[voodoo44]

Sollte ein simples

useradd username

nicht ausreichen?
Eventuell schmeißt er was mit den Parametern bei dir durcheinander? Ich habe es bisher immer so gemacht und da hat auch alles so funktioniert, wie es sollte.

 

[Mario1981]

Das hab ich natürlich auch schon probiert.

Selbes Ergebniss --> Access denied

 

[elias5000]

Schau mal im logfile nach, in das pam loggt, was dort beim Login-Versuch aufläuft und poste die Zeilen.

Schreib auch mal, welche Distribution du hast. Der Name des Logfile ist bei den Distibutionen abweichend.
Bei CentOS ist er z.B. /var/log/secure

 

[Mario1981]

Hab Debian 5.

Wenn du mir jetzt noch sagst wo ich die zu suchende Logfile finde dann poste ich die sofort.

Weil ich finde jetzt nicht wirklich was brauchbares.

/var/log/auth.log die eventuell???

 

[elias5000]

Ja, die müsste es sein.

 

[Mario1981]

Ok hab jetzt mal einen neuen Benutzer hinzugefügt und hab dann versucht mich anzumelden.

Das steht dann in der auth.log

CRON[23977]: pam_unix(cron:session): session opened for user www-data by (uid=0)
CRON[23977]: pam_unix(cron:session): session closed for user www-data
groupadd[26520]: new group: name=testuser, GID=1000
useradd[26532]: new user: name=testuser, UID=1001, GID=1000, home=/home/testuser, shell=/bin/bash
passwd[26543]: pam_unix(passwd:chauthtok): password changed for testuser
chfn[27744]: changed user `testuser' information
CRON[9430]: pam_unix(cron:session): session opened for user www-data by (uid=0)
CRON[9443]: pam_unix(cron:session): session opened for user smmsp by (uid=0)
CRON[9452]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[9465]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[9478]: pam_unix(cron:session): session opened for user root by (uid=0)
CRON[9430]: pam_unix(cron:session): session closed for user www-data
CRON[9452]: pam_unix(cron:session): session closed for user root
CRON[9465]: pam_unix(cron:session): session closed for user root
CRON[9465]: pam_unix(cron:session): session closed for user root
CRON[9478]: pam_unix(cron:session): session closed for user root
CRON[9443]: pam_unix(cron:session): session closed for user smmsp

Gibt es einen Befehl wie man sich alle User auflisten kann, muss mal bestimmt paar löschen??

Gruss
Mario

 

[elias5000]

Ich sehe da gar keinen Eintrag von sshd im Log-Auszug. Und auch keinen sonstigen Login-Versuch. Wir reden hier doch über SSH-Login, oder?

 

[Artimis]

Poste mal bitte den entsprechenden Eintrag aus der /etc/passwd.

Btw: die Funktion "root-Login verbieten" wurde nicht für entfernte Server geschaffen. Denn dort ist es i.d.R. eher ein Sicherheitsloch denn eine Sicherheit, sich mit unprivilegiertem User anzumelden und für jeden Befehl (bis auf die elementarsten, aber selbst bei einem "cd" muss ein "sudo" fällig sein, sonst ist es definitiv ein Sicherheitsleck) ein "sudo" verwenden zu müssen.
Die Funktion ist für Desktop-Rechner, die nebenher gefernwartet werden. Im Prinzip heute also out of time.

 

[Glamdring]

Btw: die Funktion "root-Login verbieten" wurde nicht für entfernte Server geschaffen. [...] Die Funktion ist für Desktop-Rechner, die nebenher gefernwartet werden. Im Prinzip heute also out of time.

Heute ist es also state of the art auf Servern herumzurooten? Deine kruden Ansichten beruhen auf wieviel Jahren Erfahrung im IT-Security-, bzw. professionellen Administrationsumfeld?

 

[Artimis]

Heute ist es also state of the art auf Servern herumzurooten? Deine kruden Ansichten beruhen auf wieviel Jahren Erfahrung im IT-Security-, bzw. professionellen Administrationsumfeld?

Zum ersten: Ja! Zum zweiten: 6 Jahre. Und ich habe Professoren und selbstständige Webhoster im Umfeld, die dies bestätigen)

Arbeitest du nicht als root, brauchst du für jedes kleine "ls" ein sudo, denn sicher hast du mit deinen jahrelangen Erfahrungen in IT-Security... daran gedacht, dass kein Verzeichnis auch nur für einen User einsehbar ist, der nicht lesen zu können braucht. Und natürlich ist es für dich komfortabler, einfach als root ein bisschen aufzupassen, statt deinen Arbeits-User jeder Gruppe hinzufügen zu müssen, damit du überhaupt etwas am Server machen kannst.

Gegenfrage: Gibt es ein (reales*) sicherheitsleck beim Arbeiten mit root?
*) solche Dinger wie "Bei root muss man den Usernamen nicht raten beim Bruten" gelten natürlich nicht, denn mit BruteForce kann man keinen vernünftig administrierten Server knacken.



Btw: Wir entfernen uns vom Topic!

 

[elias5000]

Gegenfrage: Gibt es ein (reales*) sicherheitsleck beim Arbeiten mit root?

Ja, den Account gibt es auf jedem System.

Man kann auch root inkarnieren mit sudo (sudo su -).
Vorteil dieses Vorgehens ist, dass man sich root nur inkarniert, wenn man es wirklich braucht. (Das kommt mir persönlich btw. sehr selten vor. Normalerweise benutze ich immer sudo für den Befehl.)
Und dass man nichts sieht, stimmt so nicht. Denn entweder benutzt man einen für ein Projekt spezifischen User - der darf dann auch alles an diesem Projekt ändern. Oder man ändert an den globalen Einstellungen - und diese sind dann aber auch i.d.R. für alle lesbar (aber nicht änderbar) - und genau da kommt dann sudo ins Spiel.

Per Default als root zu arbeiten ist IMHO ganz großer Mist. Als unprivilegierter User zu arbeiten schützt auch davor, aus Versehen mit zu vielen Rechten etwas kaputt zu machen.

Man kann das auch ein bisschen als Zen-Übung betrachten. Denn Sicherheit bedeutet, dass man das least-provilege-Prinzip verinnerlicht. Und dazu gehört eben auch, nur dann als Superuser zu agieren, wenn man dies benötigt.

Back to Topic: Um das weiter zu erörtern fehlen noch Informationen dazu, wie das Login erfolgen soll. Da im Log-Auszug keine sshd-Meldungen auftauchen, besteht hier noch Klärungsbedarf.

 

[CentY]

Jop, immer als Root zuarbeiten ist in größeren Firmen oft garnicht möglich, da auf dem selben System eventuell Cryptosachen gemacht werden auf die der Admin keinen Zugriff haben soll. Deswegen kann der nur zum Beispiel den Sendmailuser administrieren usw..

 

[Mario1981]

Also noch mal von vorn um alles klar zu stellen.

Ich starte Putty gebe meine Daten ein (Ip, Port) dann Connection Typ ssh und dann Login.

So beim ersten mal kam eine Meldung mit Key usw. Hab ich mit Ja bestätigt.

So nun steht da login as:

Nehme ich die Daten die mir mein Anbieter gegeben hat komme ich ohne Probleme rein und arbeite als root.

su oder sudo brauch ich da nicht vor die Befehle setzen.

Als root angemeldet lege ich einen neuen User an, egal wie auch immer mit adduser, useradd, mit Parameter dahinter oder ohne.So alles fertig Passwort usw.

Nun starte ich Putty ein 2tes mal und mach eine neue Konsole auf. Wieder login as und diesmal mit meinem angelegten user.

Access Denied ist dann die Folge egal wie ich es auch versuche.

So hier mal die /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
bind:x:101:104::/var/cache/bind:/bin/false
fetchmail:x:102:65534::/var/lib/fetchmail:/bin/false
sshd:x:103:65534::/var/run/sshd:/usr/sbin/nologin
stunnel4:x:104:106::/var/run/stunnel4:/bin/false
smmta:x:105:107:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:106:108:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
postfix:x:108:110::/var/spool/postfix:/bin/false
polw:x:109:112:policy-weight user,,,:/var/lib/polw:/bin/false
postgrey:x:110:113::/var/lib/postgrey:/bin/false
proftpd:x:111:65534::/var/run/proftpd:/bin/false
ftp:x:112:65534::/home/ftp:/bin/false
vmail:x:1000:8:vmail-user:/home/vmail:/bin/false
vu2000:x:2000:2000:vu-master:/var/www/fcgi/master:/bin/false
ntp:x:113:114::/home/ntp:/bin/false
mysql:x:107:109:MySQL Server,,,:/var/lib/mysql:/bin/false
vu2003:x:2003:2003:virtual-user:/var/www/virtual/meineseite.org:/bin/false
mario:x:2004:100::/home/mario:/bin/bash
testuser:x:1001:1000:,,,:/home/testuser:/bin/bash

 

[Artimis]

Ja, den Account gibt es auf jedem System.

Und das bringt dem Angreifer was? Klar, er kann beim SSH-Bruten des PWs von root ausgehen. Aber das ist kein Angriff, das ist Kindergarten.

Man kann auch root inkarnieren mit sudo (sudo su -).

Ja, aber das müsstest du vor jedem Befehl machen (es sei denn, du gehst über Gruppenberechtigungen, was eine Mordsarbeit sein kann). Nehmen wir das regelmäßige Sichten der Logs: Da jedes Log einem anderen user gehört und natürlich, wie auch nicht, nur er es lesen kann, musst du für ein popeliges "tail" oder "cat" oder "nano" oder "vi" ein sudo verwenden oder jeweils mit su den User wechseln.

Per Default als root zu arbeiten ist IMHO ganz großer Mist. Als unprivilegierter User zu arbeiten schützt auch davor, aus Versehen mit zu vielen Rechten etwas kaputt zu machen.

Sorry, aber wer dubiose Scripts ausführt (wer überhaupt Scripts als root laufen lässt, die auch anders laufen) oder aus Jux Dinger wie "rm -Rf /" in die Konsole hämmert, sollte nicht mit unprivilegiertem User arbeiten, der sollte bei Wind00f bleiben. Soetwas kann nicht passieren.

Denn Sicherheit bedeutet, dass man das least-provilege-Prinzip verinnerlicht.

Das ist prinzipiell vollkommen richtig. Daher muss jede Anwendung einen eigenen, am besten gechrooteten User haben und auf Desktop-Maschinen sollte man als unprivilegierter User agieren. Wer aber einen Server administriert, macht dann doch i.d.R. Dinger, die schon mal ins System eingreifen. Und dafür sind nun einmal meistens root-Rechte nötig. Klar, wenn man mal seinen IRCd neustarten möchte, könnte man sich als irc-User einloggen, statt das Startscript mit eingebauten "su" zu werwenden. Aber selbst für basics wie Apache, mySQL und Postfix, Courier und Co benötigen root-Rechte.

Aber lass uns nicht darüber streiten.
Ich akzeptiere die Seite "kein-Root" vollkommen. Es macht auch durchaus Sinn.
Aber da ich als einziger an meinen Servern arbeite und statt eines sudos lieber ein bisschen aufpasse und natürlich weiterhin sämtlichen Applikaionen einen eigenen User verpasse, ist das Arbeiten als root der richtige Weg.




Sooo, genug gespamt, weiter gehts:
In der passwd sieht alles ganz gut aus. Das PW wird aus der /etc/shadow geholt (und ich gehe mal davon aus, dass da ein gültiger Hash steht), die Shell ist gültig.
Ich kann mir nicht erklären, warum das nicht funzen sollte.
Nur, um mal völlig sicher zu gehen: Mach mal so:

useradd -m -s /bin/bash meinuser
passwd meinuser
<dein Passwort*>
<dein Passwort*>
cat /etc/passwd | grep "meinuser"
cat /etc/shadow | grep "meinuser"
ssh meinuser@localhost -p [dein SSH-Port, default=22]
<dein Passwort*>
whoami
exit
userdel -f -r meinuser

Und poste mal die Ausgabe.
*) Bitte verwende ein temporäres Passwort. Zwar ist es zwar sehr schwierig, den hash zu knacken (praktisch unmöglich), aber ein bisschen paranoid sind wir doch alle, oder?

 

[Mario1981]

Welche Ausgabe soll ich denn posten ???

 

[Glamdring]

grep username /etc/shadow

 

[Artimis]

Welche Ausgabe soll ich denn posten ???

Am besten den gesamten Screen während des Procederes von mir oben.

 

[Mario1981]

Ok also folgendes.

ssh micha@localhost -p meinport

eingebe sagt er folgendes

ssh: connect to host localhost port mein port: Connection refused

wenn ich grep micha /etc/ shadow eingebe kommt folgendes

$1$NYKc2LVd$UmVrdhqwDcgYTH6PSA4am0:14755:0:99999:7:::

Micha ist der User denn ich mal angelegt habe.

Nach kurzer Zeit kam folgendes

Message from syslogd@ at Wed May 26 09:46:14 2010 ...
host4 kernel: unregister_netdevice: waiting for lo=ffff81014a6dd000 to become fr      ntgdorg:/#
Message from syslogd@ at Wed May 26 09:46:54 2010 ...
host4 last message repeated 4 times
Message from syslogd@ at Wed May 26 09:46:55 2010 ...
host4 kernel: unregister_netdevice: device ffff81014a6dd000 marked to leak
Message from syslogd@ at Wed May 26 09:46:55 2010 ...
host4 kernel: free_netdev: device lo=ffff81014a6dd000 leaked

das ist noch nie da gewesen was ist das???

 

[Artimis]

Nun anscheinend stimmt der SSH-Port nicht. Du gibst 2212 an, aber da kann keine Verbindung hergestellt werden.
Gib mal bitte

netstat -l

ein und poste die Ausgabe.

Die merkwürdigen Ausgaben kommen iwie von einem Problem mit dem Loopback-Adapter. Das könnte auch der Grund sein.

Die Ausgaben von

cat /etc/passwd | grep "micha"
cat /etc/shadwo | grep "micha"

sieht soweit gut aus.