PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : V-Server Linux Hilfe



Roadrunner23
24.05.11, 11:20
Hallo Leute,

Ich hab seit einiger Zeit ein großes Problem bei der Betreuung eines V-Servers. Der Kunde für den ich den Server betreue hatte bis vor 5 Monaten einen anderen Techniker welcher den Server so abgesichert hat das keiner mehr Zugriff auf die SSH bekommt um z.B. Updates zu fahren oder ähnliches.

Das Server OS ist Linux 2.6.18-028stab079.1 (bei STRATO)

Ports habe ich schon ab gescannt es sind nur die wichtigsten offen, FTP und SSH Port ist zu.

Über Plesk hier in V. 8.5 kann auch nur das Webhosting eingestellt und geändert werden.
Updates werden mit einer Fehlermeldung abgebrochen. Um nun auch Plesk 9 oder 10 zu installieren wollte ich über putty zugreifen und habe es gemerkt dass die Verbindung nicht funktioniert.

Es gibt allerdings keine Möglichkeit sich mit dem alten Techniker in Verbindung zu setzen da er verschwunden ist und keiner eine Ahnung hat wo er ist.

Nun meine Frage:
Da auf dem Server Shops und Foren laufen kann ich ihn auch nicht so ohne weiteres mal eben neu Installieren.

Gibt es evtl. über das Notfall-System / Recovery Manager die Möglichkeit die Zugriffe erst mal auf Standard zurück zu setzen? (Also Port:22 und root Login).

Hatte mir darüber schon mal die Einträge in der /etc/ssh/sshd_config und /etc/passwd angeschaut den Port 22 wieder aktiviert und gespeichert.
Nach dem normalen Start des Servers geht aber trotzdem kein Login / Verbindung über putty oder SCP
SSH (putty meldet 'Netork error: Connection refused').
Das Passwort für root lässt sich über Strato zwar belibig ändern aber wenn ich keinen Zugriff auf die Shell habe nützt mir das ja nichts.
Irgendwie sheint mir der Zugang ist komplett deaktiviert.

In den logs vom Plesk-Updater steht auch nur ...update failed.

Recovery Manager = Wird von Strato angeboten um den Server vom normal Modus in einen Rettungsystem - Modus zu booten. In diesem Modus kann ich mich normal mit root über putty anmelden und auch durch die verzeichnisse gehen. Nur gibt es für diesen login ein anderes root passwort als das was ich im normal - Modus eingerichtet habe (ist mir ja klar).

"Eintrag "PermitRootLogin" auf "yes"" = ist aktiviert.

P.S. Ich hab keine Ahnung mehr was der alte Techniker an dem System eingestellt oder verstellt hat.
Muss ich denn wirklich alle ports die es gibt abscannen???

DANKE

hiyeah
24.05.11, 11:40
wie konntest du dir die Einträge in der /etc/ssh/sshd_config und /etc/passwd angucken?

Was sind für dich wichtige Ports, wenn nicht ssh?
Mal versucht, dich mit einem User einzuloggen (Rootlogin zu verbieten, ist durchaus sinnvoll..)?

Ciao

muell200
24.05.11, 12:38
erstmal willkommen...



Das Server OS ist Linux 2.6.18-028stab079.1 (bei STRATO)


kenne ich nicht - muss neu sein - oder?




P.S. Ich hab keine Ahnung mehr was der alte Techniker an dem System eingestellt oder verstellt hat.


dann solltest du jemand suchen, der sich mit sowas auskennt!
( sorry - musste raus )

soweit ich weis, gibt es bei strato ein "hilfe" system, wo die die passwoeter und systemeinstellungen veraendern kannst...


und crossposting sieht man nicht gerne!

http://www.boerse.bz/hard-software/andere-betriebssysteme/linux/774172-v-server-linux-hilfe.html

hiyeah
24.05.11, 13:13
kenne ich nicht - muss neu sein - oder?

Nein, eher alt.

muell200
24.05.11, 13:30
Nein, eher alt.

ja - das sollte ein witz sein :)
bzw. es gibt kein linux 2.6....

kreol
24.05.11, 16:05
bzw. es gibt kein linux 2.6....Sicher? Es gibt kein SuSE 2.6 und kein Linux 11.4, aber den Kernel und das OS anzugeben ist durchaus richtig und üblich.

@TE: Hinweise, wie Du auf einen Server kommst, dessen Konfiguration und PW Du nicht kennst wirst Du hier wohl kaum bekommen. Am besten wendest Du Dich an Strato und weist deine Zugriffsberechtigung dort nach.

Kreol

derRichard
24.05.11, 16:21
bzw. es gibt kein linux 2.6....

so einen üblen griff ins klo habe ich schon lange nicht mehr gesehen...

//richard

muell200
24.05.11, 16:23
so einen üblen griff ins klo habe ich schon lange nicht mehr gesehen...

//richard

was ist dann das fuer ein system?

es gibt einen kernel 2.xx ....

derRichard
24.05.11, 16:27
was ist dann das fuer ein system?

es gibt einen kernel 2.xx ....

es heisst linux 2.6.x.
zb:
https://lkml.org/lkml/2011/5/19/16

aber du kannst linus gerne eine mail schreiben, wie es richtig heisst. ;P

//richard

muell200
24.05.11, 16:31
es heisst linux 2.6.x.
zb:
https://lkml.org/lkml/2011/5/19/16

aber du kannst linus gerne eine mail schreiben, wie es richtig heisst. ;P

//richard

falsch ausgedruckt: linux distribution

DrunkenFreak
24.05.11, 17:37
Da ja eh schon Offtopic ist und man es nicht oft genug wiederholen kann:

Schaff dir keinen Server an, wenn du keine Ahnung davon hast. Du solltest den Auftrag abgeben.

Roadrunner23
25.05.11, 11:55
Ich dachte das ist ein Linux-Forum wo man Hilfe bekommt und nicht gleich für 'bekloppt' hingestellt wird.
Wenn ich mit Hilfe von Strato das Problem gelöst bekommen hätte würde ich hier nicht schreiben.
Ich will hier auch keine Anleitung zum 'hacken' oder ähnliches.
Es ist mit KEINEM Benutzer möglich sich auf der Konsole anzumelden. Den Inhalt der Dateien kann ich mir anschauen wenn ich das System im Rettungs-Modus boote.
Aber egal, ich habe einen 2. Server bestellt und ziehe mit dem Inhalt des alten Servers um. Der alte wird dann gekündigt. Mein Kunde ist damit einverstanden.

kreol
25.05.11, 12:23
Wenn Dein Vorgänger alles zugemacht hat und ohne eine Dokumentation zu hinterlassen verschwunden ist, wird es ohne Zurücksetzen des Servers ziemlich schwer. Und da ist der Provider nunmal ein besserer Ansprechpartner.

Ports hast Du gescannt und 22 ist zu. Ivm connection refused klingt das sehr nach iptables. Und ohne Zugriff auf den Rechner wirst Du da wenig ausrichten.

Da Du bereits in der sshd_config gewerkelt hast: Weisst Du noch, was da vorher drinstand? Wäre evtl. für eine Rückverfolgung interessant. Wirf auch mal einen Blick in die /etc/hosts.allow und /etc/hosts.deny.

Und ganz grundsätzlich: Eine Dateiausgabe sagt mehr als 1000 schöne Worte. Wenn Du die Dateien über das Rettungssystem lesen (und sogar editieren) kannst sollte ein c&p hierher auch möglich sein.

Du bist aber auch nicht der erste, der sich aus dem eigenen V auf diese Weise aussperrt. Würde mich wundern, wenn Strato da keine Möglichkeiten hätte, sofern man seine Berechtigung nachweist. Womit wir wieder am Anfang wären...

Kreol

Roadrunner23
25.05.11, 12:39
Mein Kunde habe ich gesagt er solle dieses Problem nocheinmal an Strato senden.

hosts.allow


# /etc/hosts.allow
# See 'man tcpd' and 'man 5 hosts_access' for a detailed description
# of /etc/hosts.allow and /etc/hosts.deny.
#
# short overview about daemons and servers that are built with
# tcp_wrappers support:
#
# package name | daemon path | token
# ----------------------------------------------------------------------------
# ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port>
# quota | /usr/sbin/rpc.rquotad | rquotad
# tftpd | /usr/sbin/in.tftpd | in.tftpd
# portmap | /sbin/portmap | portmap
# The portmapper does not verify against hostnames
# to prevent hangs. It only checks non-local addresses.
#
# (kernel nfs server)
# nfs-utils | /usr/sbin/rpc.mountd | mountd
# nfs-utils | /sbin/rpc.statd | statd
#
# (unfsd, userspace nfs server)
# nfs-server | /usr/sbin/rpc.mountd | rpc.mountd
# nfs-server | /usr/sbin/rpc.ugidd | rpc.ugidd
#
# (printing services)
# lprng | /usr/sbin/lpd | lpd
# cups | /usr/sbin/cupsd | cupsd
# The cupsd server daemon reports to the cups
# error logs, not to the syslog(3) facility.
#
# (Uniterrupted Power Supply Software)
# apcupsd | /sbin/apcupsd | apcupsd
# apcupsd | /sbin/apcnisd | apcnisd
#
# All of the other network servers such as samba, apache or X, have their own
# access control scheme that should be used instead.
#
# In addition to the services above, the services that are started on request
# by inetd or xinetd use tcpd to "wrap" the network connection. tcpd uses
# the last component of the server pathname as a token to match a service in
# /etc/hosts.{allow,deny}. See the file /etc/inetd.conf for the token names.
# The following examples work when uncommented:
#
#
# Example 1: Fire up a mail to the admin if a connection to the printer daemon
# has been made from host foo.bar.com, but simply deny all others:
# lpd : foo.bar.com : spawn /bin/echo "%h printer access" | \
# mail -s "tcp_wrappers on %H" root
#
#
# Example 2: grant access from local net, reject with message from elsewhere.
# in.telnetd : ALL EXCEPT LOCAL : ALLOW
# in.telnetd : ALL : \
# twist /bin/echo -e "\n\raccess from %h declined.\n\rGo away.";sleep 2
#
#
# Example 3: run a different instance of rsyncd if the connection comes
# from network 172.20.0.0/24, but regular for others:
# rsyncd : 172.20.0.0/255.255.255.0 : twist /usr/local/sbin/my_rsyncd-script
# rsyncd : ALL : ALLOW
#

sshd.config


# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker 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
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# 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 3600
#ServerKeyBits 768

# Logging
# obsoletes QuietMode and FascistLogging
SyslogFacility AUTH
LogLevel INFO

# Authentication:

LoginGraceTime 120
PermitRootLogin no
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 no
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 support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no


# 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 no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

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

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

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


hosts.deny


# /etc/hosts.deny
# See 'man tcpd' and 'man 5 hosts_access' as well as /etc/hosts.allow
# for a detailed description.

http-rman : ALL EXCEPT LOCAL

Wene
25.05.11, 14:07
sshd.config


...
# Authentication:

LoginGraceTime 120
PermitRootLogin no
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 no
PermitEmptyPasswords no




Gemäss dieser Konfiguration ist eine Anmeldung als root generell verboten. Ausserdem ist es verboten, sich mit Passwort zu authentifizieren. Stattdessen werden Zertifikate verwendet.

Du kannst jetzt also entweder diese Zeilen in der Konfiguration anpassen und den SSHd neu starten oder ein entsprechendes Zertifikat verwenden.