SSH-Login nichtmehr möglich !

[Daether]

Moin Moin an alle,
ich habe ein Problem mit einem Debian-Server.
Der Server war relativ alt und sollte geupdatet werden ... . Trotz meiner Einwände sollte das geschehen und nu hab ich hier den Salat .

Nachdem geupdatet wurde, konnte ich mich nichtmehr neu einloggen. Weder über die Shell, noch über SSH. Nach 2maligen neusetzten des Root-Passworts ging zumindest wieder der Root-Login auf der Shell.

SSH funktioniert immernoch nicht.

Momentan taucht im auth.log immer folgendes auf :

Code: Alles auswählen

 15 08:13:53 localhost sshd[14466]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.6.129  user=root
Oct 15 08:13:55 localhost sshd[14464]: error: PAM: Authentication failure for root from 172.16.6.129

Kann mir jemand dabei helfen, den Server wieder so hinzukriegen, dass man von überalle per SSH auf den Server raufkommt ?
Ich recherchiere schon nach PAM/SSH/Debian, komme aber nicht vorwärts ...

MfG Daether

[nepos]

Was heisst alt und auf welche Version wurde denn geupdated?

[Daether]

Moin,
alt bedeutet, dass der Server mindestens 9 Monate nichtmehr geupdatet wurde.

Leider ist mir nicht bekannt, welche SSH-version vorher drauf war. Das einzige, was ich relativ sicher sagen kann, ist dass vorher kein OpenSSH installiert war.

Vielleciht hilft das folgende noch weiter :

Code: Alles auswählen

dpkg -l | grep pam
ii  libpam-modules               0.79-5                               Pluggable Authentication Modules for PAM
ii  libpam-runtime               0.79-5                               Runtime support for the PAM library
ii  libpam0g                     0.79-5                               Pluggable Authentication Modules library

Code: Alles auswählen

 dpkg -l | grep ssh
ii  openssh-blacklist            0.1.1                                list of blacklisted OpenSSH RSA and DSA keys
ii  openssh-client               4.3p2-9etch3                         Secure shell client, an rlogin/rsh/rcp repla
ii  openssh-server               4.3p2-9etch3                         Secure shell server, an rshd replacement
ii  ssh                          4.3p2-9etch3                         Secure shell client and server (transitional

[Duff]

wie sieht denn diene sshd_config auf dem Server aus?

Eventuell ist dort PermitRootLogin auf No gesetzt?

[Daether]

SSHD_config

Code: Alles auswählen

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

# 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

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 600
PermitRootLogin no
StrictModes yes

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

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# 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

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

# Change to yes to enable tunnelled clear text passwords
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 no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
KeepAlive yes
#UseLogin no

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

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes
ChallengeResponseAuthentication yes

Merkwürdig ist auch, dass einige Server eine "connection refused" kriegen wenn ich versuche von ihnen per SSH auf den Server zu kommen und andere können zumindest versuchen ein Passwort einzugeben.

[Daether]

"PermitRootLogin no" ist der Fehler ...
Hab den Wert auf "yes" gestellt, nun ist das einloggen wieder möglich ...
*Hand vor Kopf klatsch und aus Hektik-/Kopflosmodus auslogge*

[ScyTheMan]

"PermitRootLogin no" ist der Fehler ...

Nein, das ist bestimmt kein Fehler. Root-Logins per SSH sollte man nicht erlauben, das Sicherheitsrisiko ist viel zu hoch.

[uname]

Der Server war relativ alt und sollte geupdatet werden ... . Trotz meiner Einwände sollte das geschehen und nu hab ich hier den Salat

alt bedeutet, dass der Server mindestens 9 Monate nichtmehr geupdatet wurde.

Aber du weissst schon wie man einen Server korrekt pflegt? Du hattest Einwände gegen Sicherheitsupdates und hast 9 Monate keine Sicherheitsupdates instaliert? Oder hast du versucht zu upgraden auf eine andere Version (Sarge->Etch, Etch->Lenny)?

Schau dir den openssl-Bug an vom Mai an: http://www.debian.org/security/2008/dsa-1571 an. Macht schon wohl mal Sinn Sicherheitsupdates zu installieren. Lese zudem regelmäßig http://security.debian.org

[Daether]

Generell weiß ich, dass man direkten SSH-Root-Zugriff nicht erlauben sollte und das Sicherheitslücken durch updates geschlossen werden müssen ist mir acuh bewusst.

Allerdings wird der Server nur im internen Netzwerk für Samba genutzt.
Updates hätte ich definitiv erst durchgeführt, wenn ich genau wüsste, auf welchem Stand der Server ist und wenn Backups existieren !

Glaubt mir, Spass macht es mir nicht so zu arbeiten, wie es von meiner Firma gefordert wird, bzw. standard ist.

[uname]

Allerdings wird der Server nur im internen Netzwerk für Samba genutzt.

Alles klar. Und die Windows-Rechner des gleichen "internen Netzwerks" sind alle auch intern und haben somit auch keine aktuellen Virensignaturen?

[Duff]

Lege dir doch einen extra Benutzer oder Gruppe für den ssh-Zugang an und verbinde dich dann damit zum Server.
Dort kannst du ja dann ein su zum root-User machen.

[roth]

Grüß Gott,

das ist _der_ Weg und deswegen sind ja die Logins für Root aus der Schachtel heraus für SSH ausgeschaltet.
Für diejenigen, die dazu nicht das Root-Paßwort herausgeben, gibt es dann "sudo", was wiederum sehr fein granuliert konfiguriert werden _kann_ und nicht den "su"-Rundumschlag mit allen Rechten für alle Programme erfordert.

Gruß
Sven