Nach sshd_config werden änderungen nicht übernommen

Mordor

Mordor

Registered User
Hallo zusammen

Nachdem ich mich hier im Forum zu diesem Thema schon mal durchgwühlt hab, weiß ich jetzt nicht weiter!

Folgendes Problem:
Ich hab nen vServer von 1und1 mit Suse 9.3 und deaktiviertem Plesk. Jetzt wollte ich anfangen, dass System abzusicher. Habe deshalb in der sshd_config Änderungen gemacht, so dass kein Zugriff über den User root mehr erstellt werden kann, und dass nur noch ein bestimmter User auf den Server über SSH zugreifen kann. Die Änderungen wurden in VI gespeichert und danach mit /etc/init.d/sshd restart der ssh neu gestartet.

Nachdem Neustart kann ich mich aber immer noch über root und dem dazugehörigen Passwort anmelden, was ja eigentlich nicht gehen sollte.

Nachfolgend die sshd_config:
Code: 
Port 22
Protocol 2
#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 1h
#ServerKeyBits 768

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

# Authentication:

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
AllowUsers (meinuser)
RSAAuthentication no
#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 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
 # and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM no

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

# 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

Die Frage ist, ob mir jemand weiter helfen kann, und woran das Problem liegen könnte.

Danke schon mal

Gruß Mordor
 
So, ich hab jetzt nochmal ein bishcien gesucht, und auch was gefunden. Anscheinend ist es so, dass man einfach den vServer neu starten muss.

Warum das so ist, kann ich mir irgendwie nicht erklären, denn eigentlich müsste es ja auch gehen, indem man einfach /etc/init.d/sshd restart aufruft, anstatt den Kompletten Server einmal runter und wieder hoch zu fahren.

Kennt jemand vieleicht das Problem, und weis warum das so ist?

Gruß Mordor
 
Um ehrlich zu sein, nein. Habe selber einen vServer von Strato, Suse 9.3 und er liest bei mir die Config von SSH bei jedem sshd restart neu ein.

Prüfe doch mal ob nach dem restart noch eine ssh instanz läuft (ps aux | grep ssh)

Grüße
Sinepp
 
Sinepp said:
Prüfe doch mal ob nach dem restart noch eine ssh instanz läuft (ps aux | grep ssh)
Click to expand...
Mindestens einen bringt das zum Vorschein. Nämlich den, mit dem man schaut und den SSHd neu gestartet hat.
Und die letzte Shell sollte man auf keinen Fall schließen, bevor man nicht die sichere Funktion der geänderten Config geprüft hat. Sonst sperrt man sich evtl. versehentlich aus.

Es gibt ne Menge Foren-Postings zum Thema "SSHd nach Config und Restart nicht erreichbar"...
 
...ich hätte vielleicht sagen sollen: Eine "alte" SSH Instanz...

Aber tatsächlich helfen hier vermutlich in diesem Forum bereits angelegte Threads zum Thema weiter.

Grüße
Sinepp
 
Danke das Problem hat sich ja erst mal gelöst.

Mich würde einfach nur interessieren, warum er es erst nach dem neustart macht. Aber das scheint aussichtslos, denn wenn ich sshd wirklich neu starte, sehe ich auch nach der abfrage mit ps aux keinen doppelten eintrag. Vieleicht ist das ja nur ne Eigenart von 1und1.

Gruß und danke erst mal
Markus
 
Mordor said:
Vieleicht ist das ja nur ne Eigenart von 1und1.
Click to expand...
Ich hab mal mir weg gesprochen, der auch nen 1&1-Server hatte.
Bei dem wurde gar nichts angewendet, was er in der sshd-Config eingestellt hatte.
Lösung des Rätsels war dann, dass er einen SSH-Zugang von 1&1 benutzt hat, der auf einem Terminal-Server raus kam und der dann auf COM1 seiner Kiste eine serielle Konsole connected hat.

Den ganzen Server muss man jedenfalls nicht extra neu starten, damit $daemon seine Config neu einliest.
 
Ich sag auf jendenfall erst mal danke.

Woher das Problem mit dem Server neu starten kommt, weiß ich auch nicht. Ich kann nur sagen, dass ich nachdem ich die config geändert habe, und denn sshd neu gestartet hatte, nur einen Eintrag hatte als ich mit ps und pstree abgefragt habe, was ja eigentlich darauf schlissen lässt, der sshd anständig beendet wurde und auch wieder sauber neu gestartet wurde.
Danach hab ich mich im I-net schlau gemacht, und die Problemlösung war den Server neu zu Booten. Gelesen getan, und schon hats funktioniert. Komisch!

Aber Danke nochmal für die Antworten.
 
You must log in or register to reply here.
Back
Top