SSH Probleme

Charmed

Registered User
Hallöle,
also ich habe irgendwie ein zwei Probleme mit dem SSH. Und zwar wollte ich die Kennwort-basierte Authentifizierung abschalten und mit dem Öffentlichen Schlüssel ersetzen. Ihr wisst bestimmt was ich meine.:)
Nun, das funktioniert irgendwie bei mir nicht, wie auch einige andere Dinge.
Also, ich habe beide Schlüssel generiert den öffentlichen in die authorized_keys hochgeladen und das folgende steht in meiner sshd_config:
Code:
# Authentication:

#LoginGraceTime 60
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	/etc/ssh/authorized_keys


Der letzte Pfad ist angepasst, habe mehrere Pfade versucht, aber nichts geht.
Ich bekomme immer als Fehlermeldung "Server refused our key". Was ist da falsch?

Dann zum root Login. Wie man oben sieht, ist der verboten, aber er geht immer noch. Oder ist das oben nicht alles an Einstellungen, die ich vornehmen muss?

Danke für eure Hilfe.

Gruß

Charmed

PS: Ich hab einen Strato VServer
 
Bist du sicher, das der Pfad stimmt? Bei mir ist das nämlich dieser.
Code:
/root/.ssh/authorized_keys
oder auch
Code:
/root/.ssh/authorized_keys2
Natürlich nur für den User root.
 
Ja, ich weiß, normaler weise heißt das, dass die Zeile auskommentiert ist, aber die ganze Datei sieht so aus, deshalb hab ich angenommen, dass es hier anders wäre, aber da habe ich mich ja nun geirrt. :o
Der root Login geht nun nicht mehr.
Ich habe aber immer noch die Probs mit dem ersten Problem. Ich habe mal deine Pfade probiert, aber beides geht leider nicht. Was genau muss ich dekommentieren, ich habe bis jetzt nur
Code:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile	/root/.ssh/authorized_keys
dekommentiert.
Muss ich noch was?

Gruß und Danke

Charmed
 
aber die ganze Datei sieht so aus, deshalb hab ich angenommen, dass es hier anders wäre
sshd hat sehr sinnvolle Standartwerte, deshalb kann man das meiste auskommentiert lassen.
AuthorizedKeysFile
Specifies the file that contains the public keys that can be used
for user authentication. AuthorizedKeysFile may contain tokens
of the form %T which are substituted during connection set-up.
The following tokens are defined: %% is replaced by a literal
'%', %h is replaced by the home directory of the user being
authenticated and %u is replaced by the username of that user.
After expansion, AuthorizedKeysFile is taken to be an absolute
path or one relative to the user's home directory. The default
is ``.ssh/authorized_keys''.
Das ist z.b. so ein sinnvoller Standartwert, bei euren obigen Pfadangaben müßten die Keys der User im Homeverzeichnis des roots abgelegt werden :rolleyes:, so kann sie jeder User in seinem eigenen Home Verzeichnis verwalten :)
Muss ich noch was?
Ein Blick in die Logdateien von sshd könnte nicht schaden. Vermutlich hat irgendeine Datei oder ein Verzeichnis in dem die Keys sind zu umfangreiche Dateirechte.
 
Hmmmm...
Also es geht immer noch nicht. Mit diesem Pfad: .ssh/authorized_keys .
Vielleicht muss der Key ja auch in ein anderes Verzeichnis.
Also im Moment ist der in root -> etc ->ssh. Dort in der Datei authorized_keys.
So der Pfad dahin (.ssh/authorized_keys) müsste doch also richtig sein oder nicht?
Ich habe jetzt mal im Manual geguckt und da steht als Standartpfad: $HOME/.ssh/authorized_keys
Nun tut sich noch eine Frage bei mir auf, brauche ich rsa oder dsa Keys?
Und noch ne Frage, wo finde ich denn das Log?
Ich habe in var/log geguckt, aber da ist nichts mit ssh.

Danke schon mal für die Hilfe.

Gruß

Charmed
 
Also im Moment ist der in root -> etc ->ssh. Dort in der Datei authorized_keys.
/root/.ssh/authorized_keys für den User root bei dem Standartpfad
Ich habe jetzt mal im Manual geguckt und da steht als Standartpfad: $HOME/.ssh/authorized_keys
Ist das gleiche wie ich im obigen Beitrag auch schon gepostet habe, nur eine andere Schreibweise.
Nun tut sich noch eine Frage bei mir auf, brauche ich rsa oder dsa Keys?
Guck doch einfach nochmal ins Manual.
Und noch ne Frage, wo finde ich denn das Log?
Ich habe in var/log geguckt, aber da ist nichts mit ssh.
/var/log/auth.log

[thread=527]Lesen bildet[/thread].
 
/root/.ssh/authorized_keys geht damit auch nicht.
Naja, ich lass es jetzt erst mal, ich schaue später noch mal danach.
Im Manual steht ich könnte beides nehmen.
/var/log/auth.log das Log gibt es bei mir nicht. Ich hab keine Log, die mit a anfangen, bei mir gehts erst mit boot.log los. Warum?
Ich bilde mich schon :)
Habe aber erst 2 Kapitel von Dedizierte Webserver. Dauert also noch ein bisschen.

Danke totzdem.

Gruß

Charmed
 
Ich hab die Beiträge jetzt 2x durchgelesen und mir kommt der Verdacht, dass Du die Beiträge von Hornox nicht richtig liest.

Mal rausgelöst, wie der Pfad lauten soll:
Code:
~/.ssh/authorized_keys
Tue uns doch mal den Gefallen und poste uns die Ausgabe von dem Homeverzeichnis des Users, der sich mit dem Key einloggen soll.
Code:
#Login als User vorrausgesetzt
ls -la ~/.ssh
Bitte beachte das ~! Es scheint so, als ob Du das vorher vergessen hast,
 
MOD: Full-Quote entfernt!

Leichter gesagt als getan, da gibt es nur die 3 Verzeichnisse bin (ist nichts drin), public_html (eine Datei namens .directory) und Documents (ebenfalls Datei mit dem Namen .directory). Dann sind da noch so ein paar Dateien drin, in dem Homeverzeichnis, die bei WinSCP ausgegraut sind. Ist das normal?

Welches Linux verwendest Du denn?

Auf meinem Strato VServer ist Suse 9.3.
 
Last edited by a moderator:
Guten Tag ;)

Hab mal den Thread hier ausgegraben, da ich genau das selbe Problem habe.

Beim Verbinden kommt nach Eingabe des logins "root"

ein

Code:
Server refused our key
Using keyboard-interactive authentication.
Password:

habe nun bereits 2 Tage gegoogelt und das Forum durchsucht, aber es ist nix zu finden :)

Homeverzeichniss des Users root ist /root/
ich glaube das liegt auch mit den Ordnerrechten zusammen, nur selbst Tests mit CHMOD 777 liefen nicht wie gewünscht.

Hier nochma die Verzeichnissauflistung :)

Code:
# ls -la ~/.ssh
total 12
drwxr-xr-x  2 root root 4096 Jan  4 10:16 .
drwxr-xr-x  5 root root 4096 Jan  4 10:15 ..
-rw-r--r--  1 root root 1116 Jan  4 10:15 authorized_keys

Schonmal im Vorraus vielen Dank :)

EDIT: Distri ist Suse 9.3
 
Jop, alles in einer Zeile, ist ein SSH2-DSA Key mit 2048bit

das kuriose ist ja, mit anderen Benutzern funktioniert es ja, ich hätte es aber gerne beim root auch so :)
 
Code:
#	$OpenBSD: sshd_config,v 1.69 2004/05/23 23:59:53 dtucker 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
port xxxx
#Protocol 2,1
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
#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 no
#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 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

Dazu ist zu sagen das ich den Server gestern neu aufgesetzt habe und darum noch alles Standart ist ;)
 
Nimm doch mal bitte bei
Code:
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

ie # davor weg und restarte den sshd :)

Wenn es nicht klappt, dann entferne bitte ebenfalls die # vor:
Code:
#LogLevel INFO

Dann sollten die Logfiles ein Ergebnis bringen.
 
Das sind ja schon die Standarteinstellungen, hab es dennoch mal gemacht, aber immernoch das gleiche Problem.

Das # vor LogLevel hab ich auch entfernt, nur wo find ich jetzt die Logdatei, bzw. wie heißt sie. In /var/log/ ist nichts zu finden.
 
Back
Top