SSH key permission denied voor gebruiker, root werkt wel

[Verwijderd]

Ik heb sshkeys al vaker gebruikt, maar dit heb ik nog niet meegemaakt.

Ik heb een set SSH keys voor een gebruiker aangemaakt welke op een ander systeem bekend is, echter krijg ik hoe dan ook permission denied.

Het commando van het aanmaken op PC1:

code:

ssh-keygen -t rsa -f /usr/local/keys/gebruiker/gebruiker -N ''

Dus ik heb een PC1 met de private key voor "gebruiker" en op PC2 de gebruiker "gebruiker" met de public key in /home/username/.ssh/authorized_keys, waar de keys als root zijn aangemaakt op PC1

So far so good, zou je zeggen. Ik zou dus van PC 1 naar PC 2 in moeten kunnen loggen met het volgende commando:

code:

ssh -i /usr/local/keys/gebruiker/gebruiker -o PasswordAuthentication=no -o StrictHostKeyChecking=no [e-mail]

Ik krijg het met geen mogelijkheid voor elkaar om in te loggen als root user met het bovenstaande commando op de commandline.

Ik heb SSH keys voor root even geprobeerd omdat het toch maar een testmachine is en dat werkt wel.

Met de -vvv optie in het SSH commando wordt ik niet veel wijzer. De gebruiker staat NIET op /nologin.

Default werk alles wel met SSH, dus echte vreemde dingen hoef je niet in te stellen in de ssh_config

Er gaat naar mijn idee toch iets fout met de username welke verkeerd wordt geverifieerd. Ik doe dit alles als root op de commandline en in de public key staat root@pc1

Kort samengevat:

- Root van PC1 naar PC2 werkt op dezelfde manier prima.
- Gebruiker van PC1 naar PC2 werkt niet.

[ Voor 0% gewijzigd door Verwijderd op 10-12-2007 11:47 . Reden: typo in de SSH lijn l => i ]

[Zwerver]

Geef eens wat meer info uit de logs e.d. als je dit probeert?

[Verwijderd]

Zwerver schreef op maandag 10 december 2007 @ 11:28:
Geef eens wat meer info uit de logs e.d. als je dit probeert?

Bij deze:

code:

[root@pc1 ~]# ssh -vvv -i /usr/local/keys/gebruiker/gebruiker -o PasswordAuthentication=no -o StrictHostKeyChecking=no gebruiker@192.168.1.102
OpenSSH_4.5p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.102 [192.168.1.102] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[e-mail],zlib
debug2: kex_parse_kexinit: none,[e-mail],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[e-mail],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 128/256
debug2: bits set: 516/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 7
debug1: Host '192.168.1.102' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:7
debug2: bits set: 532/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 ((nil))
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
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: Trying private key: /root/.ssh/id_rsa
debug3: no such identity: /root/.ssh/id_rsa
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
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic,password).

[ Voor 0% gewijzigd door Verwijderd op 10-12-2007 11:47 . Reden: typo in de SSH lijn l => i ]

[Kalentum]

/usr/local/keys/gebruiker/gebruiker bevat de private key van de gebruiker? Misschien dan -i gebruiken ipv -l?

[ Voor 194% gewijzigd door Kalentum op 10-12-2007 11:40 ]

[Verwijderd]

rutgerw schreef op maandag 10 december 2007 @ 11:37:
/usr/local/keys/gebruiker/gebruiker bevat de private key van de gebruiker? Misschien dan -i gebruiken ipv -l?

Jup, die bevat de private key.

Sorry voor mijn typo, met -i werkt het ook niet namelijk.

Dit was een lijn van 03:00

[Kalentum]

Nou dan weet ik het ook niet. met -i geef je de private key op maar uit je verbose output blijkt dat de ssh client domweg iets anders pakt, namelijk drie keys uit /root/.ssh/ dus die -i wordt genegeerd.

het moet zijn:

ssh -i <path naar key> user@host

[Verwijderd]

Dus jij zegt ook, hé, hij gaat bij de root kijken in plaats van de user ?

Dat had ik ook het idee, ik kon er al niets over vinden via google, fora, enz.

Ik heb het idee dat ik zelf iets fout doe, ik weet niet waarom, maar het moet iets stoms zijn.

Inloggen als user met password werkt overigens prima.

[Kalentum]

Ik vermoed dat die private keys dus niet bestaan. Misschien typo in de key, in de gebruikersnaam etc etc.

[Zwerver]

Oke, volg deze stappen eens heel exact?

Op de client: 

#ssh-keygen -t rsa -f foo -b 2048
#scp foo.pub <serveradres>

Op de server:

#cat foo.pub .ssh/authorized_hosts

Nu weer op die client:
#ssh -i /root/foo -o PasswordAuthentication=no -o StrictHostKeyChecking=no <servername>

Werkt dit? Zo ja:

$ssh-keygen -t rsa -f foo -b 2048
$scp foo.pub <serveradres>

Op de client:

$cat foo.pub .ssh/authorized_hosts

Nu weer op die client:
$ssh -i /home/<username>/foo -o PasswordAuthentication=no -o StrictHostKeyChecking=no <servername>

Werkt dit ook allemaal? Check dan even heel goed je permissies van .ssh en zijn bestanden voor de situatie die je boven hebt.....

[Sendy]

Zwerver >
Mis je in je tweede commando niet de redirect? Beetje onhandig als de TS jouw tekst letterlijk overtikt

Op de server:
#cat foo.pub >> .ssh/authorized_hosts

edit:

Jaja, append ja.

[ Voor 8% gewijzigd door Sendy op 10-12-2007 14:06 ]

[Kalentum]

en zou dat niet >> .ssh/authorized_keys moeten zijn ?

[Verwijderd]

Dank je zwerver, dat is wat ik ook deed, niet echt problemen mee.

Ok, ik denk dat ik weet waar het mis gaat.

Ik ben dus root op PC1 en maar de key aan user/foo als root. Ik krijg dus in de .pub aan het eind root@pc1

Deze kopieer ik naar de user op PC2 /home/user/.ssh/authorized_keys

Dan probeer ik als root op PC1 te connecten naar PC2 met:

code:

ssh -i /usr/local/keys/gebruiker/gebruiker -o PasswordAuthentication=no -o StrictHostKeyChecking=no [e-mail]2

Hij zal dus bij root gaan kijken, wat mij niet logisch lijkt, maar toch.

[Zwerver]

Sendy schreef op maandag 10 december 2007 @ 13:43:
Zwerver >
Mis je in je tweede commando niet de redirect? Beetje onhandig als de TS jouw tekst letterlijk overtikt

Op de server:
#cat foo.pub >> .ssh/authorized_hosts

edit:
Jaja, append ja.

Jups, moet een >> zijn idd

Verwijderd schreef op maandag 10 december 2007 @ 13:58:
Dank je zwerver, dat is wat ik ook deed, niet echt problemen mee.

Ok, ik denk dat ik weet waar het mis gaat.

Ik ben dus root op PC1 en maar de key aan user/foo als root. Ik krijg dus in de .pub aan het eind root@pc1
Deze kopieer ik naar de user op PC2 /home/user/.ssh/authorized_keys

Waarom doe je dit? Je kan toch beter de key aanmaken als user? Overigens doe ik dit soms ook wel, maar dan moet je dus wel de key chownen om hem te kunnen gebruiken....

[Verwijderd]

Zwerver schreef op maandag 10 december 2007 @ 14:17:

Waarom doe je dit? Je kan toch beter de key aanmaken als user? Overigens doe ik dit soms ook wel, maar dan moet je dus wel de key chownen om hem te kunnen gebruiken....

opzich kun je hem beter als useraanmaken, maar de users zijn bij mij alleen bekend op de slaves, de master houdt de keys om in te kunnen loggen als user op die slaves.

Je bedoelt dat ik de key op de slave moet chownen ? op de master de gebruiker niet bekend welke op de slave bekend is, alleen de key om in te kunnen loggen.

Ik zal nog eens een key als user aanmaken op de slave en dan laten kopieren naar de master, ik krijg dan alleen slave > master communicatie waar ik er voor zorgen wilde dat ik alleen master > slave communicatie heb.

[Zwerver]

Verwijderd schreef op maandag 10 december 2007 @ 15:16:
[...]


opzich kun je hem beter als useraanmaken, maar de users zijn bij mij alleen bekend op de slaves, de master houdt de keys om in te kunnen loggen als user op die slaves.

Je bedoelt dat ik de key op de slave moet chownen ? op de master de gebruiker niet bekend welke op de slave bekend is, alleen de key om in te kunnen loggen.

Ik zal nog eens een key als user aanmaken op de slave en dan laten kopieren naar de master, ik krijg dan alleen slave > master communicatie waar ik er voor zorgen wilde dat ik alleen master > slave communicatie heb.

Wha? Wat doe je moeilijk Maak gewoon op de master een key aan en vervoer die naar de slave, zet hem in de slave in je auth_hosts en log in? Das echt niet onwerkbaar volgens mij? Je moet zorgen dat er op de server (slave kant in jou geval) wel de juiste rechten zijn ingesteld op auth_hosts

[Verwijderd]

Ja ik vond het ook en beetje een omslachtige manier, maar het werd vaker gebruikt begreep ik.

Jij zegt dus 1 key per slave (aangezien ik toch een PHP app, apache dus uiteindelijk) in laat loggen. De user zelf komt er op die manier nooit op

Kan zijn dat ik dit topic later nog even update

[Zwerver]

Verwijderd schreef op maandag 10 december 2007 @ 15:32:
Ja ik vond het ook en beetje een omslachtige manier, maar het werd vaker gebruikt begreep ik.

Jij zegt dus 1 key per slave (aangezien ik toch een PHP app, apache dus uiteindelijk) in laat loggen. De user zelf komt er op die manier nooit op

Kan zijn dat ik dit topic later nog even update

Nou, eigenlijk zeg ik: zorg ervoor dat het werkt met 1 slave en ga het dan kopieren! Maar het werkt nu nog niet eens met 1 slave, laat staan met 10

[Verwijderd]

Zwerver schreef op maandag 10 december 2007 @ 15:49:
[...]

Nou, eigenlijk zeg ik: zorg ervoor dat het werkt met 1 slave en ga het dan kopieren! Maar het werkt nu nog niet eens met 1 slave, laat staan met 10

Het werkt wel, alleen voor root, dat is het probleem

Moet op te lossen zijn.

[Pim.]

Zoals ik het lees heeft Zwerver je exact verteld wat je moet weten. Lijkt me dat je nog eens de manuals door moet of zijn proces nog eens door moet

[Verwijderd]

Pim. schreef op maandag 10 december 2007 @ 17:45:
Zoals ik het lees heeft Zwerver je exact verteld wat je moet weten. Lijkt me dat je nog eens de manuals door moet of zijn proces nog eens door moet

Ik ben aan het bugtracen, ga er nu weer mee verder.

[ Voor 5% gewijzigd door Verwijderd op 10-12-2007 18:08 ]

[ralfbosz]

Twee dingen die altijd fout gaan bij mij met dit soort dingen:

1) Gebruiker op PC2 heeft geen wachtwoord (maakt niet uit wat voor eentje, als die er maar eentje heeft, en liefst eentje die niet verloopt).
2) De rechten van de .ssh directory zijn te ruim, die moet alleen benaderbaar zijn voor de eigen gebruiker (700 dus).

[Verwijderd]

ralfbosz schreef op maandag 10 december 2007 @ 18:16:
Twee dingen die altijd fout gaan bij mij met dit soort dingen:

1) Gebruiker op PC2 heeft geen wachtwoord (maakt niet uit wat voor eentje, als die er maar eentje heeft, en liefst eentje die niet verloopt).
2) De rechten van de .ssh directory zijn te ruim, die moet alleen benaderbaar zijn voor de eigen gebruiker (700 dus).

Beide in orde, zoals je zelf aangeeft dat ze moeten zijn.

Ik zal de directory zelf ook nog even controleren.

[Verwijderd]

Hoe stom kun je zijn (heel stom)

Ik had het homepath van de user een directory hoger gezet, dus /home/user/data

De key werd iedere keer verplaatst met het copy command naar de data folder als ik hem als user kopieerde

De homedir van de user is dus anders