Ssh mit publickey geht von 12.04, aber von 16.04 nicht. Ideen?

maxEG · 3. März 2020 um 22:49

Hallo,
ich greife von meiner 6.2, also ubuntu 12.04 auf einen apt-server (ubuntu 18.04) zu mit private-key-authentication zu. Die private-key Datei ist /root/.ssh/apt-server. Das geht prima.
Da ich momentan mit dem apt-server Netzwerkprobleme habe, möchte ich vom server host (16.04) ebenso drauf zugreifen. Also key hinkopiert, in .ssh/config alles gleich eingetragen, auch rechte, Owner des keys (gleicher Ort) wie auf 12.04 eingetragen und: es geht nicht. Die Logs hier:

von 12.04:

23:25/0 server ~/.ssh # ssh -v apt-server 
OpenSSH_5.9p1 Debian-5ubuntu1.10, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 10: Applying options for apt-server
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 172.16.2.1 [172.16.2.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/apt-server type -1
debug1: identity file /root/.ssh/apt-server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.10
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA b7:d6:0a:cc:53:c5:b3:f5:e3:50:b1:03:da:16:2f:64
debug1: Host '172.16.2.1' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:24
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/apt-server
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 172.16.2.1 ([172.16.2.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
Last login: Tue Mar  3 23:24:23 2020 from 10.16.1.1

von 16.04:

root@server-host:~/.ssh# ssh -v apt-server
OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 7: Applying options for apt-server
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 172.16.2.1 [172.16.2.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/apt-server type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/apt-server-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 172.16.2.1:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
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:lW5y8NGWqd59jGNkSJdCTAyTNGJFlBjZwscxXUD0LzI
debug1: Host '172.16.2.1' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/apt-server
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Ich hab mir nen Wolf gesucht und noch keinen blassen Schimmer, warum das nicht geht. Auf die nextcloud (ebenfalls 18.04) klappt das problemlos.

Vielleicht kann mir jemand einen Tipp geben? Danke!
LG
Max

MachtDochNix · 4. März 2020 um 07:04

Hallo Max!

Er findet den Key nicht. Kennst du:

https://wiki.ubuntuusers.de/SSH/#Authentifizierung-ueber-Public-Keys

Dort besonders den Hinweis:

Falls es noch nicht klappt, kann es daran liegen, dass die Rechte beim Server nicht korrekt sind. sshd achtet darauf, dass das Homeverzeichnis, das dem Login-Namen entspricht (also die „Mappe“ selbst), das .ssh-Verzeichnis und authorized_keys nur für den Eigentümer Schreibrechte hat. Hintergrund ist wohl, die Gefahr zu verringern, dass authorized_keys manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.

Wer also bei bestimmten Konten auf dem Server auch einer Gruppe Schreibrechte gewähren will, muss evtl. die Optionen in /etc/ssh/sshd_config prüfen.

Beste Grüße

Thorsten

maxEG · 4. März 2020 um 14:20

Hallo Thorsten,
Danke, ich les mir das genau durch!
LG
Max

maxEG · 4. März 2020 um 14:39

Ok, ich musste den Titel ändern (es war spät gestern).
von 12.04 geht es, von 16.04 nicht. Ich probier nacher 18.04, wenn es dann funktioniert, upgrade ich den server-host (wollt ich eh machen).
LG
Max

Arnaud · 4. März 2020 um 14:46

Hallo Max,

Wenn ich mich gut errinere, gab es auch einige Sichereitsänderungen : einige Verschlüsserungsalgorithmus sind nicht mehr unterstützt. Aber das kannst du in den Serverlogs überprüfen. Vielleicht gibt :

ssh-keygen -l -f /PFAD/KEY.pub

einige interessante Infos.

Gruß

Arnaud

maxEG · 5. März 2020 um 11:48

Hallo Arnaud,

root@apt-server:~/.ssh#  ssh-keygen -l -f apt-server.pub 
2048 SHA256:BRUFMgzoBMVxpKxJ78+vSNjrNgL12/np9Pxv9YtWRNM root@apt-server (RSA)

auf dem server-host (16.04) und dem apt-server selbst (18.04).

LG
Max

maxEG · 9. März 2020 um 09:53

ok, nachdem im Log vom apt-server tatsächlich gar nix ankam, habe ich mir mal die route auf dem Server-Host angeschaut und den Schuldigen gefunden:

root@server-host:~/.ssh# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         141.10.49.225   0.0.0.0         UG    0      0        0 br1
10.16.0.0       *               255.240.0.0     U     0      0        0 br0
141.10.49.224   *               255.255.255.248 U     0      0        0 br1
172.16.1.0      *               255.255.255.0   U     0      0        0 virbr2
172.16.2.0      *               255.255.255.0   U     0      0        0 virbr3

und ifconfig gibt

virbr3    Link encap:Ethernet  HWaddr 52:54:00:32:e5:68  
          inet addr:172.16.2.1  Bcast:172.16.2.255  Mask:255.255.255.0

aus, der Host frägt also bei sich selber an? Auch wenn es nicht die identischen MAC-Adressen sind.
Ich muss mir wohl das Netzwerkgedöns von KVM mal wieder durchlesen…
Gelöst ist es noch nicht, aber wohl eine ganz andere Baustelle…
Weiß jemand, wie man das macht, vom Host auf den Gast über eine virtuelle Netzwerkkarte?
LG
Max