ubuntuusers.de

Hallo
Ich habe einen neuen Rechner aufgesetzt und möchte auf dem jetzt Nemo per SSH über Publickey an einen Server (OMV) anbinden.
Das hatte ich auf einem anderen Rechner schon mal so, weiß aber nicht mehr wie das per Nemo gelang.
Nemo fragt fleißig nach einer PW Anmeldung, obwohl ich auf dem OMV Rechner nichts geändert habe.
Bisherige Schritte:

ssh-keygen: Schlüsselpaar erzeugt
ssh-copy-id: öffenlichen Schlüssel an OMV rübergeschickt (daher ist PW Anmeldung weiterhin zugelasen), der ist auch angekommen unter ~/.ssh/authorized_keys
Die systemweite /etc/ssh/sshd_config sieht folgendermaßen aus:

Protocol 2
# HostKey /etc/ssh/ssh_host_rsa_key
# HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
StrictModes yes
PubkeyAuthentication yes
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
UsePAM yes
Subsystem sftp /usr/lib/openssh/sftp-server
# Subsystem sftp internal-sftp
# ForceCommand internal-sftp
# Match Group dateiplatform
# ChrootDirectory %h
PermitTunnel no
AllowGroups users root ssh 
AllowUsers USER1 USER2 USER3
AddressFamily any
Port 22
PermitRootLogin yes
AllowTcpForwarding no
Compression no
PasswordAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys /var/lib/openmediavault/ssh/authorized_keys/%u

Hier https://github.com/linuxmint/nemo/issues/161 wird vorgeschlagen einzufügen:

PreferredAuthentications publickey

Mir ist da aber nicht klar, ob sich das auf dem Client oder Server bezieht- klingt mehr nach Client.
Und Nemo hat das beim anderen Rechner bisher ohne diesen Eintrag gemacht.
Allerdings fragt auch die Konsole USER1/2/3 fleißig nach PW Login, ist also ggf. nicht nur Nemo.
Also die übliche Frage: Was habe ich übersehen...?

Gruß
Stephan

Moin,

Allerdings fragt auch die Konsole USER1/2/3 fleißig nach PW Login, ist also ggf. nicht nur Nemo.

Da würde ich mal anfangen. Was sagt denn

ssh -v user@server

? (kann mit -vv bzw. -vvv zunehmend gesprächiger gemacht werden)

Manchmal wirft der Client den Server mit Zertifikaten zu, bis dieser dann ablehnt. Dafür kann es helfen die folgenden Optionen sinnvoll zu setzen (mit -o direkt im Befehl, oder dann in der ~/.ssh/config):

• IdentitiesOnly

• IdentityFile

• PreferredAuthentications

• PubkeyAuthentication

• PasswordAuthentication

Hallo,

Scheint fast, wie ich vermutet hatte:
Der erwartet den Publickey in ~/.ssh/ statt in ~/.ssh/known_hosts.pub
Die verbose Version deutet jedenfalls drauf hin und inzwischen fand ich auch auf dem anderen Rechner den privaten und publickey unter ~/.ssh/

OpenSSH_8.2p1 Ubuntu-4ubuntu0.5, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.1.12 [192.168.1.12] port 22.
debug1: Connection established.
debug1: identity file /home/USER/.ssh/id_rsa type -1
debug1: identity file /home/USER/.ssh/id_rsa-cert type -1
debug1: identity file /home/USER/.ssh/id_dsa type -1
debug1: identity file /home/USER/.ssh/id_dsa-cert type -1
debug1: identity file /home/USER/.ssh/id_ecdsa type -1
debug1: identity file /home/USER/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/USER/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/USER/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/USER/.ssh/id_ed25519 type -1
debug1: identity file /home/USER/.ssh/id_ed25519-cert type -1
debug1: identity file /home/USER/.ssh/id_ed25519_sk type -1
debug1: identity file /home/USER/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/USER/.ssh/id_xmss type -1
debug1: identity file /home/USER/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.12:22 as 'USER'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:aqsHiukipodR+zh58NG/bI/ew2i8gMxlo3DxMa6Hlp0
debug1: Host '[192.168.1.12]:22' is known and matches the ECDSA host key.
debug1: Found key in /home/USER/.ssh/known_hosts:9
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/USER/.ssh/id_rsa
debug1: Will attempt key: /home/USER/.ssh/id_dsa
debug1: Will attempt key: /home/USER/.ssh/id_ecdsa
debug1: Will attempt key: /home/USER/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/USER/.ssh/id_ed25519
debug1: Will attempt key: /home/USER/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/USER/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/USER/.ssh/id_rsa
debug1: Trying private key: /home/USER/.ssh/id_dsa
debug1: Trying private key: /home/USER/.ssh/id_ecdsa
debug1: Trying private key: /home/USER/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/USER/.ssh/id_ed25519
debug1: Trying private key: /home/USER/.ssh/id_ed25519_sk
debug1: Trying private key: /home/USER/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive

Ich hatte das Schlüsselpaar mit

ssh-keygen -t ed25519 -f ~/.ssh/

erzeugt und mit

ssh-copy-id -i ~/.ssh/known_hosts.pub USER@192.168.1.12 -p22

Allerdings findet sich auf em OMV unter ~/.ssh/ keine Datei 'known_hosts.pub' und es fragt immer noch nach PW. Hab' ich wohl nochwas übersehen...

ssh-copy-id -i ~/.ssh/known_hosts.pub USER@192.168.1.12 -p22

Öhm, du hast den von dir erzeugten Key hoffentlich nicht known_hosts genannt (das wäre ein eher unglücklicher Name).

Hochladen solltest du den Publickey, den du mit dem Befehl zuvor erstellt hast. Also vermutlich eher einen aus dieser Liste:

• id_rsa

• id_dsa

• id_ecdsa

• id_ecdsa_sk

• id_ed25519

• id_ed25519_sk

• id_xmss

PS: Bei mir funktioniert die Portangabe am Ende nicht, mag aber versionsabhängig sein, würde es eher so probieren:

ssh-copy-id -i ~/.ssh/known_hosts.pub -p22 USER@192.168.1.12

Bzw. wenn ssh auf dem Standardport läuft kannst du es dir auch sparen. Vielleicht klappt es bei dir auch, weil es obsolet ist.

Hallo,

Scheint alles zu passen:

Erstellt hatte ich den Key auf dem Client mit

#ssh-keygen -t ed25519

und dann den .pub hochgeladen, wie beschrieben. Habe es aber nochmal wiederholt mit der Portangabe vor dem Ziel, statt dahinter (es gab keine Beschwerde zuvor, also war mich nix verdächtig).

Jetzt also nachgeschaut:
1. Server: ~/.ssh/authorized_keys enthält den Pubkey aus Client: ~/.ssh/known_hosts.pub (gleich 4x, durch wiederholte Hochladeversuche, aber ok- er ist da).
2. Server: /etc/ssh/sshd_config enthält die Zeile und zeigt zwei OrteÖ

AuthorizedKeysFile .ssh/authorized_keys  /var/lib/openmediavault/ssh/authorized_keys/%u

Habe das allerdings nie verändert.
3. Server: ~/.ssh/sshd_config Zeile

PreferredAuthentications publickey

hinzugefügt, dann

sudo service ssh restart

und es kommt:

Job for ssh.service failed because the control process exited with error code.
See "systemctl status ssh.service" and "journalctl -xe" for details.

Eine neue SSH Verbindung funktioniert ebenfalls nicht.

sudo service ssh status

ergab:

● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2023-03-25 19:42:00 UTC; 3s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 20961 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255/EXCEPTION)

Mär 25 19:42:00 OMV.local systemd[1]: ssh.service: Service RestartSec=100ms expired, scheduling restart.
Mär 25 19:42:00 OMV.local systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
Mär 25 19:42:00 OMV.local systemd[1]: Stopped OpenBSD Secure Shell server.
Mär 25 19:42:00 OMV.local systemd[1]: ssh.service: Start request repeated too quickly.
Mär 25 19:42:00 OMV.local systemd[1]: ssh.service: Failed with result 'exit-code'.
Mär 25 19:42:00 OMV.local systemd[1]: Failed to start OpenBSD Secure Shell server.

PreferredAuthentications publickey

wegkommentiert, restart und es ist alles wieder normal.
Das war mehrfach reprodizierbar.
Fazit: PubKey funktioniert nicht, scheint also kein Präferenzfehler.
Interessant fand ich:
Auf dem Client in ~/.ssh/ findet sich: id_ed25519 id_ed25519.pub known_hosts known_hosts.pub.
id_ed25519 id_ed25519.pub sind leer, die Schlüssel liegen in den beiden anderen Datien.

ssh-keygen

sollte doch per default in die 'known_hosts' und 'known_hosts.pub' schreiben, oder nicht?
4. Die /etc/ssh/ssh_config auf beiden Clients (dem, der PubKey macht und dem neuen) sind identisch: Alles auskommentiert außer

Include /etc/ssh/ssh_config.d/*.conf
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes

5. Der funkionierende Client hat keine Datei ~/.ssh/known_hosts.pub, funktionert aber per PubKey... ?!?

Soviel für jetzt erstmal. Nicht viel schlauer als vorher...noch nicht.

Gruß
Stephan

Zu 3.: Die Zeile mit Server: ~/.ssh/sshd_config Zeile gehört nach der Anleitung nicht in die sshd_config auf dem Server, sondern in die ~/.ssh/config auf dem Client.

Zu 5.: Die Datei heisst ~/.ssh/known_hosts (ohne .pub). In dieser Datei werden die Fingerprints der Server gespeichert. Das hat nichts mit deinen SSH-Keys zu tun.

Hi Stefan,

du solltest dich mit der Funktion der Dateien authorized_keys und known_hosts auseinandersetzen.

Du hast offenbar einen Key mit dem Namen known_hosts erstellt, zumindest vermute ich, dass daher die Datei known_hosts.pub kommt, diese gibt es nämlich normalerweise nicht.

Wenn du einen neuen Key erstellst (ssh-keygen) wird am Client das Schlüsselpaar erstellt:

• mein_key

• mein_key.pub

Jetzt lädst du deinen Publickey mein_key.pub hoch (ssh-copy-id). Auf dem Server wird dieser Key jetzt in die Datei authorized_keys eingetragen. Verbindet sich jetzt der Client zum ersten mal mit dem Server, dann trägt der Client den Key des Servers in seine known_hosts Datei ein. (kann man auch alles per Hand machen um es einmal nachzuvollziehen)

Kurz gesagt:

• Die known_hosts dient dem Client dazu, den Server zu verifizieren. Damit sich nicht einfach ein anderer Server für diesen ausgeben kann.

• Die authorized_keys dient dem Server dazu, sicherzustellen, dass nur zugelassene Clients sich per Pubkey mit dem Server verbinden können.

Ich würde jetzt mal

• in

  cat .ssh/known_hosts

  schauen und vermute die fängt so an:

  -----BEGIN OPENSSH PRIVATE KEY-----

• den Inhalt der Datei dann löschen, vermutlich auch die Datei, da ssh sie selbst neu anlegt, bin mir aber nicht sicher.

• die known_hosts.pub in jedem Fall löschen.

• einen neuen Key erstellen (ssh-keygen) und diesen bitte nicht knowon_hosts nennen.

• den neuen Key auf den Server schieben (ssh-copy-id, oder fürs bessere Verständnis einfach mal per Hand)

• mich per ssh auf dem Server einloggen.

Zu deinem parallelen Experiment:

3. Server: ~/.ssh/sshd_config Zeile

PreferredAuthentications publickey

Das ist nicht verwunderlich, weil dies eine Option für die ssh_config, also clientseitig ist (s. Manpage) und nicht für die sshd_config, die ja serverseitig ist.

Dem Client kannst du sagen womit du dich am liebsten anmelden würdest. Der Server erlaubt aber nur bestimmte Verfahren, hier gibt es kein "am liebsten" 😉

Hi,

Es hat funktioniert, und auch gedauert, aber ich habe endlich mal Zeit gefunden. Hatte in der Tat die sshd_config und die ssh_config miteinander verwechselt.

Also Keys gelöscht und neu erstellt und alles funktioniert problemlos.

Vergessen hatte ich allerdings, eine PW Abfrage für die Verwendung des Schlüssels zu definieren. Jetzt wird ohne Nachfrage verbunden- nicht gut, wenn der Rechner gehackt oder gestolen wird.

Ich markiere das mal als gelöst, frage aber dennoch mal in die Runde, ob sich ein Schlüsselpaßwort nachträglich ergänzen läßt oder nicht.

Gruß
Stephan

san04 schrieb:

Hi Stefan,

du solltest dich mit der Funktion der Dateien authorized_keys und known_hosts auseinandersetzen.

Du hast offenbar einen Key mit dem Namen known_hosts erstellt, zumindest vermute ich, dass daher die Datei known_hosts.pub kommt, diese gibt es nämlich normalerweise nicht.

Wenn du einen neuen Key erstellst (ssh-keygen) wird am Client das Schlüsselpaar erstellt:

• mein_key

• mein_key.pub

Jetzt lädst du deinen Publickey mein_key.pub hoch (ssh-copy-id). Auf dem Server wird dieser Key jetzt in die Datei authorized_keys eingetragen. Verbindet sich jetzt der Client zum ersten mal mit dem Server, dann trägt der Client den Key des Servers in seine known_hosts Datei ein. (kann man auch alles per Hand machen um es einmal nachzuvollziehen)

Kurz gesagt:

• Die known_hosts dient dem Client dazu, den Server zu verifizieren. Damit sich nicht einfach ein anderer Server für diesen ausgeben kann.

• Die authorized_keys dient dem Server dazu, sicherzustellen, dass nur zugelassene Clients sich per Pubkey mit dem Server verbinden können.

Ich würde jetzt mal

• in

  cat .ssh/known_hosts

  schauen und vermute die fängt so an:

  -----BEGIN OPENSSH PRIVATE KEY-----

• den Inhalt der Datei dann löschen, vermutlich auch die Datei, da ssh sie selbst neu anlegt, bin mir aber nicht sicher.

• die known_hosts.pub in jedem Fall löschen.

• einen neuen Key erstellen (ssh-keygen) und diesen bitte nicht knowon_hosts nennen.

• den neuen Key auf den Server schieben (ssh-copy-id, oder fürs bessere Verständnis einfach mal per Hand)

• mich per ssh auf dem Server einloggen.

Zu deinem parallelen Experiment:

3. Server: ~/.ssh/sshd_config Zeile

PreferredAuthentications publickey

Das ist nicht verwunderlich, weil dies eine Option für die ssh_config, also clientseitig ist (s. Manpage) und nicht für die sshd_config, die ja serverseitig ist.

Dem Client kannst du sagen womit du dich am liebsten anmelden würdest. Der Server erlaubt aber nur bestimmte Verfahren, hier gibt es kein "am liebsten" 😉

Das Lesen der Manpage soll helfen. Um die Passphrase zu ändern, gibt es die -p Option.

Also, z.B.:

ssh-keygen -p -f ~/.ssh/id_ed25519