ubuntuusers.de

Rechner von dem verbunden wird:

~/.ssh$ ls -la
insgesamt 16
drwxrwx--- 2 ab ab   71 Dez 25 18:14 .
drwxrwx--- 3 ab ab   17 Nov  5 01:25 ..
-rwx------ 1 ab ab 1343 Nov  5 01:25 config
-rwx------ 1 ab ab 2590 Dez 28 06:37 id_rsa
-rwx------ 1 ab ab  559 Dez 28 06:37 id_rsa.pub

Rechner zu dem verbunden wird:

~/.ssh$ ls -la
insgesamt 20
drwx------  2 ab ab   80 Dez 28 07:07 .
drwxr-xr-x 16 ab ab 4096 Dez 28 07:02 ..
-rw-rw-r--  1 ab ab  560 Dez 28 07:02 authorized_keys
-rw-------  1 ab ab 2590 Dez 24 23:20 id_rsa
-rw-r--r--  1 ab ab  559 Dez 24 23:20 id_rsa.pub
-rw-r--r--  1 ab ab  222 Dez 28 07:07 known_hosts

Das funktioniert problemlos, wenn sich User ab zu User ab am anderen PC vebindet.

Zu einem weiteren PC funktioniert das auch, wenn sich ab zu ab verbindet, aber nicht wenn sich ab zu einem anderen User verbindet. Vermutlich gibt es da irgendeine Sicherheitseinstellung. Was fehlt da bei mir?

Habe mein eigenes Problem von damals wiedergefunden. Nur funktioniert es dieses Mal noch immer nicht.

glaskugel schrieb:

So, nun wurde 192.168.178.122 neu aufgesetzt (manches funktionierte zu früher extrem langsam und war nicht erklärbar) und da läuft nun Oneiric, statt Natty. Die ssh-Problematik blieb (verrückterweise). Die Fehlermeldung in /var/log/auth.log hat meine Glaskugel inspiriert 😉 und ich habe folgendes als root gemacht:

chmod 600 /home/ec/.ssh/authorized_keys
chown ec:ec /home/ec/.ssh/authorized_keys

ls -l /home/ec/.ssh/authorized_keys
-rw------- 1 ec ec 390 2012-04-10 21:09 /home/ec/.ssh/authorized_keys

Danach funktionierte der Login ohne PW. Verständlich ist das nicht für mich, da das mit dem anderen User nicht notwendig ist, aber das ist zumindest ein Workaround.

$ ls -la
insgesamt 12
drwx------ 2 ec ec   61 Dez 28 08:11 .
drwxrwxr-x 3 ec ec   17 Dez 28 08:14 ..
-rw------- 1 ec ec  560 Dez 28 08:11 authorized_keys
-rw------- 1 ec ec 2590 Dez 28 08:11 id_rsa
-rw-r--r-- 1 ec ec  563 Dez 28 08:11 id_rsa.pub

$ ls -la /home/ec/.ssh/authorized_keys 
-rw------- 1 ec ec 560 Dez 28 08:11 /home/ec/.ssh/authorized_keys

Allerdings ist es nun ein Link von einer anderen Partition zu ~/.ssh und das dürfte das Problem sein, ohne Link funktioniert es.

glaskugel schrieb:

[…] Das funktioniert […] nicht wenn sich [Benutzer] ab zu einem anderen User verbindet.

• Dann muss der Benutzer ab natürlich nicht den Schlüssel von ab, sondern den Schüssel des anderen Benutzers vorweisen

• oder der andere Benutzer muss auch den Schlüssel von ab besitzen.

Die Datei ~/.ssh/authorized_keys befindet sich auf dem Ziel-Rechner im Heimat-Verzeichnis des sich anmeldenden Benutzers; abhängig von diesem ist es also jeweils eine andere!

Das musst du missverstanden haben. Es sind schon die richtigen Keys verwendet. Ich habe ~/.ssh am Ziel-PC gelöscht, von /daten/irgendwas/.ssh das nach ~/.ssh verlinkt war, nach ~/.ssh kopiert, die Rechte vorsichtshalber geprüft und es hat funktioniert. Das Problem ist also die Verlinkung. Eventuell ist "lrwxrwxrwx" beim Link das Problem.

ssh kennt die Option -v für eine gesprächigere Ausgabe. Je mehr v, umso gesprächiger. Wenn du uns diese Meldungen hier einfügst, können wir das Problem vielleicht besser eingrenzen.

Dein erstes ~/.ssh/-Listing macht auf mich den Eindruck, dass du der Gruppe noch alle Rechte entziehen solltest.

Bzgl. deiner Anmerkung zu den symbolischen Links hilft dir vielleicht OpenSSH refused .ssh directory with a symbolic link🇬🇧.

So funktioniert es, .ssh ist _nicht_ verlinkt.

$ ssh -v ec@192.168.2.172
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/ab/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.2.172 [192.168.2.172] port 22.
debug1: Connection established.
debug1: identity file /home/ab/.ssh/id_rsa type 0
debug1: identity file /home/ab/.ssh/id_rsa-cert type -1
debug1: identity file /home/ab/.ssh/id_dsa type -1
debug1: identity file /home/ab/.ssh/id_dsa-cert type -1
debug1: identity file /home/ab/.ssh/id_ecdsa type -1
debug1: identity file /home/ab/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ab/.ssh/id_ed25519 type -1
debug1: identity file /home/ab/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ab/.ssh/id_xmss type -1
debug1: identity file /home/ab/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0p1 Ubuntu-6build1
debug1: match: OpenSSH_8.0p1 Ubuntu-6build1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.2.172:22 as 'ec'
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:MEIN-KEY1
debug1: Host '192.168.2.172' is known and matches the ECDSA host key.
debug1: Found key in /home/ab/.ssh/known_hosts:2
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/ab/.ssh/id_rsa RSA SHA256:MEIN-KEY2 agent
debug1: Will attempt key: /home/ab/.ssh/id_dsa 
debug1: Will attempt key: /home/ab/.ssh/id_ecdsa 
debug1: Will attempt key: /home/ab/.ssh/id_ed25519 
debug1: Will attempt key: /home/ab/.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
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ab/.ssh/id_rsa RSA SHA256:MEIN-KEY2 agent
debug1: Server accepts key: /home/ab/.ssh/id_rsa RSA SHA256:MEIN-KEY2 agent
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.2.172 ([192.168.2.172]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/ec/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/ec/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = de_AT.UTF-8
Welcome to Ubuntu 19.10 (GNU/Linux 5.3.0-24-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


0 Aktualisierungen können sofort installiert werden.
0 dieser Aktualisierung sind Sicherheitsaktualisierungen.

.ssh im Homeverzeichnis ist nun verlinkt und es kommt zur PW-Abfrage, Dateien sind ident.

Das ist nun ein Test mit einem anderen (3.) PC, da ich beim 2. PC den Link entfernt habe, da ich die automatische Identifizierung dort permanent brauche und nicht immer ein PW eingeben will.

$ ssh -v ec@192.168.2.172
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/ab/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.2.172 [192.168.2.172] port 22.
debug1: Connection established.
debug1: identity file /home/ab/.ssh/id_rsa type 0
debug1: identity file /home/ab/.ssh/id_rsa-cert type -1
debug1: identity file /home/ab/.ssh/id_dsa type -1
debug1: identity file /home/ab/.ssh/id_dsa-cert type -1
debug1: identity file /home/ab/.ssh/id_ecdsa type -1
debug1: identity file /home/ab/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ab/.ssh/id_ed25519 type -1
debug1: identity file /home/ab/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ab/.ssh/id_xmss type -1
debug1: identity file /home/ab/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0p1 Ubuntu-6build1
debug1: match: OpenSSH_8.0p1 Ubuntu-6build1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.2.172:22 as 'ec'
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:MEIN-KEY1
debug1: Host '192.168.2.172' is known and matches the ECDSA host key.
debug1: Found key in /home/ab/.ssh/known_hosts:2
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/ab/.ssh/id_rsa RSA SHA256:MEIN-KEY2 agent
debug1: Will attempt key: /home/ab/.ssh/id_dsa 
debug1: Will attempt key: /home/ab/.ssh/id_ecdsa 
debug1: Will attempt key: /home/ab/.ssh/id_ed25519 
debug1: Will attempt key: /home/ab/.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
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ab/.ssh/id_rsa RSA SHA256:MEIN-KEY2 agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/ab/.ssh/id_dsa
debug1: Trying private key: /home/ab/.ssh/id_ecdsa
debug1: Trying private key: /home/ab/.ssh/id_ed25519
debug1: Trying private key: /home/ab/.ssh/id_xmss
debug1: Next authentication method: password
ec@192.168.2.172's password: 
debug1: Authentication succeeded (password).
Authenticated to 192.168.2.172 ([192.168.2.172]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /videos/ec
debug1: Sending environment.
debug1: Sending env LANG = de_AT.UTF-8
Welcome to Ubuntu 19.10 (GNU/Linux 5.3.0-24-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage


0 Aktualisierungen können sofort installiert werden.
0 dieser Aktualisierung sind Sicherheitsaktualisierungen.

Die Dateirechte sehen so aus:

$ ls -la /home/ec/.ssh
lrwxrwxrwx 1 ec ec 16 Dez 29 03:44 /home/ec/.ssh -> /videos/ec/.ssh/

Unterschied zum ursprünglichen PC ist, dass jetet nicht /videos ec:ec gehört, sondern erst /videos/ec/

$ ls -la /home/ec/.ssh/
insgesamt 16
drwx------  2 ec ec   77 Dez 29 03:42 .
drwxrwxr-x 25 ec ec 4096 Dez 29 03:42 ..
-rw-------  1 ec ec  560 Dez 29 03:42 authorized_keys
-rw-------  1 ec ec 2590 Dez 29 03:42 id_rsa
-rw-r--r--  1 ec ec  559 Dez 29 03:42 id_rsa.pub

Zum Vergleich, die Rechte direkt und nicht über den Link abgefragt.

$ ls -la /videos/ec/.ssh/ insgesamt 16 drwx-––- 2 ec ec 77 Dez 29 03:42 . drwxrwxr-x 25 ec ec 4096 Dez 29 03:42 .. -rw-––– 1 ec ec 560 Dez 29 03:42 authorized_keys -rw-––– 1 ec ec 2590 Dez 29 03:42 id_rsa -rw-r--r-- 1 ec ec 559 Dez 29 03:42 id_rsa.pub

Ganz vergessen, danach zu fragen: Kannst du uns auch Logs der Serverseite bereitstellen?

Mir ist in diesem Fall nicht klar, was die Serverseite ist? Aber grundsätzlich ja, ich habe auf beiden PCs root-Rechte.

In der Regel ist der Server der Teil eines Systems, der Resourcen bereitstellt. Im Fall von ssh ist es also der Host, auf dem du dich anzumelden versuchst.

glaskugel schrieb:

debug1: Remote: Ignored authorized keys: bad ownership or modes for directory /videos/ec

Das ist doch ziemlich eindeutig - das übergeordnete Verzeichnis muss deinem User gehören (und es sollte keine Schreibrechte für dritte ermöglichen, da sonst das .ssh Verzeichnis kompromittiert werden kann).