[Gelöst] ssh mit Key

[sys_op]

Hallo Leute

Ich habe hier 2 Server auf denen Virtualbox VM`s unter dem User virtualbox laufen. Da ich immer den unten benannten Fehler hatte, habe ich die Konfiguration (sshd_config) von Server1 auf Server2 kopiert

Auf meinem Client (debian 10) habe ich einen Key erstellt und mit

Code: Alles auswählen

ssh-copy-id virtualbox@server1

auf Server1 kopiert und mit

Code: Alles auswählen

ssh-copy-id virtualbox@server2

auf Server2

Die Anmeldung klappt auf Server1, aber server2 will immer wieder das Passwort haben?

Also einen anderen user angelegt und noch einmal

Code: Alles auswählen

ssh-copy-id user@server2

das Login klappt???

ssh virtualbox@server2 und wieder wird nach dem Passwort gefragt

ssh -v ergibt auf Server1

Code: Alles auswählen

debug1: Offering public key: /home/mn/.ssh/id_rsa RSA SHA256:XpnzKqSZ8vL1sFizsWI1URYW8G2gS5f72Rac0AYW3lg agent
debug1: Server accepts key: /home/mn/.ssh/id_rsa RSA SHA256:XpnzKqSZ8vL1sFizsWI1URYW8G2gS5f72Rac0AYW3lg agent
debug1: Authentication succeeded (publickey).
Authenticated to server1 ([server1]:22).

auf server 2 gelingt das aber nicht:

Code: Alles auswählen

debug1: Offering public key: /home/mn/.ssh/id_rsa RSA SHA256:XpnzKqSZ8vL1sFizsWI1URYW8G2gS5f72Rac0AYW3lg agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mn/.ssh/id_dsa
debug1: Trying private key: /home/mn/.ssh/id_ecdsa
debug1: Trying private key: /home/mn/.ssh/id_ed25519
debug1: Trying private key: /home/mn/.ssh/id_xmss
debug1: Next authentication method: password

die Dateien authorized_keys sind auf beiden Servern identisch.
Nun bin ich etwas ratlos, wieso das frei nach bill gates (mal gates, mal gates nicht) funktionert...

Danke für jede Antwort.

[heisenberg]

Auf Server2 in /var/log/auth.log nachschauen, was da beim Anmelden kommt. Ggf. in sshd_config LogLevel höher stellen auf Server2 und sshd durchstarten.

Mögliche Ursachen

- Falsche Rechte/Eigentümer der authorized_keys / Elternverzeichnisse.
- Altes Keyformat/Cipher nicht mehr von neuen Systemen in der Standardkonfiguration akzeptiert

[chrbr]

Hast du die ~/.ssh/known_hosts mit kopiert? Die sind im allgemeinen für jeden Rechner unterschiedlich und beinhalten Parameter, mit denen die sich anmeldenden Hosts wiedererkannt werden.

Ich weiß nicht, inwiefern das zu den Log Meldungen passt. Aber du könntest die Datei auf Server2 mal umbenennen. Dann wird bei der ersten Anmeldung nach dem Passwort gefragt. Dann schreibt Server2 die known_hosts neu. Danach sollte die Anmeldung ohne Passwort Eingabe funktionieren.

[Blackbox]

Dann schreibt Server2 die known_hosts neu. Danach sollte die Anmeldung ohne Passwort Eingabe funktionieren.

Mit den vorliegenden Informationen ist dieses Versprechen nicht mehr als eine Vermutung.
Woher kommt diese Gewissheit?

@sys_op

Hättest du das Loglevel nur um eine Stufe erhöht, wären in den Meldungen

Code: Alles auswählen

debug1: Offering public key: /home/mn/.ssh/id_rsa RSA SHA256:XpnzKqSZ8vL1sFizsWI1URYW8G2gS5f72Rac0AYW3lg agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mn/.ssh/id_dsa
debug1: Trying private key: /home/mn/.ssh/id_ecdsa
debug1: Trying private key: /home/mn/.ssh/id_ed25519
debug1: Trying private key: /home/mn/.ssh/id_xmss
debug1: Next authentication method: password

auch die Antworten vom Server aufgetaucht.
Kannst du das bitte nachholen und zur Verfügung stellen?

[heisenberg]

Hättest du das Loglevel nur um eine Stufe erhöht, wären in den Meldungen auch die Antworten vom Server aufgetaucht.

Das scheint mir keinen Sinn zu ergeben. Wenn der Server einen Key nicht akzeptiert, wird er außer der Tatsache, dass es so ist, mit Sicherheit nichts weiter dazu mitteilen. Wenn doch, würde ich das als Sicherheitslücke einstufen.

Ich habe das natürlich auch mal direkt ausprobiert (Ich bin dabei gleich auf debug3 hochgegangen), mit dem konstruierten Fall "Rechte auf authorized_keys falsch gesetzt" und sehe da erwartungsgemäß keine weiteren Informationen:

Code: Alles auswählen

$ ssh -vvv tester@dot

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ichhalt/.ssh/id_rsa RSA SHA256:csZnSbbqCaS8UWUSYC6FIMXNN3+grQDsXaRvaCNE1ks
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/ichhalt/.ssh/id_ecdsa ECDSA SHA256:jV1c8ImKTuNv8+FaOEduMWoxckhWKUazN/h8kN+RXJo
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/ichhalt/.ssh/id_ecdsa_sk
debug3: no such identity: /home/ichhalt/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/ichhalt/.ssh/id_ed25519
debug3: no such identity: /home/ichhalt/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/ichhalt/.ssh/id_ed25519_sk
debug3: no such identity: /home/ichhalt/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/ichhalt/.ssh/id_xmss
debug3: no such identity: /home/ichhalt/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
tester@dot's password: 

Auf LogLevel debug2 sehe ich da keine Informationen vom Server, nachdem der Pubkey gesendet wurde. Auf LogLevel debug3 sehe ich "receive packet: type 51", was ich als "Der Key wurde abgelehnt" oder "Antwort auf eine PubKey Übertragung" vermute. debug2 oder debug3 scheint mir also in so einem Fall keine weiteren Erkenntnisse zu liefern.

Evtl. wäre die Aushandlungsphase für das debugging - der Verbindungsaufbau - noch interessant. Aber für den Fall, dass da keine gemeinsame Basis (Cipher, KeyExchange, ...) wäre, würde ich vermutlich eine entsprechende Fehlermeldung bekommen, also z. B. so etwas wie das folgende:

Code: Alles auswählen

$ ssh bla

Unable to negotiate with 1.2.3.4 port 22: no matching key exchange method found. 
Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

[Blackbox]

Das scheint mir keinen Sinn zu ergeben.

Aber nur, wenn man nach dem Motto: Schnelligkeit vor Gründlichkeit agiert.
Außerdem schrieb ich vom Loglevel, und nicht vom Debug Mode.

@sys_op: Zeig doch bitte die sshd-Konfiguration deines /server2/.

[sys_op]

Hi,
erst mal danke, dass sich so viele so intensiv mit meinem Malheur beschäftigen

Hier also die sshd_config, die ich natürlich vorher auch vom anderen Server kopiert hatte.

Code: Alles auswählen

#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj 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 override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
LogLevel DEBUG2

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

# PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# 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 yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange 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 and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

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

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

Noch zur Info:
Server1 und Server2 sind komplett identisch mit Debian 11 aufgesetzt. Bevor ich hier gepostet habe, hatte ich noch die sshd_config kopiert und den server neu gestartet, war also vorher nicht ganz untätig

Ich habe nun noch einmal /home/user/.ssh nach /home/virtualbox kopiert, die Rechte gesetzt, es will nicht (EDV = [E]nde [D]er [V]ernunft)

hier nun noch ssh -vvv

Code: Alles auswählen

debug1: Offering public key: /home/mn/.ssh/id_rsa RSA SHA256:XpnzKqSZ8vL1sFizsWI1URYW8G2gS5f72Rac0AYW3lg agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mn/.ssh/id_dsa
debug3: no such identity: /home/mn/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/mn/.ssh/id_ecdsa
debug3: no such identity: /home/mn/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/mn/.ssh/id_ed25519
debug3: no such identity: /home/mn/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/mn/.ssh/id_xmss
debug3: no such identity: /home/mn/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Interessant, auf dem selben Server mit einem anderen User klappt der Key??

[heisenberg]

Ping

Ok. Noch mal zur Wiederholung und in bunt:

Auf Server2 in /var/log/auth.log nachschauen, was da beim Anmelden kommt.

Ich würde da mit LogLevel INFO in sshd_config anfangen und wenn nix kommt Schritt für Schritt höher schalten.

[sys_op]

Hi, danke ich habe den Fehler gefunden, es waren die Rechte am Ordner /home/virtualbox, die durch ein restore-script auf 757 gestellt wurden, offenbar akzeptiert ssh nur 755.

Irgend wer hier war mit den Rechten also auf dem richtigen Weg

Sorry, aber ich habe das sicher 100 mal überlesen....

Danke

[Blackbox]

Sorry, aber ich habe das sicher 100 mal überlesen....

Ja, ein typischer Layer 8 Error.
Vergiss bitte nicht, den Thread als [gelöst] zu markieren.

[heisenberg]

Hättest du das Loglevel nur um eine Stufe erhöht, wären in den Meldungen
...
auch die Antworten vom Server aufgetaucht.

Das kann ich nicht nachvollziehen und aus oben erwähntem Grund macht das für mich keinen Sinn, dass das so ist.

Kannst Du das exemplarisch mal darstellen, wie Du das genau meinst? Also ich bitte darum, dass Du den Fall, so wie ich das auch gemacht habe, mal einrichtest: Server/User mit falschen Berechtigungen auf der authorized_keys und dann zeige mir bitte die entsprechende Logausgabe vom SSH-Client, der Hinweise darauf gibt, dass die Berechtigungen auf dem Server falsch sind.

Das scheint mir keinen Sinn zu ergeben.

Aber nur, wenn man nach dem Motto: Schnelligkeit vor Gründlichkeit agiert.
Außerdem schrieb ich vom Loglevel, und nicht vom Debug Mode.

Kannst Du das, was Du damit meinst auch mal - wie in vorigem Absatz gewünscht - nochmal exemplarisch für diese Aussage zeigen? Denn ich weiss leider überhaupt nicht, was Du mit Gründlichkeit hier untersuchen möchtest. Die Option -v beim SSH-Client erhöht im Übrigen das LogLevel desselben, was man an der Ausgabe sieht. Da gibt es für mich keinen Unterschied zwischen LogLevel und DebugLevel. Oder meinst Du das sshd-LogLevel des Zielservers - also so wie ich das auch empfohlen hatte?

[sys_op]

Hi,

Zur Klärung, in der auth.log war ein Eintrag

Code: Alles auswählen

Authentication refused: bad ownership or modes for directory /home/virtualbox

den habe ich gefühlte 100 mal überlesen.

mit ssh -vvv wurde dieser Eintrag aber nicht ausgegeben, die Lösung war also nur über die auh.log zu finden.