ssh "root" wird sofort gekickt !!!!!!!!!!

**zyrusthc** · 09.08.04, 12:02

Hallo

Ich habe ein kleines Problem ,
Einen Localen Debian Server mit OpenSSH_3.4
Das einloggen klappt alles super , aber nur als User.
Wenn ich mich als root einlogge werde ich sofort wieder rausgeschmissen

b.s.p.
[root@server .ssh]# ssh -X -l root 192.168.1.4
root@192.168.1.4's password:
Connection to 192.168.1.4 closed.
[root@server .ssh]#

Kann mir jemand nen Tip geben, warum das nur als User geht ?!

**HEMIcuda** · 09.08.04, 12:04

Alter, voll krass !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1111111 1111111111111111
Warum schickst Du auch Dein root-Passwort uebers Netz? Debian hat da
vollkommen recht, Dich abzublocken. Sowas macht man einfach nicht.

'cuda

**r2k** · 09.08.04, 12:04

Zitat von zyrusthc

Hallo

Ich habe ein kleines Problem ,
Einen Localen Debian Server mit OpenSSH_3.4
Das einloggen klappt alles super , aber nur als User.
Wenn ich mich als root einlogge werde ich sofort wieder rausgeschmissen

b.s.p.
[root@server .ssh]# ssh -X -l root 192.168.1.4
root@192.168.1.4's password:
Connection to 192.168.1.4 closed.
[root@server .ssh]#

Kann mir jemand nen Tip geben, warum das nur als User geht ?!

Poste mal deine sshd_config

**L00NIX** · 09.08.04, 12:26

Ist evtl. in /etc/ssh/sshd_config PermitRootLogin auf no gesetzt?

**Svenny** · 09.08.04, 12:49

ich würds auch auf no lassen..

**L00NIX** · 09.08.04, 13:53

Zitat von Svenny

ich würds auch auf no lassen..

Diese Frage ist schon oft hier diskutiert worden und keiner hat eine wirklich gute Begründung gegeben, warum man eben dieses machen sollte.

Ich sehe kein Problem, den root-Login offen zu lassen, solange man entweder ssh nach innen (Intranet) beschränkt und/ oder das root Passwort gut genug wählt.

**Pingu** · 09.08.04, 14:01

Zitat von L00NIX

Diese Frage ist schon oft hier diskutiert worden und keiner hat eine wirklich gute Begründung gegeben, warum man eben dieses machen sollte.

Ich sehe kein Problem, den root-Login offen zu lassen, solange man entweder ssh nach innen (Intranet) beschränkt und/ oder das root Passwort gut genug wählt.

Vielleicht um eine zusätzliche Hürde auf dem Weg zum root zu haben?

Pingu

**mbo** · 09.08.04, 14:23

Zitat von L00NIX

Diese Frage ist schon oft hier diskutiert worden und keiner hat eine wirklich gute Begründung gegeben, warum man eben dieses machen sollte.

Ich sehe kein Problem, den root-Login offen zu lassen, solange man entweder ssh nach innen (Intranet) beschränkt und/ oder das root Passwort gut genug wählt.

Du willst eine gute Begründung?
root sollte grundsätzlich, wenn überhaupt, nur von physikalischen Consolen zugriff haben, weil root dummerweise alles darf.
Ist wie mit dem Haustürschlüssel, warum sollte ich net alle Schlüssel, inklusive Banksafe, nicht unter der Fußmatte deponieren? Oder noch schlimmer: Stell Dir vor, Dein Chef gibt Dir den Generalschlüssel für die Firma und Du schleppst ihn immer mit ...
Ob Du es tust, ist Deine eigene Entscheidung.
Außerdem: wenn root nur physikalische Zugriffe hat, muß jede root-shell ergo per su kommen - kann man für Systemüberwachung nutzen: wenn keiner der erlaubten Benutzer eingeloggt ist, kann es auch keine rootshell geben.

Und warum auch ssh? Nun, ssh ist ein Dienst, der angreifbar ist.

Wenn Du natürlich jetzt eine Netzwerkkarte hast, mit eigener IP-Adresse im eigenen Subnetz am eigen Switch / NIC hängst, und der sshd nur an diesem Interface lauscht, dann ist es egal, dann kannst auch root-login ohne PW machen ...

cu/2 iae

**DJEddy** · 09.08.04, 14:56

Wenn Du natürlich jetzt eine Netzwerkkarte hast, mit eigener IP-Adresse im eigenen Subnetz am eigen Switch / NIC hängst, und der sshd nur an diesem Interface lauscht, dann ist es egal, dann kannst auch root-login ohne PW machen ...

Auch DMZ's sollen schon unerlaubt durchquert worden sein, lehrt uns Startrek ...

Davon abgesehen, wo liegt das Problem, sich nach dem User-Login mit su zu root zu befördern? Wie schon genannt, bloss eine Hürde zur sexy '#' vor dem Prompt.

Oder dem, was der User an Systemprivilegien braucht, mit sudo nachzuhelfen?

Böses PermitRootLogin no ...

Gruss Eddy

**zyrusthc** · 09.08.04, 16:40

Hier hat sich ja einiges getan ,lol

@HEMIcuda Ich sagte das ganze ist ein localer Server, der zur Info auch nicht für eine Internetverbindung gedacht ist!

Hier mal die /etc/ssh/sshd_config

Code:

# Package generated configuration file
# See the sshd(8) manpage for defails

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user (off due to PrivSep)
PAMAuthenticationViaKbdInt no
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes no

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	%h/.ssh/authorized_keys

# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts no
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding yes
PrintMotd yes
PrintLastLog yes
KeepAlive yes
UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem	sftp	/usr/lib/sftp-server
ReverseMappingCheck no
GatewayPorts no
AllowTcpForwarding yes
IgnoreUserKnownHosts no

Und die /etc/ssh/ssh_config

Code:

# Package generated configuration file
# See the sshd(8) manpage for defails

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user (off due to PrivSep)
PAMAuthenticationViaKbdInt no
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin yes
StrictModes no

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	%h/.ssh/authorized_keys

# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts no
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding yes
PrintMotd yes
PrintLastLog yes
KeepAlive yes
UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem	sftp	/usr/lib/sftp-server
ReverseMappingCheck no
GatewayPorts no
AllowTcpForwarding yes
IgnoreUserKnownHosts no

Hoffe jetzt kann mir jemand weiter helfen

Über die Sicherheit brauch ich mir wie gesagt bei diesen Server keine Gedanken machen.
Hauptsächlich geht es mir um das X11Forwarding , dies als root zu nutzen.

Ich kann mich ja als normaler User einloggen dort funktioniert das X11Forwarding ,und wenn ich dann mir "su" zum root wechsle geht es nicht mehr ! Gibt es da ne möglichkeit ?

gruss
Oli

**L00NIX** · 09.08.04, 17:52

Zitat von mbo

Du willst eine gute Begründung?
root sollte grundsätzlich, wenn überhaupt, nur von physikalischen Consolen zugriff haben, weil root dummerweise alles darf.

Korrekt, root darf alles.

Zitat von mbo

Ist wie mit dem Haustürschlüssel, warum sollte ich net alle Schlüssel, inklusive Banksafe, nicht unter der Fußmatte deponieren?

Das hinkt jetzt aber, oder meinst du ich schreibe als Welcome-Meldung hin:
"Bitte loggen sie sich als root mit dem Passwort geheim ein. Danke"

Zitat von mbo

Oder noch schlimmer: Stell Dir vor, Dein Chef gibt Dir den Generalschlüssel für die Firma und Du schleppst ihn immer mit ...

Auch dieser Vergleich hinkt...

Zitat von mbo

Ob Du es tust, ist Deine eigene Entscheidung.
Außerdem: wenn root nur physikalische Zugriffe hat, muß jede root-shell ergo per su kommen - kann man für Systemüberwachung nutzen: wenn keiner der erlaubten Benutzer eingeloggt ist, kann es auch keine rootshell geben.

Im Moment habe ich ssh nur nach innen lauschen, da ich von außen sowieso nicht dran muss, bzw. der Rechner dann nicht läuft.

Aber das mit dem zweiten Passwort als Schutz (erst normaler User, dann root-PW) ist kein Argument: Meistens wird der root-Account auf ganz andere Weise erreicht: BUGS bzw. EXPLOITS.

So gesehen, ist jede von aussen erreichbare SSH gleich gefährlich, denn ein lokaler Account reicht in den meisten Fällen aus.

**mbo** · 09.08.04, 18:21

Zitat von L00NIX

Aber das mit dem zweiten Passwort als Schutz (erst normaler User, dann root-PW) ist kein Argument: Meistens wird der root-Account auf ganz andere Weise erreicht: BUGS bzw. EXPLOITS.

Zuerst: die Vergleiche hinken weniger, als Du vermuten magst.
Es ist eben nicht so, daß die meisten root-shells/zugriffe durch Exploits oder Bugs realisiert werden.
Nun, sicher, auf einem kompromittierten System als root einzuloggen ist weniger PW-Verräterisch, als ein su -. Es ist im Endeffekt reine Ansichtssache, und es geht weniger um die Umstände, wie kann man leichter an einen root-Account kommen, sondern eher darum, wie kann man den root-Zugriff verhindern.

cu/2 iae

ps: bei mir laufen entweder keine Dienste, die ne rootshell offenbaren, oder sie können damit nicht viel anfangen. und die wenigen KernelExploits dafür, sind entweder schon gefixt, oder nicht erreichbar.

**zyrusthc** · 09.08.04, 19:15

Hallooooo

Kann mir den niemand bei meinen Problem weiterhelfen.

**IT-Low** · 09.08.04, 19:21

Zitat von zyrusthc

Ich kann mich ja als normaler User einloggen dort funktioniert das X11Forwarding ,und wenn ich dann mir "su" zum root wechsle geht es nicht mehr ! Gibt es da ne möglichkeit ?

Probiers mal mit "su -m"