SSH Konfigurationsproblem unter SuSE 9.1

[Habanera]

Hallo Ihr Lieben!

Ich möchte gern, dass ich mich via SSH NUR mit einem PrivateKey einloggen kann. Leider klappt es nicht.

Das System ist SuSE 9.1 Professional

Fehlermeldungvon WinSCP:

Zitat:
Anmeldungsprotokoll (Siehe Sitzungsprotokoll für Details):
Using username "burbanek".
Unable to use key file "D:\Programme\Internet\WinSCP3\id_dsa.ppk" (OpenSSH SSH2 private key)
No supported authentication methods left to try!

Die Verbindung wurde unerwartet geschlossen. Der Server sendete den Befehlsbeendigungsstatus 0.



Folgendes habe ich gemacht:

1.) Keypaar erstellt mit putty keygen & einmal direkt auf dem Linuxrechner. Beide Varianten haben nicht geklappt. DAS 2048 Bit und RSA 1024 Bit versucht. Den public-key in das Homeverzeichnis von mir kopiert (~/.ssh/authorized_keys), den private Key auf dem Rechner gelassen, mit dem ich mich anmelden möchte.

Folgende Konfiguration der sshd_config habe ich gemacht:

(nach dem Guide http://www.debianhowto.de/howtos/de/sshconfig/c_sshconfig.html)

sshd_config:


# $OpenBSD: sshd_config,v 1.68 2003/12/29 16:39:50 millert 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
#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
PermitRootLogin no
#StrictModes yes

#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
RhostsRSAAuthentication no

# similar for protocol version 2
#HostbasedAuthentication no
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
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

### add by burbanek
#PAMAuthenticationViaKbdInt no
AllowUsers burbanek
StrictModes yes
PubkeyAuthentication yes
RSAAuthentication no
#RhostsAuthentication no
KeepAlive yes

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

# Kerberos options
#KerberosAuthentication no
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 (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication' and
'PermitEmptyPasswords'
UsePAM no

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


Kann mir jemand helfen??

Wäre voll nett!

Danke!

[heatwalker]

Hey,
also diesen Eintrag:

AuthorizedKeysFile .ssh/authorized_keys
solltest du noch in

AuthorizedKeysFile %h/.ssh/authorized_keys
umändern. Das "%h" steht für home.
Damit der SSH auch weiss, wo genau die Keys liegen.

Ein anderes Problem kann ich im Augenblick auch nicht sehen.

[Habanera]

Danke, habe ich versucht, allerdings leider ohne Erfolg :confused:

[cane]

Unable to use key file "D:\Programme\Internet\WinSCP3\id_dsa.ppk" (OpenSSH SSH2 private key)

Ist denn das auch der passende Key?

Hast Du nach den Änderungen an der config den sshd auch per '/etc/init.d/sshd restart' neu gestertet?

Noch was: Hat SSH denn vorher funktioniert?

mfg
cane

[heatwalker]

Hast du in der "ssh_config" auch eingestellt wie dein privatkey heisst???

Standardmässig sucht der nach "id_rsa" bzw. "id_dsa".
Könnte es sein das Putty den privatekey anders abspeichert?

[Habanera]

habe ich jetzt nochmal gemacht, brachte aber nix. Ich weiß aich nicht genau, aber ich glaube die ssh_config brauch ich ja nicht verändern, da es ja als Server auf dem SuSE laufen soll und ich von eienm Windowrechner dort hinwill, oder?

Habe auch nochmal 2 neue Keys erstellt.

Immernoch die gleiche Fehlermeldung.

Mit den Keys hat es noch nie funktioniert - ist ne Neuinstallation gewesen auf nem Rechner. Den Neustart hatte ich gemacht von dem Deamon.

Nur mal so ne DAU-Frage: der PublicKey kommt auf den Rechner, wo ich hin will und der PrivatKey ist das File, was ich bei WinSCP mit lade, nicht war?

[heatwalker]

Hey,

zur "ssh_config":
Hier sollten schon änderungen gemacht werden falls dein Privatkey anders heisst als
id_rsa oder id_dsa.

Dein Key heisst ja wohl "id_dsa.ppk", dann muss das in der ssh_conf auch drin stehen.
Zumindest nach meinem Wissenstand.

Der Inhalt des Publickey wird in die Datei "authorized_keys" auf dem Server übermittelt,
auf den du zugreifen willst.

.. und richtig, der Privatkey bleibt auf dem Rechner von dem du die Verbindung aufbaust.

Aber muss es eigentlich WinPutty sein??? Sonst versuch es doch mal mit "openSSH" für Windows. Damit funktioniert es einwandfrei.

[Borkasson]

Setze mal:
StrictModes no

[Jinto]

steht doch da:
Unable to use key file "D:\Programme\Internet\WinSCP3\id_dsa.ppk" (OpenSSH SSH2 private key)

Du verwendest einen OpenSSH Key (wohl einfach nur in ppk umbenannt), putty erwartet ihn aber im ppk. Konvertiere ihn wie im Handbuch beschrieben.

Nachtrag:
Ich meine das Putty/Puttytool Handbuch