SSH avaimella Windowskoneeseen ei onnistu [RATKAISTU: authorized_keys oikeudet]

[Jagster]

Koska toinen osapuoli on Ubuntu, niin kelpaako?

Julkiset avaimet ovat paikallaan eikä mitään suurempia säätöjä ole tehty Win 10 SSH-serverillä. Silti kysyy koko ajan salasanaa. Googlekierrosta on nyt tehty pari päivää, eikä mikään onnistu. Koko ajan, kun yritän päästä Raspberrystä sisäverko Windows-koneeseen, kysytään sitkeästi salasanaa.

ssh -v kertoo tällaista:

[19:03:12] jagster@ubuntu:~$ ssh -v jakke@192.168.100.40
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/jagster/.ssh/config
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.100.40 [192.168.100.40] port 22.
debug1: Connection established.
debug1: identity file /home/jagster/.ssh/id_rsa type 0
debug1: identity file /home/jagster/.ssh/id_rsa-cert type -1
debug1: identity file /home/jagster/.ssh/id_dsa type -1
debug1: identity file /home/jagster/.ssh/id_dsa-cert type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/jagster/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/jagster/.ssh/id_ed25519 type -1
debug1: identity file /home/jagster/.ssh/id_ed25519-cert type -1
debug1: identity file /home/jagster/.ssh/id_ed25519_sk type -1
debug1: identity file /home/jagster/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/jagster/.ssh/id_xmss type -1
debug1: identity file /home/jagster/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_for_Windows_7.7
debug1: match: OpenSSH_for_Windows_7.7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.100.40:22 as 'jakke'
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:fj3Ntlzh3xNDxyDKBp+7fWR7KDA7aEDV7uD6kaXttcw
debug1: Host '192.168.100.40' is known and matches the ECDSA host key.
debug1: Found key in /home/jagster/.ssh/known_hosts:1
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/jagster/.ssh/id_rsa RSA SHA256:HieGsx5L1GozfvQlb5wwYfpKEDUiNRqAOAEHpqPFTGk
debug1: Will attempt key: /home/jagster/.ssh/id_dsa
debug1: Will attempt key: /home/jagster/.ssh/id_ecdsa
debug1: Will attempt key: /home/jagster/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/jagster/.ssh/id_ed25519
debug1: Will attempt key: /home/jagster/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/jagster/.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: Offering public key: /home/jagster/.ssh/id_rsa RSA SHA256:HieGsx5L1GozfvQlb5wwYfpKEDUiNRqAOAEHpqPFTGk
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/jagster/.ssh/id_dsa
debug1: Trying private key: /home/jagster/.ssh/id_ecdsa
debug1: Trying private key: /home/jagster/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/jagster/.ssh/id_ed25519
debug1: Trying private key: /home/jagster/.ssh/id_ed25519_sk
debug1: Trying private key: /home/jagster/.ssh/id_xmss
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
jakke@192.168.100.40's password:

Näkeekö joku tuossa mitään vinkkiä sille, että SSH-avain ei käy, vaan siirrytään salasanaan? Minusta tuon mukaan kaikki on ok, mutta silti avainta ei käytetä. Jos estän salasanalla kirjautumisen, niin sitten ei kirjauduta ollenkaan.

[Jagster]

Alkaa haiskahtamaan, että tiedosto-oikeudet on väärin.

Jos olen koskaan joskus sanonut pahan sanan pingiviinimaailman vaikeudesta ja ohjeiden keskeneräisyydestä, niin nehän ovat ihan esikoulutasoa verrattuna WIndowsin ohjeisiin ja mitä Microsoftin tukisivut tarjoavat. No, kaipa tämä tästä - minä saan sekunnissa ohjeet miten oikeudet laitetaan Ubuntussa kohdallee, mutta olen nyt googlaillut puoli päivää miten hemmetissä se onnistuu Winkympissä 

[Thinkit]

https://unix.stackexchange.com/questions/421397/why-is-ssh-key-authentication-failing-for-this-user-centos-7

Olisiko siis samaa kuin tässä ketjussa.

t. Thinkit

[Jagster]

Tiesin niin paljon, että koska on win-tunnukseni on ylläpitäjä, niin se käyttää C:\\ProgramData\ssh\administrators_authorized_keys tiedostoa. Taviskäyttäjällä se olisi kotihakemistossa .ssh/authorized_keys (adminin suhteen tuota voi muuttaa sshd_config tiedostossa).

Sekin selvisi matkan varrella, että kyse on nimenomaan tiedosto-oikeuksista. Se mikä ei sitten selvinnyt on että miten hemmetissä nuo muutetaan. Yksikään PowerShell ohje ei toiminut. Osa oli liian vanhaa, osassa oli muuten vaan virheitä ja kaikki neuvoibat yhden kohdan väärin - joka on toki voinut toimiakin joskus kympin alkuvuosina.

Oikeudet saa ja täytyy olla vain kahdella: oma tunnus ja SYSTEM. Jokainen PowerShell-ohje, johon törmäsin, liittivät mukaan esim. sshd-käyttäjän.

Resurssinhallinta auki, oikea hakemisto, tapauksesta riippuen jonkumpi keys-tiedosto ja ominaisuudet, suojaus ja sitten nuo kaksi käyttäjää oikeuksilla. Ei oikeuksien perimistä, ei muita käyttäjiä. Ja salasanan kysely loppui siihen.

Ihmettelen vaan kahta asiaa:
- miksi logit eivät kerro mikä mättää (ssh:n logienkin katsominen oli yksi hemmetin souvi, kun nekin on suljettu kaikilta)
. minkä helvetin takia mikkisoftan inssit ei ole varastaneet chmod-komentoa

Ja kolmas . miksi Microsoftin omissa ohjeissa, joissa neuvotaan SSH-serverin asennus, ei tuota kerrota; ei tietenkään, koska ideahan on mennä ulos joten miksi silloin kukaan asentaisi serveriä...

Kyllä. Olen huonolla tuulella ja päätä särkee. Minulla meni puolitoista päivää tällaiseen perunan eto-asiaan.

[Jagster]

Jospa laittaisi näkyviin mitä tein. Ehkä joskus jollakulla on samanlainen ongelma:

https://www.eksis.one/ohjeet/ssh-shell/windows-10-ja-ssh/