Kein Root-Zugang mehr

Hans Maulwurf

Hans Maulwurf

New Member
Ich habe auf meinen vServer keinen Root-Zugriff mehr. Weder per FTP noch über Plesk. Als normaler Benutzer habe ich FTP- und Plesk-Zugang auf den Server (natürlich nicht so tief). Weder das Zurücksetzen der Root-Passwortes, noch der Recovery-Boot, mit Bearbeiten von ssh2_config ("AllowUser admin root" und "PermitRootLogin yes") im recovery-Verzeichnis haben geholfen. Was muss ich an der Konfiguration des SSH-Clients oder sonst wo ändern? :confused:
 
Ohne Panik machen zu wollen aber wenn man plötzlich keinen Rootzugang mehr hat, könnte es sich um einen Hack handeln. Von alleine passiert so etwas jedenfalls nicht. Abgesehen davon sollte es mit SSH nur peripher zu tun haben, da Du ja scheinbar selbst in Plesk nicht mehr reinkommst?
 
Last edited by a moderator:
Hans Maulwurf said:
Ich habe auf meinen vServer keinen Root-Zugriff mehr. Weder per FTP noch über Plesk.
Click to expand...

Per FTP solltest Du auch definitiv keinen Root Zugang haben, da hier das Rootpasswort unverschlüsselt über die Leitung geht. Eine sichere Möglichkeit ist SSH, auf der Konsole wie auch mit dateibasierten Programmen wie WinSCP.

Weder das Zurücksetzen der Root-Passwortes, noch der Recovery-Boot, mit Bearbeiten von ssh2_config ("AllowUser admin root" und "PermitRootLogin yes") im recovery-Verzeichnis haben geholfen. Was muss ich an der Konfiguration des SSH-Clients oder sonst wo ändern? :confused:
Click to expand...

Kann es sein, dass Du die SSH Änderungen in den jeweiligen Verzeichnissen im Recoverysystem, nicht aber im eigentlichen System gemacht hast? Hast Du überhaupt nach dem Recovery System resettet / neu gestartet?
 
Thunderbyte said:
Per FTP solltest Du auch definitiv keinen Root Zugang haben, da hier das Rootpasswort unverschlüsselt über die Leitung geht. Eine sichere Möglichkeit ist SSH, auf der Konsole wie auch mit dateibasierten Programmen wie WinSCP.



Kann es sein, dass Du die SSH Änderungen in den jeweiligen Verzeichnissen im Recoverysystem, nicht aber im eigentlichen System gemacht hast? Hast Du überhaupt nach dem Recovery System resettet / neu gestartet?
Click to expand...

Die Änderungen habe ich in "meinen" gesichertem ssh2_config-File gemacht und nicht im ssh2_config-File des Recovery-Systems. Nach dem Recovery habe ich den Server natürlich wieder neu gestartet.

Streiche oben "FTP" setze "SFTP via SSH2"
 
Last edited by a moderator:
Thunderbyte said:
Das ist ein Riesenunterschied! ;) Aber so passts ja.

Geht denn SSH generell noch? D.h. kannst Du Dich als Nicht-Root SSH User per Konsole (Putty) einloggen? Dann kannst Du Dich ja auch per "su" zum Root machen.
Click to expand...

Nö, als Nicht-Root-User komme ich nicht per PuTTy rein, nur per PLESK und FTP.
 
sbr2d2 said:
Poste doch mal die sshd.conf. Vielleicht kann man da etwas erkennen.
Click to expand...
Kein Problem. Hier die sshd_config:

# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
AllowUsers admin root
#StrictModes yes
MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

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

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

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 3
ClientAliveCountMax 10
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
PermitTunnel yes

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
 
Kannst Du bitte für die Zukunft solche Sachen in Code-tags packen. Läßt sich dann so besser lesen.

Beispiel:
Code: 
# $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
AllowUsers admin root
#StrictModes yes
MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys

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

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

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 3
ClientAliveCountMax 10
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
PermitTunnel yes

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/libexec/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

Hmm...frage an die Fachleute. Wenn der Port nicht kommentiert wird, läuft der ssh dann Standard auf Port 22. Ich würde jetzt zum testen den Port erst mal wieder mit angeben.
 
Naja, das wäre logisch, da er ansonsten gar nicht soweit hätte connecten können, er wäre nicht einmal bis zum SSH login vorgedrungen.
 
Last edited by a moderator:
Hmm. Ich würde ja mal vermuten, dass der SSH Daemon aus irgendwelchen Gründen gar nicht läuft. Gibts da über Plesk irgendeine Möglichkeit den Dienst zu starten oder zu kontrollieren ob er läuft? Über FTP geht da ja schonmal nichts.
 
Darf man fragen, woher die ominöse ssh2_config stammt und wofür sie zuständig sein soll?
OpenSSH verwendet standardmässig nämlich:
Server: /etc/ssh/sshd_config
Client: /etc/ssh/ssh_config
 
Bin ich eigentlich der Einzige, der es verdächtig findet, dass er auch in Plesk nicht mehr als Root(admin) einloggen kann?

Ok, gut, vielleicht bin ich nur paranoid aber für mich klingt das erst einmal danach paranoid zu werden.
 
Thunderbyte said:
Hmm. Ich würde ja mal vermuten, dass der SSH Daemon aus irgendwelchen Gründen gar nicht läuft. Gibts da über Plesk irgendeine Möglichkeit den Dienst zu starten oder zu kontrollieren ob er läuft? Über FTP geht da ja schonmal nichts.
Click to expand...
In Plesk gibt es ein SSH-Terminal, das aber in meinem Fall nicht funktioniert. Das mit dem SSH-Daemon ist schon sehr verdächtig. Im Recovery-Mode komme ich ja überall hin, nur ich habe keinen Plan mehr was wo zu tun ist, dass der Daemon läuft.
 
Marentis said:
Ok, gut, vielleicht bin ich nur paranoid aber für mich klingt das erst einmal danach paranoid zu werden.
Click to expand...

- Paranoia ist nur ein anderer Begriff für erhöhte Wachsamkeit -


Also wenn er definitiv nicht läuft, und man nicht mehr in den Server reinkommt/einloggen kann, auch nicht per Admin-Software, würde ich schon fast sagen: Server per Menü in der Serverprovider-Seite neustarten und dann im Rescue-System, starten lassen. Hierbei müsste man dann einen chroot ins System machen, dort sshd ins runlevel adden. Anschließend aus der chroot-Umgebung wieder raus, umount und restart. Doch ich glaube nicht, das dies bei einem vServer geht. Zumindest beim chroot nicht. Aber da will ich mich nicht festlegen.

Welche Meldung kommt denn, wenn mit PuTTY versucht wird:

Code: 
ssh 1.2.3.4
(1.2.3.4 ist durch Deine IP-Adresse zu ersetzen!!!)

Wenn dort "connection refused" kommt, und Du per PuTTY mit Port22 zugreifst, dann ist mit dem Port auf dem vServer was 'krumm'.

Ob 'Port 22' so:

Code: 
Port 22

oder so:

Code: 
# Port 22
steht, ist unerheblich. Standard (Port 22) wird auch dann verwendet, wenn die Zeile kommentiert ist.
 
Last edited by a moderator:
Wenn ich versuche über PuTTY mich mit "root" und dem initialen Rootpasswort anzumelden, erhalte ich die Fehlermeldung:
"PuTTY fatal Error - Server unexpectedly closed network connection"
Falsche Passwörter erkennt das System und meldet das auch. Mit dem "richtigen" init-Rootpasswort kommt die genannte Fehlermeldung.
Mit der Möglichkeit des Logins mit einem neu generierten initialen Rootpasswort bekomme ich ebenfalls keinen Zugang.
 
Hans Maulwurf said:
Wenn ich versuche über PuTTY mich mit "root" und dem initialen Rootpasswort anzumelden, erhalte ich die Fehlermeldung:
"PuTTY fatal Error - Server unexpectedly closed network connection"
Falsche Passwörter erkennt das System und meldet das auch. Mit dem "richtigen" init-Rootpasswort kommt die genannte Fehlermeldung.
Mit der Möglichkeit des Logins mit einem neu generierten initialen Rootpasswort bekomme ich ebenfalls keinen Zugang.
Click to expand...

Du kannst über Virtuozzo reingehen. Ich hatte mal dasselbe, weil ich meinen Port versehentlich auf was draufgeschaltet hatte. Da kannst du das Rescue machen. Das hilft. Es ist dann auch noch alles da, also keine Sorge. Die Änderungen in der sshd_config allerdings nicht mehr. Aber dann kommst du wieder auf dein System. Im Virtuozzo ist auch ein Filebrowser, der meist noch funktioniert. Vielleicht hilft das ja schon.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top