• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]ssh mit public key meldet Server refused our key

Emanuele

Member
Hallo,

ich versuche von einem Linux-Server auf einen Linux-Client eine Verbindung per ssh einzurichten die ohne Passworteingabe zurecht kommt.
Dabei habe ich auf dem Server einen ssh-keygen laufen lassen und danach den erhaltenen key in die Datei authorized_keys auf dem Client eingetragen.
Der Key sieht so aus "1024 35 Kryptischer Code user@Server"
Hab versucht ein ssh-rsa davor zu schreiben hat aber nichts genutzt.
Leider konnte ich in der suche nur linux zu Windows mit putty finden nicht linux zu linux nur mit ssh aus der Konsole heraus.
Vielleicht könnt ihr mir ja helfen.


Die Rechte der authorized-keys hab ich umgestellt auf -rw------- user usergroup
Wenn ich mich verbinde wird der korrekte key verwendet "user@server" aber die RSA authentication schlägt fehl mit der Fehlermeldung Server refused our key.
 
A

Anonymous

Gast
Emanuele schrieb:
Leider konnte ich in der suche nur linux zu Windows mit putty finden nicht linux zu linux nur mit ssh aus der Konsole heraus.
Schau mal hier und gehe das alles noch mal der Reihe nach durch, irgendwo müsstest du was nicht ganz richtig gemacht zu haben.

robi
 

/dev/null

Moderator
Teammitglied
Hi Emanuele,

Emanuele schrieb:
ich versuche von einem Linux-Server auf einen Linux-Client eine Verbindung per ssh einzurichten ...
Dabei habe ich auf dem Server einen ssh-keygen laufen lassen und danach den erhaltenen key in die Datei authorized_keys auf dem Client eingetragen.

Ich glaube, du bringst hier nur die Begriffe "Server" Und "Client" durcheinander.

Server
- ist in diesem Fall der Rechner, auf welchem der sshd läuft.
- auf welchen die Clients per ssh zugreifen sollen
- welcher die Datei "~/.ssh/authorized_keys" mit den authorisierten öffentlichen Schlüsseln der anmeldeberechtigten Nutzer besitzt

Client
- ist hier der Rechner, der sich anmeldet
- hier wird das Schlüsselpaar erzeugt, der secret-key bleibt dort und der public-key wird auf dem Server in die "authorized_keys" kopiert.

Selbstverständlich kann der (ssh-)Client physisch ein Server und der (ssh-)Server physisch ein Client sein.

Meine Empfehlung: Bringe zuerst die ssh-Verbindung mit ganz normaler Passwort-Auth. zum Laufen. Dann generiere, so wie das in vielen Anleitungen ganz sauber beschrieben ist, auf dem (ssh-)Client das Schlüsselpaar und füge den public-key in die "authorized_keys" auf dem Server ein, teste es und verhindere erst wenn alles läuft in der sshd_config die Anmeldung mit Benutzername und Passwort.


MfG Peter
 
OP
E

Emanuele

Member
Danke für die Tipps.
Das Beispiel in der Wiki kann ich nicht durchführen da ich mit ssh-keygen nicht die option -t anwenden kann.
Das verwendete Linux ist Version 7.0
Der Rechner auf den ich mich verbinden möchte hat Suse 10.1

Ansonsten habe ich alles genauso wie dort beschrieben durchgeführt, ohne Erfolg. Kann es sein dass der Key nicht benutzt werden kann, wenn es nicht explizit ein RSA-Key ist?
Kann es vlt am großen Versionsunterschied liegen das es nicht klappt?
Übrigens die normale ssh Verbindung klappt wunderbar.

Ich hab den ganzen Tag versucht das hinzubiegen es klappt einfach nicht.

Kann man irgendwo angeben welche Datei zum identifizieren verwendet werden soll oder kann man das auf allgemein lassen und es wird alles durchprobiert. Bei mir sind nämlich noch weitere Keys vorhanden die scheinen aber auch nicht zu funktionieren...
Vielleicht hat der Vorgänger versucht das gleiche einzurichten und hatte ebenfalls keinen Erfolg.
Ich weiss echt nicht mehr weiter...
 

/dev/null

Moderator
Teammitglied
Die Datei zum Authentifizieren ist doch die bewusste "authorized_keys" mit dem public-key des berechtigten Nutzers.

Poste doch mal deine sshd_config. Vielleicht hilft uns das weiter. Es gibt unterschiedliche ssh-Protokolle (1 und 2), ich habe kein 7.x mehr vorliegen, kann also nicht nachschauen, ob dieses schon beide kann.
Poste auch die Versionsstände von ssh und die vollständige Ausgabe deiner Versuche mit ssh-keygen.

MfG Peter
 
OP
E

Emanuele

Member
auf dem Client läuft ssh Version OpenSSH_2.1.1, protocol versions 1.5/2.0
Auf dem Server läuft OpenSSL 0.9.8a 11 Oct 2005


Code:
#	$OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus 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,1
#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 1h
#ServerKeyBits 768

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

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#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 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 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 yes

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes 
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#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

# 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


ssh-keygen Log:
Code:
  445  Generating RSA keys:  ..............................ooooooO....ooooooO
  446  Key generation complete.
  447  Enter file in which to save the key (/home/dsadmin/.ssh/identity):
  448  /home/dsadmin/.ssh/identity already exists.
  449  Overwrite (y/n)? y
  450  Enter passphrase (empty for no passphrase):
  451  Enter same passphrase again:
  452  Your identification has been saved in /home/dsadmin/.ssh/identity.
  453  Your public key has been saved in /home/dsadmin/.ssh/identity.pub.
  454  The key fingerprint is:
 
Und das sshkey-gen hast Du auf dem Client ausgeführt? Wohin hast Du diesen public-key dann auf dem Server kopiert?
 

/dev/null

Moderator
Teammitglied
Die Ausgabe des Schlüsselpaares als ".ssh/identity" bzw. ".ssh/identity.pub" sagt mir, dass hier lediglich ein Schlüsselpaar für das RSA-Protokoll 1 erzeugt wurde. Dies, und dass du die Option "-t" nicht setzten konntest, interpretiere ich so, dass deine ssh-Version auf dem Client nur das veraltete Protokoll 1 beherrscht.

Den auf dem Client (!!) generierten ".ssh/identity.pub" hast du ja bestimmt in die "~/.ssh/authorized_keys" auf dem Server kopiert?
Der ".ssh/identity" ist auch wie gefordert nur -rw------- ?
Die sshd_config sieht mir wie die unbearbeitete Originalversion aus, daran kann es also nicht liegen. Und die immer noch zugelassene Passwort-Authentifizierung funktioniert ja auch.

Jetzt muss ich raten: Ändere mal in der sshd_config den Eintag "#Protocol 2,1" in "Protocol 1", sshd neu starten.
Jetzt läuft er nur nach Protokoll 1 - so wie auch der Client. Ob es was bringt, weiß ich nicht.

Gibt es eigentlich gute Gründe, an der betagten Version des Betriebssystems auf dem Client festzuhalten?

MfG Peter
 
A

Anonymous

Gast
Was du dort für einen Key erstellt hast, ist ein rsa1 Key also einen Key für Protokollversion 1

Versuche dich mit
Code:
ssh -1 user@server
anzumelden

Ansonsten wenn du da jetzt mehrere Keys rumliegen hast, entweder du bist sicher das niemand anders die noch benötigt, dann alle Keys aus beiden UserHomeverzeichnissen löschen und alles noch mal neu anlegen. Wenn das Löschen aus irgend einem Grund nicht sein darf, dann (und nur dann) brauchen wir langsam mal eine Übersicht was du dort überhaupt mittlerweile alles rumliegen hast. Jeweils mit dem entsprechenden User (nicht als root) folgende Ausgaben:

Auf dem Server ( der Rechner an dem du dich mit ssh remote anmelden willst)
Code:
id -un ; uname -n
awk -F "[ -]" '{print $1,$2, $NF}' ~/.ssh/authorized_keys
Auf dem Rechner auf dem du ssh startest
Code:
id -un ; uname -n
head -1 $(find ~/.ssh -type f ! -name "id*.pub" ! -name known_hosts )
awk -F "[ -]" '{print $1,$2, $NF}' $(find ~/.ssh -name "id*.pub")

robi
 
OP
E

Emanuele

Member
@Geier0815
ssh-keygen habe ich auf dem Client ausgeführt von dem aus die ssh connection initiiert wird.
Den erhaltenen identity.pub habe ich zum Server (Dort will ich mich hinverbinden) sowohl im Verzeichnis ~/.ssh als auch im Verzeichnis /home/xy/.ssh abgelegt. Beides ohne Erfolg.
xy ist der User mit dem ich mich verbinden will. Dieser User existiert auf beiden Rechnern.

@/dev/null
den Inhalt von identity.pub hab ich in die authorized_keys sowohl im userverzeichnis als auch in ~-Verzeichnis abgelegt. Die Datei hat -rw-------
die sshd habe ich durchgeschaut aber so gelassen wie sie ist. Das sollte ja auch funktionieren.

Ich hab jetzt das Protokoll geändert so das nur das Protocol 1 verwendet wird und es funktioniert. DANKE DAFÜR

Ich vermute jetzt mal das Protokoll 2 sicherer ist und ich mir jetzt ernsthaft überlegen sollte openssh upzudaten und alles auf protokoll 2 umzustellen. Oder kann ich auch weiter das 1er benutzen?

Hab mich grad dafür entschieden das System upzudaten :)

Nochmals danke für die Hilfe an alle.
 

/dev/null

Moderator
Teammitglied
Hi,

freut mich, dass es jetzt funktioniert.
Ja, updaten solltest du unbedingt. Gerade in den Bibliotheken welche mit ssh und ssl zusammenhängen, hat es in den letzten Jahren viele Sicherheitsmägel gegeben, welche mittlerweile (hoffentlich) gefixt wurden. Auch das Protokoll 1 hat Nachteile gegenüber dem 2. Infos gibt es per Wikipedia. Aber Angst musst du dir wegen des Pr. 1 keine machen. Es geht hauptsächlich um den verwendeten Verschlüsselungsalgorithmus. Protokoll 1 kannte noch kein AES.

Da waren ja meine und robis Feststellungn mit Protokoll 1 ja richtig.
In einem bin ich mir aber jetzt nicht sicher: Wenn ich einen sshd in der sshd_config auf Protokoll 1 zwinge, muss ich da auf dem Client noch die Option "-1" setzen? Oder erkennt der Client das selbst und verwendet er ohne die Option dann eben das einzig mögliche Protokoll 1?
(Die Antwort darauf hat natürlich nur theoretische Bedeutung - ich würde kein Protokoll1 mehr verwenden.)

Emanuele, teste das doch bitte mal für mich. Also: musst du die Option -1 angeben, oder geht es auch ohne diese?

MfG Peter
 
OP
E

Emanuele

Member
wenn im sshd_config keine option angegeben ist (also # davor) nimmt er anscheinend das Protokoll 2 und nur das.
sobald ich die # entferne und somit
Code:
protocol 2,1
benutze geht es. Ich habe am Anfang auch nur
Code:
protocol 1
drin stehen gehabt wie du empfohlen hattest.
Er sucht sich also das passende Protokoll aus, wenn beide angegeben sind.

Der Client hat ja den rsa1 key produziert. Also sollte er den 1er auch verwenden. Ich gebe keine option -1 an und es funktioniert wunderbar.
Also nimmt er wohl das passende Protokoll.
 

/dev/null

Moderator
Teammitglied
Emanuele schrieb:
Ich gebe keine option -1 an und es funktioniert wunderbar.

Ok, damit meine Frage beantwortet.
Klar, Client und Server versuchen sich auf das beste gemeinsame Protokoll zu einigen. Da ich lt. deiner ssh-keygen-Ausgabe festgestellt habe, dass der Cleint nur 1 kann, habe ich dir empfohlen, den Server gleich auf 1 einzustellen. Also von vornherein das Aushandeln ausgeschlossen.

Was ich noch vergesen habe: Du kannst und solltest dich jetzt mit dem "Härten" des sshd befassen. Zumindest die PW-Anmeldung und den direkten root-Zugriff verbieten. Dir nützt die sicherste public-key-Auth. nichts, wenn das Hintertürchen (Passwortanmeldung) noch offen steht. Die Scriptkiddies warten oder spielen schon. Schau dir mal nach ein paar Stunden /var/log/messages an.

MfG Peter
 
Oben