Einloggen in Debian per Putty (ssh) geht nicht mehr nach einen apt-get upgrade

Keine_Ahnung · 14. August 2008

Hallo,

ich musste (oder auch nicht?) ein apt-get upgrade machen weil ich mir da einiges zerschossen hatte.
Nu läuft alles wieder wunderbar, aber ich kann mich nicht mehr mit putty (ssh client) dort einloggen.
Beim update wurde mir auch mitgeteilt das ssh irgenwelche alten Keys zurückzieht. Gut, aber wie kann ich mich jetzt wieder dort einloggen?

Ich erinnere mich das ich damals einfach putty gestartet hatte, dann hatt er den Schlüssel vom VDR gezogen und ich konnte mich immer wunderbar einloggen.
Jetzt weist der ssh Server aber jeden Versuch ab mich einzuloggen.

Hat jemand einen Tip für mich wo ich mal schauen kann was da falsch läuft?

cu

wilderigel · 14. August 2008

authentifizierung per key datei?
laeuft ddhd denn aufn vdr?

lol, log, log

heinzelrumpel · 14. August 2008

Zitat

Original von Keine_Ahnung
Hallo,

ich musste (oder auch nicht?) ein apt-get upgrade machen weil ich mir da einiges zerschossen hatte.
Nu läuft alles wieder wunderbar, aber ich kann mich nicht mehr mit putty (ssh client) dort einloggen.
Beim update wurde mir auch mitgeteilt das ssh irgenwelche alten Keys zurückzieht. Gut, aber wie kann ich mich jetzt wieder dort einloggen?

Ich erinnere mich das ich damals einfach putty gestartet hatte, dann hatt er den Schlüssel vom VDR gezogen und ich konnte mich immer wunderbar einloggen.
Jetzt weist der ssh Server aber jeden Versuch ab mich einzuloggen.

Hat jemand einen Tip für mich wo ich mal schauen kann was da falsch läuft?

cu

Alles anzeigen

Hi,

was genau heisst, du kannst dich nicht mehr einloggen?Gibt es eine Fehlermeldung. Evtl. den Inhalt von ".ssh/known_hosts" mal löschen.

Gruß, Heinzelrumpel

NemoN · 14. August 2008

mal mit "ssh -v <host>" einloggen und posten...

mz01 · 14. August 2008

Hallo!

"Keys zurückgezogen"? Das klingt doch nach dem Debian-SSL-Schlüssel Bug oder?

http://www.heise.de/security/S…-Co--/news/meldung/107808

Beim einspielen der neuen Version von OpenSSL wurden die verwendeten Schlüssel vermutlich als von dem Problem betroffen erkannt und zurückgezogen.

In dem Fall müsste man neue Schlüssel generieren und dann sollte es wieder funktionieren.

Schöne Grüsse

Michael

geeg07 · 14. August 2008

Es ist so wie mz01 schrieb.
Die von Debian erzeugten SSH-Keys sind kompromittiert und wurden deshalb gesperrt.

In diesem Fall kannst du dich nur direkt an der Konsole anmelden, einen neuen SSH-Key erzeugen und diesen verwenden.
Da du vermutlich das Login per SSH mittels Passwort unterbunden hast, kommst du mit SSH nicht mehr an das System.

Folgende Vorgangsweise sollte dir helfen:

Login an der Konsole

Code

ssh-keygen -b 2048 -t rsa -f Name_der_Keydatei
cat Name_der_Keydatei.pub >>~/.ssh/authorized_keys

Dann die Datei Name_der_Keydatei auf dein Windowssystem kopieren (über Freigabe, oder wie auch immer), mit PuTTYgen umwandeln, über die alte Keydatei kopieren.
Sobald das Login per SSH funktioniert ~/.ssh/Name_der_Keydatei am vdr löschen.

Alternativ kannst du an der Konsole SSH-Login per Passwort in /etc/ssh/sshd_config aktivieren indem du folgende Zeile auf yes änderst

Code

#PasswordAuthentication no
PasswordAuthentication yes

und mittels /etc/init.d/ssh restart den SSH-Server neu startest.
Dann kannst du dich ohne Schlüssel mit Passwort per SSH am vdr anmelden und die Erzeugung des neuen Schlüssels per PuTTY durchführen.

Nachdem der neue Schlüssel funktioniert, änderst du in sshd_config wieder den Eintrag Passwordlogin no und führst erneut einen Neustart des SSH-Servers durch.

MarkusH · 14. August 2008

- erledigt -

Keine_Ahnung · 14. August 2008

Danke für die Antworten, ich hab jetzt mal versuch einiges Umzusetzen.

Zitat

Original von wilderigel
authentifizierung per key datei?

Mhhh, bisher gings einfach so Ich bin da echt nicht der Profi.

Bissher hab ich einfach Putty gestartet, die IP eingegeben und dann hatte ich die Shell wo ich mich als Root eingeloggt hatte.

In der Verbindungskonfiguration kann man weder Usernamen noch Password eingeben. Und bei der Keydatei die man importieren kann steht was vom Private Key. Aber nach meinem Verständnis müsste man da doch den Public Key importieren, oder?

Zitat

laeuft ddhd denn aufn vdr?

---
cd /
find -name ddhd
---

sagt nicht, also gibts ddhd wohl ganricht bei mir. Aber das hat ssh das letzte Jahr auch nicht davon abgehalten zu funktionieren.

Also, egal was ich versuche, Putty reagiert immer mit:
"Network Eroor: Connection Reset by peer"

Dabei sagt logread (Also der Versuch der Kontaktaufnahme kommt am VDR an):

Code

Aug 14 16:30:53 (none) auth.info sshd[4575]: Server listening on :: port 22.
Aug 14 16:31:58 (none) auth.err sshd[4585]: error: Host key 45:7e:af:d4:1d:79:e7:d2:66:2f:75:6b:6c:23:2f:48 blacklisted (see ssh-vulnkey(1))
Aug 14 16:31:58 (none) auth.err sshd[4585]: error: Host key 7b:e0:89:4a:ba:df:cf:98:5d:d3:14:5e:35:74:94:32 blacklisted (see ssh-vulnkey(1))

Wobei "ssh restart" mit folgender Meldung Startet:

Code

Host key 45:7e:af:d4:1d:79:e7:d2:66:2f:75:6b:6c:23:2f:48 blacklisted (see ssh-vulnkey(1))
Host key 7b:e0:89:4a:ba:df:cf:98:5d:d3:14:5e:35:74:94:32 blacklisted (see ssh-vulnkey(1))
Host key 45:7e:af:d4:1d:79:e7:d2:66:2f:75:6b:6c:23:2f:48 blacklisted (see ssh-vulnkey(1))
Host key 7b:e0:89:4a:ba:df:cf:98:5d:d3:14:5e:35:74:94:32 blacklisted (see ssh-vulnkey(1))

Das

Code

ssh-keygen -b 2048 -t rsa -f Name_der_Keydatei
cat Name_der_Keydatei.pub >>~/.ssh/authorized_keys

ändert nichts darn. Und ich vermute es kommt auch garnicht bis zu der Stelle wo das benötigt wird da er schon von vornherrein jeden Verbindungsversuch abweist.

BTW: Ist doch richtig edas ich den *.pub" Schlüssel in PuttyKeyGen importieren muß um ihn dann als Public Key zu exportieren. Dieser wird dann in Puty importiert (weil in Putty finde ich nur einen Import für einen private Key)?

Code

#PasswordAuthentication no
PasswordAuthentication yes

Folglich bringt das auch nichts.

Kann es sein das irgendetwas mit den Grundlegenden Keys nciht stimmt und ich diese neu generieren muß.

/etc/ssh enthält folgendes:

Code

\\EASYVDR\root\etc\ssh\
sshd_config	1872	2008.8.14	16:29.8
sshd_config.bak	1873	2008.8.14	15:23.48
ssh_host_dsa_key	672	2008.8.13	22:25.58
ssh_host_dsa_key.pub	602	2008.8.13	22:25.58
ssh_host_rsa_key	1679	2008.8.13	22:25.56
ssh_host_rsa_key.pub	394	2008.8.13	22:25.56
blacklist.DSA-1024	2064867	2008.5.13	16:23.20
blacklist.RSA-2048	2064867	2008.5.13	16:23.20
ssh_host_dsa_key.broken	672	2007.1.17	15:29.22
ssh_host_dsa_key.pub.broken	601	2007.1.17	15:29.22
ssh_host_rsa_key.broken	1675	2007.1.17	15:29.20
ssh_host_rsa_key.pub.broken	393	2007.1.17	15:29.20
moduli	132777	2006.12.23	21:9.10
ssh_config	1424	2006.12.23	21:9.10

Alles anzeigen

sshd_config

Code

# 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 120
PermitRootLogin yes
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 yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no


# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes


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


# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes


X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no


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


# Allow client to pass locale environment variables
AcceptEnv LANG LC_*


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


UsePAM yes

Alles anzeigen

sshd_config

Code

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.


# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.


# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.


Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Alles anzeigen

Kann ich nicht einfach mal den ganzen Schlüsselkram löschen udn eu generieren?
Oder ssh deinstallieren, das Verzeichnis löschen und neu installieren?

cu

knebb · 14. August 2008

Deine Keys sind blacklisted, weil sie von dem boesen Debian Bug befallen sind.

Gemeint sind die Host-Keys, nicht irgendwelche zum einloggen. Also hat authorized_keys damit ueberhaupt nichts zu tun.

Die aktuelle Version von ssh hat die fehlerhaften Keys erkannt und "geblacklisted", so dass sie nicht mehr verwendet werden. Dummerweise wurden allerdings keine neuen generiert.

Also entweder alles loeschen oder die Keys neu generieren. Wie das jetzt speziell in Debian ist, weiss ich nicht. Schau einfach mal in das Startskript (vmtl. /etc/init.d/sshd rein, da sollte eine Abfrage drinnen sein.

Also, host-Keys neu generieren, dann laeuft dsa auch wieder einwandfrei.

mz01 · 14. August 2008

Deinstallieren geht unter Debian folgendermaßen:

apt-get remove --purge openssh-server

Das sollte alles samt Konfiguration löschen. Und mit

apt-get install openssh-server

neu installieren. Dabei sollte der ssh-server neue Hostkeys generieren.

Keine_Ahnung · 14. August 2008

Jaaaaaaaa. Es geht

War also ne kaputte Konfig. Und ich dachte wegen dem neuen SSH ist da jetzt irgendwas grundsätzlich anderst (mehr Sicherheitsstufen, oder soetwas). Da war ich also auf dem komplett falschen Weg.

Vielen Dank an alle die hier mitgewirkt haben.

BTW: SSH laut obrigen Post deinstalliert. /etc/ssh gelöscht und neu installiert. Dann gabs ne Fehlermeldung.
Dann das /etc/ssh von der damaligen easyVDR install CD wiederhergesstellt und SSH nochmal deinstalliert und dann wieder installiert. Dann lief es (und zwar genauso einfach wie immer).

cu

Einloggen in Debian per Putty (ssh) geht nicht mehr nach einen apt-get upgrade

Jetzt mitmachen!

Teilen