SSH Keybased login werkt niet

[Verwijderd]

Hallo,

Bij wijze van test wil ik een ssh verbinding maken doormiddel van keybased authentication. Deze verbinding moet komen vanaf een remote server naar een lokale server die ik hier thuis heb.

Ik heb dit werkend gekregen met het root account van mijn lokale server, maar ik wil het graag met een 'normale' user doen. Maar zodra ik dit doe, blijft de ssh verbinding vragen om een wachtwoord.

Ik heb deze handleiding gevolgd.

Wat gegevens:
Beide systemen draaien ubuntu, de remote 9.10 en de lokale 8.10.
De remote server draait: OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
De lokale draait: OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007


Ik heb in die handleiding alle stappen gevolgd bij "What if it doesn't work?".


Het probleem is dus dat hij blijft zeuren om het wachtwoord, nadat ik de keyfile op de lokale server toegevoegd heb.

Iemand die mij kan helpen?

[swbr]

Staan de juiste permissies op je .ssh directories en de bestanden daarin?

Staat de juiste public key in je authorized_hosts, of als er de juiste staat, staan er misschien harde returns midden in je key?

Probeer anders eens de optie -vvv mee te geven met ssh, de logging die je dan krijgt moet je aardig op weg helpen.

[Verwijderd]

Waarschijnlijk staan inderdaad de permissies verkeerd. De volgende files moeten de volgende permissies hebben:

~/.ssh chmod 0700

~/.ssh/authorized_keys chmod 0600

[Verwijderd]

Verwijderd schreef op vrijdag 18 december 2009 @ 13:41:
Waarschijnlijk staan inderdaad de permissies verkeerd. De volgende files moeten de volgende permissies hebben:

~/.ssh chmod 0700

~/.ssh/authorized_keys chmod 0600

Deze rechten staan goed.

Stel dat ik wil inloggen als gebruiker 'sander', dan moet dit bestand dus ook van 'sander' zijn, toch? En dit moet staan in /home/sander/.ssh ? Klopt dat?

Als ik ssh start met -vvv (dus ssh gebruiker@lokaleserver -vvv)

krijg ik dit:

debug1: Host '[lokaleserver:poort' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:2
debug2: bits set: 523/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x29b5a00)
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,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: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
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

Ik snap hier dus geen hol van. Er staat toch (dikgedrukt stukje) dat de id_rsa is verstuurd, dat hij wacht op een reply, en verder niks?

Bovenin in dat logstukje staat er nog een rijtje met dit:

debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype

Dat lijkt erop dat er iets fouts staat in het id_rsa bestand?

Nog andere dingen die ik misschien kan doen?

[Nvidiot]

Wat staat er in je authorized_keys bestand? Daar hoort niet iets te staan als:
---- BEGIN
ssh-rsa AAAAPNETOPSOPWOPGsnoep <etc>= hostname
---- END

Maar alleen het stuk TUSSEN --- BEGIN en --- END.

[Verwijderd]

Nvidiot schreef op vrijdag 18 december 2009 @ 19:51:
Wat staat er in je authorized_keys bestand? Daar hoort niet iets te staan als:
---- BEGIN
ssh-rsa AAAAPNETOPSOPWOPGsnoep <etc>= hostname
---- END

Maar alleen het stuk TUSSEN --- BEGIN en --- END.

Er staat alleen iets als:

code:

ssh-rsa AAAAfffsadfFIXb24YL9Gwrq4UQJc8kwLBQ42R6RgVI+JxhwPbkjJfVJWE3jXT0fMrVPQlp3Q+Y4k3GRgRGSy2ftLWpW8aUwN9ndTgqHdsfaeerfsfasTMmnpN6YxZva7k8v91B1Vcge78HwoG9F2UoC09LtwzTLzncfnvtxmUpQglXzNtwepTC0ourELv12/lcTECVY2i4xMclKtsyViTMU2tNiikSKiw3wNBqqL4P7xLEWsv6oGOpSE7u9BnHfLPamSakVbdRHjj1EbyU6MzgMKHWLsKBXASRvNs9/tZ/w== root@remote
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnFUmrEUF1AbO4DNWoXMRFb2GRyddQqfbZ50ybwFot9buGpPK4PrL0CDinZ0aga/ejomHirAecBx+QLdud1ivKxIC75BrolqgpZCuXnXLr0wYjtl/qzvhfS2y/TpIuel/QsXvO9vDsHqKS5XCGDf/i9EmmG8vWtb43pnMOora6iemO/vTrSPThf9G5zrz1jpbMFxWUcoBs9oBmV4YyiTFVAj8Q1wMg9jTgU5sI8yEbmX4AkdKIQtMfuvIa2oZ3bnrFBKJ7XVAbsLlIow06jGOyeVEpQdZlyD/hKRYro51iRP97NfzeT1iA5ZW92azRbP90YP3p/zjpvyi9PXFwhC+Ow== root@remote
ssh-rsa AAAAB3dffsasAAAABIwAAAQEAwIE1esVx3UzESWbuu/EIVo0nJlynwm3YbKgbrbj7oMc1VXWdpUGh14iMeZImuyD2k2Tsafdsffdsffsdsdfsadffsddsaffdsdfs/+sPkFrDgD2XXdfdfadsaffsKpR4nEZFgRpfB05aaoF32ZbLpYFEAgCh0BZWegrUv87ToPqxiZyp0uStDFhpul66XEjR1SZA9SZWcegSa9E67wstln4by1GyQmji/yILUZtsH4nzChytNuQHg18IAnGXmnL9q4zHEYO2FOnyRLHWWafUkd61z50TVkcumB+AyGzwWMARmIvu6+d3QxAfkEgK/jKdNgsdIfQ== root@remote

[swbr]

Verwijderd schreef op vrijdag 18 december 2009 @ 19:42:
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply[/b]

Hier wordt je private key naar de server verzonden, de reden dat je geen reply krijgt is dat je public key niet in de authorized_keys staat.

Let wel, het gaat hier om de private/public key van root op de machine waar je het ssh commando uitvoert (want dat doe je zo te zien als root), en die public key van root lijkt dus niet (of niet goed) in de authorized_keys van 'gebruiker' op de remote machine te staan. Als dat allemaal wel het geval is, zou je eens op de remote host in de logs moeten gaan kijken waarom je ssh daemon je key niet accepteert.

debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
...
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype

Dat lijkt erop dat er iets fouts staat in het id_rsa bestand?

Dit is normaal, je ssh client gaat eerst kijken of je rsa key van type RSA1 is, dat is niet zo, en dan gaat hij verder kijken of je rsa key van type RSA2 is.

[Hero of Time]

Het is redelijk simpel: verkeerde user hangt er achter de sleutel. De keys die je hebt toegevoegd zijn als je root user gemaakt, maar aangezien je met je normale user nu wilt aanmelden, werkt dat niet want de gebruiker komt niet overeen. Maak dus die keys opnieuw aan als normale gebruiker zoals in de howto staat, vervang de public key van root met die van je gebruiker (of voeg 'm toe, maar waarom zou je vanaf root naar je andere machine gaan als normal user) en probeer het opnieuw.

Even voor de duidelijkheid, dit is het probleem:
ssh-rsa <lange key>== root@remote
ssh-rsa <lange key>== root@remote
ssh-rsa <lange key>== root@remote
Dat hoort dus sander@remote te zijn, of wat voor gebruikersnaam je ook gebruikt op je 'client' die de verbinding opzet.

[Verwijderd]

Hero Of Time schreef op vrijdag 18 december 2009 @ 21:16:
Het is redelijk simpel: verkeerde user hangt er achter de sleutel. De keys die je hebt toegevoegd zijn als je root user gemaakt, maar aangezien je met je normale user nu wilt aanmelden, werkt dat niet want de gebruiker komt niet overeen. Maak dus die keys opnieuw aan als normale gebruiker zoals in de howto staat, vervang de public key van root met die van je gebruiker (of voeg 'm toe, maar waarom zou je vanaf root naar je andere machine gaan als normal user) en probeer het opnieuw.

Even voor de duidelijkheid, dit is het probleem:
ssh-rsa <lange key>== root@remote
ssh-rsa <lange key>== root@remote
ssh-rsa <lange key>== root@remote
Dat hoort dus sander@remote te zijn, of wat voor gebruikersnaam je ook gebruikt op je 'client' die de verbinding opzet.

Oké, nu begrijp ik er even helemaal niks meer van.

Op mijn remote server log ik altijd in via SSH als 'sander' (dus niet root). Als ik dan iets wil doen als root, doe ik dat met sudo of sudo -i. De ssh verbinding opzetten, evenals ssh-keygen en ssh-copy-id heb ik gedaan met sudo -i (dus als root).


Wat ik nu wil doen is via rsync via ssh een backup maken. Ik weet niet zeker of ik dit moet doen als root of als 'sander', maar in mijn ogen doet dat er toch niet toe?

Ik wil dat backup programma (rsync) laten lopen via ssh via de gebruiker 'backup'. Dus vanaf remote, gebruiker 'root' OF 'sander' met SSH naar lokaal met gebruiker 'backup'.

Wat ik dus probeerde, is om als root (op mijn remote server), via SSH in te loggen op de lokale server, met gebruiker 'backup'.

Jij zegt, dat ik de keys die ik heb toegevoegd als root heb aangemaakt, maar dat ik nu met een normale user wil aanmelden. Dat klopt, ik heb die keys als root op mijn remote server aangemaakt, en ik wil als normale gebruiker (gebruiker 'backup') inloggen op de lokale server.
Dat is dan toch goed? Of moet ik op beide servers een gebruiker 'backup' hebben, om daar mee in te loggen? Ik kan toch wel gewoon als gebruiker root@a of sander@a inloggen als backup@b? Of moet het zijn: met ssh op backup@a inloggen als backup@b?

[ Voor 12% gewijzigd door Verwijderd op 18-12-2009 21:59 ]

[Hero of Time]

Het is dus niet helemaal duidelijk, ik zal het met een voorbeeld beter omschrijven:
Ik heb twee systemen, een laptop, hostname Chii, en een PC, hostname Lain. Ik maak op Lain een public en private key als m'n gewone gebruiker, sasquatch in dit geval. De public key die eruit komt, id_rsa.pub, zet ik vervolgens in de ~/.ssh/authorized keys van Chii bij de gebruiker bij wie ik wil aanmelden. Zou ik bijvoorbeeld direct als root willen aanmelden ermee, dan staat de public key van sasquatch (de gebruiker die de SSH verbinding opzet) van host Lain in /root/.ssh/authorized_keys bij Chii.

Jij, met je root en sander gebruikers, beide met dus een eigen id_rsa.pub sleutel (eindigend op root@remote voor root en sander@remote voor je normale gebruiker) in /home/backup/.ssh/authorized_keys op je lokale server.
Het samenvoegen is heel eenvoudig door de root en sander id_rsa.pub te echo-en naar authorized_keys op de uitvoerende server (lokaal) via cat id_rsa.pub >> authorized_keys (dit voegt het toe, met > wordt de inhoud overschreven).

Dus, alle gebruikers die via een key aanmelden op een server moeten allemaal een eigen key genereren (op de client) en toevoegen op de server.

Btw, ik weet niet of het moet, maar ik heb ook m'n public en private key in .ssh van de gebruiker staan met wie ik de SSH sessie opzet (client side).

[ Voor 6% gewijzigd door Hero of Time op 19-12-2009 00:13 ]

[silentsnake]

Wat Hero of Time zegt is niet helemaal juist. Het user@host is alleen maar commentaar, het gaat puur om de key zelf. Ik heb genoeg authorized_key files gezien waar de user@host niet klopte maar de authenticatie wel gewoon werkt. Het gaat er om dat je met de juiste user de ssh verbinding start zodat je de juiste ssh keys aan de server aanbied, niet wat de user@host zegt.

Waar Hero of Time dus op doelt is dat je met de juiste gebruiker ingelogd moet zijn, of de rechten van die gebruiker moet hebben voordat je je SSH commando draait.

Voor de rest weet ik het ook niet zo 123, check dat je de juiste key in de juiste authorized_keys zet. En als je sudo gebruikt om een (root) shell te krijgen, zorg ervoor dat je sudo su - gebruikt, anders blijf je de eigenschappen van je vorige shell houden (hoewel ik niet weet of dit relevant is). Sowieso probeer het eens met een test user.

[gertvdijk]

silentsnake schreef op zaterdag 19 december 2009 @ 00:21:
Wat Hero of Time zegt is niet helemaal juist. Het user@host is alleen maar commentaar

Inderdaad. Boeit niet.

Wat zegt je SSH server log? /var/log/auth.log bijvoorbeeld.

[Soultaker]

Even voor de duidelijkheid: OpenSSH negeert die username en hostname compleet. Die zijn alleen om voor jezelf het overzicht te bewaren. Het gaat er dus uitsluitend om dat de public key op de server overeenkomt met de private key op de client.

Het heeft er alle schijn van dat het geen technisch probleem is, maar sander1001 gewoon zit te prutsen.

Verwijderd schreef op vrijdag 18 december 2009 @ 19:42:
Als ik ssh start met -vvv (dus ssh gebruiker@lokaleserver -vvv)

krijg ik dit:

debug1: Host '[lokaleserver:poort' is known and matches the RSA host key.
[..]
debug1: Offering public key: /root/.ssh/id_rsa
[..]

Is dit nu van 'lokaal' naar 'lokaal' of van 'remote' naar 'lokaal'? Sowieso ben je hier dus weer met root aan het inloggen, wat niet het scenario is wat je in je TS beschrijft. (Sterker nog: in je TS stel je dat dit al werkt!)

Verwijderd schreef op vrijdag 18 december 2009 @ 19:56:
[...]


Er staat alleen iets als:

code:

ssh-rsa AAAAfffsadfFIXb24YL9Gwrq4UQJc8kwLBQ42R6RgVI+JxhwPbkjJfVJWE3jXT0fMrVPQlp3Q+Y4k3GRgRGSy2ftLWpW8aUwN9ndTgqHdsfaeerfsfasTMmnpN6YxZva7k8v91B1Vcge78HwoG9F2UoC09LtwzTLzncfnvtxmUpQglXzNtwepTC0ourELv12/lcTECVY2i4xMclKtsyViTMU2tNiikSKiw3wNBqqL4P7xLEWsv6oGOpSE7u9BnHfLPamSakVbdRHjj1EbyU6MzgMKHWLsKBXASRvNs9/tZ/w== root@remote
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAnFUmrEUF1AbO4DNWoXMRFb2GRyddQqfbZ50ybwFot9buGpPK4PrL0CDinZ0aga/ejomHirAecBx+QLdud1ivKxIC75BrolqgpZCuXnXLr0wYjtl/qzvhfS2y/TpIuel/QsXvO9vDsHqKS5XCGDf/i9EmmG8vWtb43pnMOora6iemO/vTrSPThf9G5zrz1jpbMFxWUcoBs9oBmV4YyiTFVAj8Q1wMg9jTgU5sI8yEbmX4AkdKIQtMfuvIa2oZ3bnrFBKJ7XVAbsLlIow06jGOyeVEpQdZlyD/hKRYro51iRP97NfzeT1iA5ZW92azRbP90YP3p/zjpvyi9PXFwhC+Ow== root@remote
ssh-rsa AAAAB3dffsasAAAABIwAAAQEAwIE1esVx3UzESWbuu/EIVo0nJlynwm3YbKgbrbj7oMc1VXWdpUGh14iMeZImuyD2k2Tsafdsffdsffsdsdfsadffsddsaffdsdfs/+sPkFrDgD2XXdfdfadsaffsKpR4nEZFgRpfB05aaoF32ZbLpYFEAgCh0BZWegrUv87ToPqxiZyp0uStDFhpul66XEjR1SZA9SZWcegSa9E67wstln4by1GyQmji/yILUZtsH4nzChytNuQHg18IAnGXmnL9q4zHEYO2FOnyRLHWWafUkd61z50TVkcumB+AyGzwWMARmIvu6+d3QxAfkEgK/jKdNgsdIfQ== root@remote

Waarom heb je nu drie verschillende keys voor dezelfde gebruiker op dezelfde host, in plaats van aparte keys voor aparte gebruikers (zoals je wilde?) Als je er zo'n zootje van maakt, vind ik het niet vreemd dat je 't niet werkend krijgt hoor.

edit:
Grmbl. Laat.

[Hero of Time]

silentsnake schreef op zaterdag 19 december 2009 @ 00:21:
Wat Hero of Time zegt is niet helemaal juist. Het user@host is alleen maar commentaar, het gaat puur om de key zelf.

Dat wist ik niet, ik legde alleen uit wat ik zelf ervan begrijp. Voor zulk soort dingen doe ik het liever iets uitgebreider met hierdoor mogelijk overbodige, foute of anderszins niet boeiende informatie als het resultaat maar bereikt wordt .

Ik had al wel een gevoel dat die user@host geen zak uitmaakte, maar liever toch melden dan de plank nog meer mis slaan .

[Verwijderd]

Ik heb alles eens doorgelezen, en heb het allemaal nog eens opnieuw geprobeerd.

Dit is wat heb gedaan.


Ik heb op mijn lokale server de /home/backup/.ssh/authorized_keys verwijderd. (Dit omdat er 3 keer een key in stond van root@remote)

Toen heb ik ingelogd als 'sander' op mijn remote server, toen heb ik ssh-keygen gedaan, en vervolgens:
ssh-copy-id -i ~/.ssh/id_rsa.pub "backup@lokaal -p poortnummer".

Dit gaf aan dat het goed was gegaan en dat ik moest inloggen via ssh. Dit probeerde ik dus:
ssh backup@lokaal -p poortnummer
Hier werd echter nog steeds om een wachtwoord gevraagd.

Toen ben ik dus gaan kijken op mijn lokale server in /home/backup/.ssh/authorized_keys (die ssh-copy-id weer aangemaakt had) om te kijken wat er in stond. Hier stond de key van sander@remote in, dat was dus goed.


Vervolgens heb ik hetzelfde gedaan als 'root'. Ik deed dus op mijn remote server:
sudo -i.
Vervolgens:
ssh-keygen,
en die vroeg of ik de bestaande key wilde overschrijven. Dat deed ik dus.
Daarna weer:
ssh-copy-id -i ~/.ssh/id_rsa.pub "backup@lokaal -p poortnummer"

wat weer aangaf dat alles goed was gegaan. Weer probeerde ik in te loggen:
ssh backup@lokaal -p poortnummer
Hier werd echter nog steeds om een wachtwoord gevraagd.

Toen heb ik nog even gecontrolleerd of de de key wel op mijn lokale server was toegevoegd in /home/backup/.ssh/authorized_keys en die stond er in.

Soultaker schreef op zaterdag 19 december 2009 @ 00:30:
Is dit nu van 'lokaal' naar 'lokaal' of van 'remote' naar 'lokaal'? Sowieso ben je hier dus weer met root aan het inloggen, wat niet het scenario is wat je in je TS beschrijft. (Sterker nog: in je TS stel je dat dit al werkt!)

Wat ik bedoelde dat werkt is dat als ik vanaf mijn remote server via ssh in wil loggen als root@lokaal. Dus dit:
root@remote:~$ ssh root@lokaal -p poortnummer

Dit werkt dus zonder password. Maar inloggen via ssh vanaf de remote server met backup@lokaal werkt niet. Dus dit:
root@remote:~$ ssh backup@lokaal -p poortnummer en/of
sander@remote:~$ ssh backup@lokaal -p poortnummer
En dat is wat ik wil.

Hero Of Time schreef op zaterdag 19 december 2009 @ 00:11:
Het is dus niet helemaal duidelijk, ik zal het met een voorbeeld beter omschrijven:
Ik heb twee systemen, een laptop, hostname Chii, en een PC, hostname Lain. Ik maak op Lain een public en private key als m'n gewone gebruiker, sasquatch in dit geval. De public key die eruit komt, id_rsa.pub, zet ik vervolgens in de ~/.ssh/authorized keys van Chii bij de gebruiker bij wie ik wil aanmelden. Zou ik bijvoorbeeld direct als root willen aanmelden ermee, dan staat de public key van sasquatch (de gebruiker die de SSH verbinding opzet) van host Lain in /root/.ssh/authorized_keys bij Chii.

Jij, met je root en sander gebruikers, beide met dus een eigen id_rsa.pub sleutel (eindigend op root@remote voor root en sander@remote voor je normale gebruiker) in /home/backup/.ssh/authorized_keys op je lokale server.
Het samenvoegen is heel eenvoudig door de root en sander id_rsa.pub te echo-en naar authorized_keys op de uitvoerende server (lokaal) via cat id_rsa.pub >> authorized_keys (dit voegt het toe, met > wordt de inhoud overschreven).

Dus, alle gebruikers die via een key aanmelden op een server moeten allemaal een eigen key genereren (op de client) en toevoegen op de server.

Btw, ik weet niet of het moet, maar ik heb ook m'n public en private key in .ssh van de gebruiker staan met wie ik de SSH sessie opzet (client side).

Volgens mij heb ik nu alles gedaan wat jij zei, toch?

Nu staan er trouwens maar 2 keys in /home/backup/.ssh/authorized_keys. Namelijk die van sander@remote en root@remote. Ik heb ze ook vergeleken met de bijbehorende id_rsa.pub en ze komen overeen.

[ Voor 4% gewijzigd door Verwijderd op 19-12-2009 11:56 ]

[Verwijderd]

Wat geeft:

ls -al /home/backup/.ssh/

?

[Verwijderd]

Verwijderd schreef op zaterdag 19 december 2009 @ 12:27:
Wat geeft:

ls -al /home/backup/.ssh/

?

Dat geeft dit:
drwx------ 2 backup backup 4096 2009-12-19 11:30 .
drwxr-xr-x 7 samba samba 96 2009-12-17 16:36 ..
-rw------- 1 backup users 798 2009-12-19 11:35 authorized_keys

[vanaalten]

Ik weet er niet zo heel veel van af, maar deze:

drwxr-xr-x 7 samba samba 96 2009-12-17 16:36 ..

... vind ik wel opmerkelijk. Dus de directory /home/backup is eigendom/schrijfbaar voor user 'samba', niet voor user 'backup'? Of snap ik iets niet?

[Verwijderd]

vanaalten schreef op zaterdag 19 december 2009 @ 14:15:
Ik weet er niet zo heel veel van af, maar deze:

[...]

... vind ik wel opmerkelijk. Dus de directory /home/backup is eigendom/schrijfbaar voor user 'samba', niet voor user 'backup'? Of snap ik iets niet?

Poe, ja, dat viel mij net ook pas op. En het lijkt erop dat dit het probleem was.

[Verwijderd]

Verwijderd schreef op zaterdag 19 december 2009 @ 13:32:
[...]

Dat geeft dit:
drwx------ 2 backup backup 4096 2009-12-19 11:30 .
drwxr-xr-x 7 samba samba 96 2009-12-17 16:36 ..
-rw------- 1 backup users 798 2009-12-19 11:35 authorized_keys

Met directories/files van 2 verschillende users en 3 verschillende groepen is het nogal logisch dat je niet met keys kan inloggen

[Hero of Time]

Verwijderd schreef op zaterdag 19 december 2009 @ 11:46:
[...]

Volgens mij heb ik nu alles gedaan wat jij zei, toch?

Nu staan er trouwens maar 2 keys in /home/backup/.ssh/authorized_keys. Namelijk die van sander@remote en root@remote. Ik heb ze ook vergeleken met de bijbehorende id_rsa.pub en ze komen overeen.

Dat zou het idd moeten zijn. Ik heb alleen geen ssh-copy-id, maar via scp de bestanden naar m'n remote user gestuurd. Kan ook via USB stick of andere methodes, maar hiermee was ik iig zeker dat het werkte (was ook de manier hoe ik het bij anderen zag).

Die rechten moet je eerst even fixen, anders zal een verbinding nooit de nodige bestanden kunnen lezen. Als dat werkt, ben je klaar. Zo niet, hieronder wat ik een tijd geleden heb gedaan:
- ssh-keygen
- standaard map van ~/.ssh/id_rsa laten staan
- scp ~/.ssh/id_rsa.pub <user>@<doelhost>:~ (eventueel met poortnummer mocht dat afwijken van standaard 22)
- ssh <user>@<doelhost> (eventueel met poortnummer)
- cat id_rsa.pub > ~/.ssh/authorized_keys
- bovenstaand herhalen voor andere authorized gebruikers en cat id_rsa.pub >> ~/.ssh/authorized_keys

[Borromini]

Hero Of Time schreef op vrijdag 18 december 2009 @ 21:16:
Het is redelijk simpel: verkeerde user hangt er achter de sleutel. De keys die je hebt toegevoegd zijn als je root user gemaakt, maar aangezien je met je normale user nu wilt aanmelden, werkt dat niet want de gebruiker komt niet overeen. Maak dus die keys opnieuw aan als normale gebruiker zoals in de howto staat, vervang de public key van root met die van je gebruiker (of voeg 'm toe, maar waarom zou je vanaf root naar je andere machine gaan als normal user) en probeer het opnieuw.

Even voor de duidelijkheid, dit is het probleem:
ssh-rsa <lange key>== root@remote
ssh-rsa <lange key>== root@remote
ssh-rsa <lange key>== root@remote
Dat hoort dus sander@remote te zijn, of wat voor gebruikersnaam je ook gebruikt op je 'client' die de verbinding opzet.

Onzin. Wat jij vet geselecteerd hebt is louter informatief. OpenSSH houdt daar geen rekening mee, dat is alleen voor de computergebruiker interessant.

Wat het echte probleem lijkt te zijn - je zinspeelt er ook al op - is dat de TS als root een verbinding tot stand probeer te brengen met de server waarop hij als een andere gebruiker wil inloggen. Het probleem: als je als root de verbinding initialiseert gaat OpenSSH ook in de homedir van de root-gebruiker kijken naar sleutels die het kan gebruiken. Dat ook niet meer dan logisch .µ

Hij hoeft die sleutel niét te regenereren; alleen al de sleutels kopiëren naar sanders map en sander eigenaar ervan maken is voldoende.

[Hero of Time]

Borromini schreef op zaterdag 19 december 2009 @ 16:59:
[...]

Onzin. Wat jij vet geselecteerd hebt is louter informatief. OpenSSH houdt daar geen rekening mee, dat is alleen voor de computergebruiker interessant.

Komt spuit11 even langs. Dat is gisteren al gezegd en heb ook al aangegeven dat ik dat niet wist, ik heb mij er ook niet in verdiept. Als je ook even verder had gelezen, had je gezien dat het probleem nu is opgelost, hij had niet de juiste rechten op z'n home folder.

[Soultaker]

Hero Of Time schreef op zaterdag 19 december 2009 @ 15:23:
- cat id_rsa.pub > ~/.ssh/authorized_keys
- bovenstaand herhalen voor andere authorized gebruikers en cat id_rsa.pub >> ~/.ssh/authorized_keys

Doe maar altijd >> (in plaats van >) dan voorkom je dat je het bestand per ongeluk overschrijft.

Verwijderd schreef op zaterdag 19 december 2009 @ 15:14:
Poe, ja, dat viel mij net ook pas op. En het lijkt erop dat dit het probleem was.

Even voor de duidelijkheid: werkt het wel, nu je de permissies goed hebt gezet? Probleem opgelost dus?

[Hero of Time]

Soultaker schreef op zaterdag 19 december 2009 @ 22:29:
[...]

Doe maar altijd >> (in plaats van >) dan voorkom je dat je het bestand per ongeluk overschrijft.

Mijn idee was juist om eventuele fouten die er al in het bestand staan op te lossen, je voorkomt ook dubbelen entries. Niet dat het een probleem zou moeten geven, maar je weet maar nooit . Uiteraard als je al keys erin hebt van andere systemen wel >> gebruiken.