[ssh] Waarom werkt dit niet meer?

[pven]

Ik heb een tijdje terug ssh-keys ingeregeld op al mijn 'servers'. Tot mijn verbazing kom ik er op eentje niet meer binnen met ssh, terwijl dat eerst wel werkte.

Wat ik zie (her-en-der gecensureerd):

DiskStation> ssh -v [e-mail]
OpenSSH_6.6, OpenSSL 1.0.1p-fips 9 Jul 2015
debug1: Connecting to werktniet.com [3.1.1.7] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6p2-hpn14v4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: Remote is NON-HPN aware
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x1c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr [e-mail] none
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr [e-mail] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 88:90:aa:fe:48:b8:45:ka:po:td:a5:ka:po:t2:b6:04
debug1: Host 'werktniet.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: password
[e-mail]'s password:

'Found key in /root/.ssh/known_hosts:5' geeft volgens aan dat de ssh-key juist is? Het maakt niet uit welk account ik pak, want geen eentje werkt. Wat nog gekker is: inloggen via het juiste wachtwoord werkt ook niet meer. Ik heb op de betreffende servers wat sites draaien, die doen het prima. Nog gekker: ook rsync via ssh werkt probleemloos.

Iemand enig idee wat er gaande kan zijn? Ik kom er niet aan uit.

Voor de volledigheid: ik kom nu dus niet ingelogd op deze server. Helaas heb ik daar karige support.

[Donaldinho]

Ik mis eigenlijk de daadwerkelijke foutmelding.

Staat in de .ssh van je diskstation nog wel het id-rsa en id-rsa.pub keypair? Het lijkt erop dat hij geen keypair match kan maken en daarom terugvalt op gewone password authenticatie.

Wat is het commando waarmee je die rsync draait?

[pven]

Ja, die keys staan er nog gewoon.

Het rsync-commando:

rsync -av --exclude @eaDir /volume1/FotoVideo/ rsync://[e-mail]/backup/backup/Foto_Video >> /volume1/log/rsync_Foto_Video_`date +%Y%m%d%H%M`.log

Ik kan me niet herinneren sinds welke actie het niet meer werkt. Ik log nooit zoveel in op die server, zo lang de websites en rsync werken hoef ik er niet naar om te kijken.

[Voor 28% gewijzigd door pven op 06-09-2015 15:45]

[Hero of Time]

Als ik jou was, zou ik toch proberen om erop aan te melden, want als dat niet meer werkt, heb je geen enkel idee wat er op de server gebeurt. Voor hetzelfde geld is deze gekaapt en is het onderdeel van een botnet. Omdat rsync nog wel werkt, kan dat een afleiding zijn om zo het gevoel te geven dat je nog wel alles kan wat je zou moeten kunnen.

Dat van de host key found is niets meer dan de RSA key die je krijgt als je voor het eerst aanmeld bij een systeem. Weet je nog dat je die vraag kreeg?

code:

The authenticity of host 'localhost (::1)' can't be established.
ECDSA key fingerprint is SHA256:<hash waarde>
Are you sure you want to continue connecting (yes/no)?

Als je nou met -vvv zou werken, ipv een enkele -v, dan krijg je meer output van je ssh commando en weet je of je key wordt aangeboden en wat er mogelijk mis mee zou zijn. Probeer ook met rsync de .ssh/authorized_keys op te halen van de gebruiker waarmee je wilt inloggen, dan kan je verifiëren dat je key er nog in staat of niet. Ook zie je eventueel andere keys die je er niet in hebt gezet, zoals die van de hackers, als dat je probleem is.

[Blokker_1999]

HOT, word inloggen met een keypair niet verhinderd wanneer de authorized_keys leesbaar zijn voor andere gebruikers? Ik dacht dat die permissions op 600 moeten staan voordat het werkt. Of doelde je op de authorized_keys van die backup gebruiker die nog wel werkt?

Met een beetje geluk kan je eens kijken of er in de sshd config iets vreemds te vinden is alsook of er in /etc/passwd onbekende gebruikers zijn bijgekomen.

[deadinspace]

pven schreef op zondag 06 september 2015 @ 15:24:
Ik heb een tijdje terug ssh-keys ingeregeld op al mijn 'servers'. Tot mijn verbazing kom ik er op eentje niet meer binnen met ssh, terwijl dat eerst wel werkte.

Het zou toch wel heel erg handig zijn om in te kunnen loggen op je server, zodat je wat meer informatie kan krijgen (bv uit /var/log/auth.log en /var/log/syslog). Heb je geen console-access via je hoster?

Welke distributies gebruik je (zowel server als client)?

Heb je recentelijk dingen veranderd aan je server? Grote upgrades? Wie beheert die server?

'Found key in /root/.ssh/known_hosts:5' geeft volgens aan dat de ssh-key juist is?

Dat gaat over de host key, niet de client key. Dat zegt dus niet al te veel.

pven schreef op zondag 06 september 2015 @ 15:44:
Het rsync-commando:

rsync -av --exclude @eaDir /volume1/FotoVideo/ rsync://[e-mail]/backup/backup/Foto_Video >> /volume1/log/rsync_Foto_Video_`date +%Y%m%d%H%M`.log

Je gebruik het rsync protocol, dat is verschrikkelijk onveilig. Je data en authenticatie gaat daarmee unencrypted over de lijn. Verander dat alsjeblieft.

Ik kan me niet herinneren sinds welke actie het niet meer werkt. Ik log nooit zoveel in op die server, zo lang de websites en rsync werken hoef ik er niet naar om te kijken.

Pas je wel security updates toe dan?

Blokker_1999 schreef op zondag 06 september 2015 @ 17:06:
HOT, word inloggen met een keypair niet verhinderd wanneer de authorized_keys leesbaar zijn voor andere gebruikers? Ik dacht dat die permissions op 600 moeten staan voordat het werkt.

Nope, authorized_keys mag gewoon world-readable zijn. De keyfiles (uiteraard) niet.

[Thralas]

deadinspace schreef op zondag 06 september 2015 @ 19:40:
Je gebruik het rsync protocol, dat is verschrikkelijk onveilig. Je data en authenticatie gaat daarmee unencrypted over de lijn. Verander dat alsjeblieft.

En ter aanvulling: in z'n startpost geeft TS aan dat het gek is dat rsync nog werkt. Niet dus, hoewel je met user@host syntax inderdaad over ssh gaat, gaat een rsync:// prefix volgens mij inderdaad met het rsync-protocol zonder ssh..

[Boudewijn]

deadinspace schreef op zondag 06 september 2015 @ 19:40:


Nope, authorized_keys mag gewoon world-readable zijn. De keyfiles (uiteraard) niet.

Ja dat zijn pubkeys. Let wel even op dat deze niet world-writeable is .
Private keys: ssh-agent gaat echt wel mekkeren hoor als dat niet goed zit.

[Hero of Time]

Blokker_1999 schreef op zondag 06 september 2015 @ 17:06:
HOT, word inloggen met een keypair niet verhinderd wanneer de authorized_keys leesbaar zijn voor andere gebruikers? Ik dacht dat die permissions op 600 moeten staan voordat het werkt. Of doelde je op de authorized_keys van die backup gebruiker die nog wel werkt?

Je SSH client gaat klagen als je .ssh map ruimer staat dan 0700, dus daar vang je al een deel mee af. Vervolgens moet juist je private key 0600 zijn. Is het iets anders, dan gaat het ook mekkeren. Je known_hosts mag zoals deadinspace al zei 0644 zijn, geen probleem (misschien zelfs wel 664). Authorized_keys, het bestand wat op de server staat en gebruikt wordt voor het accepteren van verbindingen via key exchange moet als ik 't goed heb ook 0600 zijn.

[Donaldinho]

ik zie trouwens dat je in je rsync user "backup" gebruikt terwijl je vanaf je diskstation probeert als root in te loggen.

Als je nu eens een gewone ssh sessie als backup user opstart?

[Voor 0% gewijzigd door Donaldinho op 06-09-2015 22:55. Reden: Damn you auto complete]

[pven]

Dank voor de tips! Uiteraard begrijp ik ook wel dat inloggen hoe-dan-ook de voorkeur heeft om te kijken wat er gaande is.

Donaldinho schreef op zondag 06 september 2015 @ 22:54:
ik zie trouwens dat je in je rsync user "backup" gebruikt terwijl je vanaf je diskstation probeert als root in te loggen.

Als je nu eens een gewone ssh sessie als backup user opstart?

Klopt: ik kom met root en backup niet binnen. Het ssh-voorbeeld is van root, maar ik rsync niet naar root maar naar backup. Ssh via backup werkt dus ook niet, zelfde melding. Terwijl rsync via ssh wel werkt. Dit laatste is voor mij het echte raadsel.

[Hero of Time]

En dus even met extra verbose logging proberen en uitvoer hier plaatsen. Tevens je .ssh map met rsync naar je systeem halen zodat je kan kijken wat er nou mis gaat. Doe wel de --preserve-all switch, dan behoud je ook de rechten op de map en bestanden (welke mask ze hebben) zodat je daar ook naar kan kijken.

[Mijzelf]

Wanneer je rsynct over ssh, wordt aan de andere kant rsync gestart. Wanneer je probeert in te loggen, start hij de shell uit /etc/passwd. Bestaat die nog wel?

Eventueel kun je dat omzeilen door

ssh user@server "/bin/sh -i"

uit te voeren. (Of bash, ash, ...)

Mogelijk is de file /etc/shells beschadigd/weg.

Als je de server verder niet goed kent zou het kunnen dat:

• voor de backup user een validatie script draait, waardoor je alleen rsync kunt uitvoeren.
• voor root helemaal geen remote login toegestaan is.

[pven]

Hero of Time schreef op maandag 07 september 2015 @ 08:48:
En dus even met extra verbose logging proberen en uitvoer hier plaatsen. Tevens je .ssh map met rsync naar je systeem halen zodat je kan kijken wat er nou mis gaat. Doe wel de --preserve-all switch, dan behoud je ook de rechten op de map en bestanden (welke mask ze hebben) zodat je daar ook naar kan kijken.

Ga ik vanavond doen.

Mijzelf schreef op maandag 07 september 2015 @ 10:13:
Wanneer je rsynct over ssh, wordt aan de andere kant rsync gestart. Wanneer je probeert in te loggen, start hij de shell uit /etc/passwd. Bestaat die nog wel?

Eventueel kun je dat omzeilen door

ssh user@server "/bin/sh -i"

uit te voeren. (Of bash, ash, ...)

Mogelijk is de file /etc/shells beschadigd/weg.

Als je de server verder niet goed kent zou het kunnen dat:

• voor de backup user een validatie script draait, waardoor je alleen rsync kunt uitvoeren.
• voor root helemaal geen remote login toegestaan is.

Ook dit ga ik vanavond doen. De server ken ik uiteraard wel, ik heb er zelf CentOS op geïnstalleerd.

Kortom: vanavond meer.

[deadinspace]

Hero of Time schreef op zondag 06 september 2015 @ 22:03:
Je SSH client gaat klagen als je .ssh map ruimer staat dan 0700

Hier niet. Op zowel Debian 7 als 8 .ssh dirs met 755 en geen enkel protest

pven schreef op maandag 07 september 2015 @ 07:14:
Ssh via backup werkt dus ook niet, zelfde melding. Terwijl rsync via ssh wel werkt. Dit laatste is voor mij het echte raadsel.

Zoals Thralas en ik al aangaven, je rsynct over het rsync-protocol (wat onveilig is) en niet over ssh. Je rsync heeft dus niks met ssh te maken.

Als je verder wil met je probleem helpt het trouwens als je vragen beantwoordt

[Hero of Time]

deadinspace schreef op maandag 07 september 2015 @ 16:10:
[...]

Hier niet. Op zowel Debian 7 als 8 .ssh dirs met 755 en geen enkel protest

Doe je dat terwijl je een pub/private key combi hebt en gebruikt? Want dan gaat 't echt wel zeiken. Vaak genoeg gehad.

[deadinspace]

Hero of Time schreef op maandag 07 september 2015 @ 16:12:
Doe je dat terwijl je een pub/private key combi hebt en gebruikt?

Jep (password logins zijn sowieso disabled op de machines die ik beheer).

Want dan gaat 't echt wel zeiken. Vaak genoeg gehad.

Ik herinner het me ook vagelijk van vroeger, maar nu? Nope:

% ls -ld .ssh .ssh/known_hosts .ssh/authorized_keys 
drwxr-xr-x 2 user user  4096 Aug 21 13:39 .ssh/
-rw-r--r-- 1 user user  1482 May 28 10:45 .ssh/authorized_keys
-rw-r--r-- 1 user user 31258 Aug 21 13:39 .ssh/known_hosts
% ssh yoda uptime                                  
 17:04:20 up 4 days,  8:29,  1 user,  load average: 0.12, 0.13, 0.09
%

Sterker nog, ik kan ~/.ssh world-writable maken, en dan nog kan ik vanuit dat account ssh'en. (ernaartoe ssh'en werkt niet meer, sshd vertrouwt de authorized_keys niet meer)

[CAPSLOCK2000]

Als rsync wel werkt dan zou ik de logs van de server downloaden en daar in gaan zoeken naar aanwijzingen, te beginnen met /var/log/auth.log

[Hero of Time]

Er uiteraard van uitgaande dat rsync met root werkt, want /var/log/auth.log is alleen te lezen door root.

[pven]

Ik heb rsync dicht getimmerd: ik kan alleen de backup-directory benaderen, verder niets. .ssh heb ik kunnen downloaden, daar staat niets bijzonders in. Tijd voor de rescue mode?

De boot-volgorde kan ik wijzigen naar rescue mode, maar wat dan? Hoe kom ik er dan wel bij? (Ik ben nog aan het Google'n, ik vind nogal wat. Ff lezen ...)

Ah: als ik herstart, krijg ik een mailtje van de hoster met de tijdelijke login. Ik zit nu als root in de rescue mode, en probeer uit te vogelen hoe ik dat wachtwoord kan wijzigen. Ik heb storage gemount, en kan dus bij alles. Weer even puzzelen ...

---

Nu ik eens wat langer na heb gedacht, heb ik nog ergens een yum update gedraaid die succesvol leek te zijn. Wel heb ik het idee dat het sinds die tijd fout zit.

Inmiddels het ik via copy/paste het root-wachtwoord gewijzigd, maar helaas ... hetzelfde resultaat. Bij deze de erg uitgebreide logging (daar waar nodig gecensureerd):

DiskStation> ssh -vvv [e-mail]
OpenSSH_6.6, OpenSSL 1.0.1p-fips 9 Jul 2015
debug2: ssh_connect: needpriv 0
debug1: Connecting to werktniet.com [3.1.1.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6p2-hpn14v4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: Remote is NON-HPN aware
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x1c000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "werktniet.com" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [e-mail],[e-mail],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: kex_parse_kexinit: [e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [e-mail],[e-mail],ssh-rsa,[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],[e-mail],[e-mail],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[e-mail],[e-mail],[e-mail],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: kex_parse_kexinit: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[e-mail],[e-mail],[e-mail],[e-mail],hmac-md5,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[e-mail],[e-mail],[e-mail],[e-mail],hmac-md5,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-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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[e-mail]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[e-mail],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[e-mail]
debug2: kex_parse_kexinit: none,[e-mail]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup [e-mail]
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr [e-mail] none
debug2: mac_setup: setup [e-mail]
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr [e-mail] none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1548/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 88:ff:ni:et:48:b8:45:42:1a:ff:ni:et:49:f2:b6:04
debug3: load_hostkeys: loading entries for host "werktniet.com" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "37.187.100.17" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'werktniet.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:5
debug2: bits set: 1527/3072
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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa (0x20191b08),
debug2: key: /root/.ssh/id_dsa ((nil)),
debug2: key: /root/.ssh/id_ecdsa ((nil)),
debug2: key: /root/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred 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: Offering RSA 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,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ecdsa
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
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
[e-mail]'s password:
debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
[e-mail]'s password:

Ik blijf hoop houden.

[Voor 114% gewijzigd door pven op 07-09-2015 23:01]

[Donaldinho]

debug3: no such identity: /root/.ssh/id_dsa: No such file or directory
debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method

misschien eens opnieuw een pub/private keypair generen, uitwisselen en opnieuw proberen? hoe staan de rechten van je .ssh dir en je authorized_keys en private key?

[pven]

Ga ik straks naar proberen te kijken, wederom dank.

Voor mijn beeld: ik kan via de rescue mode bij mijn storage komen. Wat is dan de beste manier om een wachtwoord aan te passen? (Wat ik nu heb gedaan is het tijdelijk wachtwoord van root uit /etc/shadow plukken en plakken naar mijn 'eigen' shadow, uiteraard met behoud van rechten.)

[Voor 30% gewijzigd door pven op 08-09-2015 08:34]

[Hero of Time]

Hmm, wel vreemd dat je je id_rsa private key wordt gebruikt, maar niet geaccepteerd. Het gaat vervolgens kijken naar id_dsa, wat je logischerwijs niet hebt omdat die niet standaard gemaakt wordt (en dan zou je 'm alsnog moeten toevoegen aan authorized_keys.

Voor het wijzigen van je wachtwoord is het beste om een chroot te maken en dan passwd uitvoeren op de server. Als je al in / zit, met /etc beschikbaar, dan hoef je alleen maar een 'passwd' uit te voeren om 't wachtwoord te wijzigen.

[pven]

Ik heb eindelijk eens tijd gemaakt om dit verder op te lossen. Na de nodige mounts en chroot heb ik volgens mij het wachtwoord van mijn 'echte' root-account kunnen wijzigen. Helaas ... na een herstart om uit de rescue-mode te komen kom ik er nog steeds niet in.

Ik zal eens kijken of er in /var/log/auth.log of /var/log/syslog wat te vinden is.

TIps zijn meer dan welkom!

---

Nu ik eens wat langer na heb gedacht, heb ik nog ergens een yum update gedraaid die succesvol leek te zijn. Wel heb ik het idee dat het sinds die tijd fout zit.

In /var/log zie ik yum.log staan, die is van net voor dat de ellende begon. Kan ik nog iets met die log? Ik zie eigenlijk alleen maar meldingen dat het succesvol was.

In /var/log zie ik overigens geen auth.log of syslog staan:

-rw-------  1 root    root    1610584 Oct 18 03:37 secure-20151018
-rw-------  1 root    root    1162223 Oct 18 03:39 cron-20151018
drwx------  2 root    root       4096 Oct 18 03:39 httpd
-rw-------  1 root    root      29977 Oct 18 03:39 messages-20151018
-rw-------  1 root    root          0 Oct 18 03:39 spooler
-rw-r--r--  1 spotweb root   67788152 Oct 18 20:46 spotweb
drwxr-xr-x  7 root    root       4096 Oct 18 21:29 .
-rw-r--r--  1 root    root      33157 Oct 18 21:29 dmesg
-rw-r-----  1 mysql   mysql     11121 Oct 18 21:30 mysqld.log
-rw-------  1 root    root      51627 Oct 18 21:30 messages
-rw-------  1 root    root       5396 Oct 18 21:30 maillog
-rw-rw-r--  1 root    utmp     155904 Oct 18 21:30 wtmp
-rw-------  1 root    utmp    9382272 Oct 18 21:32 btmp
-rw-------  1 root    root     809363 Oct 18 21:32 secure
-rw-------  1 root    root     119751 Oct 18 21:34 cron

[Voor 68% gewijzigd door pven op 18-10-2015 21:42]

[fsfikke]

Kom je totaal niet meer in je server? Hoe ziet de (/etc/ssh/)sshd_config er uit? Vooral de entries:
PermitRootLogin
PubkeyAuthentication
AuthorizedKeysFile
ChallengeResponseAuthentication
PasswordAuthentication

[pven]

In de log secure zie ik overigens, naast alle hack-attempts, het volgende staan:

Oct 18 21:31:23 ks3363521 sshd[3429]: User root from <mijnip> not allowed because not listed in AllowUsers
Oct 18 21:31:23 ks3363521 sshd[3430]: input_userauth_request: invalid user root
Oct 18 21:31:31 ks3363521 sshd[3429]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<mijnip>  user=root
Oct 18 21:31:33 ks3363521 sshd[3429]: Failed password for invalid user root from <mijnip> port 49350 ssh2

fsfikke schreef op zondag 18 oktober 2015 @ 21:43:
Kom je totaal niet meer in je server? Hoe ziet de (/etc/ssh/)sshd_config er uit? Vooral de entries:
PermitRootLogin
PubkeyAuthentication
AuthorizedKeysFile
ChallengeResponseAuthentication
PasswordAuthentication

Via rsync kan ik nog wel bestanden syncen, en via rescue/chroot kom ik nog wel ergens bij.

Ik heb het opgezocht:
#PermitRootLogin yes
#AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
PasswordAuthentication yes

Hmz, opvallend dat die eerste twee uitgevinkt zijn. Aan de andere kant is sshd_config sinds vier maanden niet meer gewijzigd.

Uithekken maar en weer proberen?

[fsfikke]

Inderdaad, die even aanvinken en kijken of je er simpelweg met het wachtwoord weer in kan. Daarna zou ik die instellen op PermitRootLogin without-password zodat je er alleen met een ssh-key in kan.

En de
AuthorizedKeysFile ook activeren.

[Voor 47% gewijzigd door fsfikke op 18-10-2015 21:54]

[pven]

Done, maar helaas ...

Wederom uit /var/log/secure:

Oct 18 21:56:20 ks3363521 sshd[3422]: User root from <mijnip> not allowed because not listed in AllowUsers
Oct 18 21:56:20 ks3363521 sshd[3423]: input_userauth_request: invalid user root
Oct 18 21:56:24 ks3363521 sshd[3422]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<mijnip>  user=root
Oct 18 21:56:26 ks3363521 sshd[3422]: Failed password for invalid user root from <mijnip> port 50666 ssh2
Oct 18 21:56:51 ks3363521 sshd[3423]: Connection closed by <mijnip>

[fsfikke]

Wat staat er in sshd_config onder AllowUsers?
Ander misschien onderaan
AllowUsers root

toevoegen.

[Voor 39% gewijzigd door fsfikke op 18-10-2015 22:17]

[pven]

WTF: dat is hem!

Ik had daar een sftp-user staan, daar heb ik nu root aan toegevoegd. Nu kom ik dus wel binnen. Wat vaag zeg: maandenlang is die config niet gewijzigd, maar sinds een update via yum kwam ik er dus niet meer in.

Mijn dank is groot! Ik ga een dezer dagen eens verder kijken hoe ik mijn server beter dicht kan timmeren.

Thanks!

[BoAC]

Dat hebben ze vanuit de Distributie natuurlijk niet voor niets in gezet
Eigenlijk wil je niet als Root binnen kunnen komen via wat voor protocol dan ook (beter: moet je niet willen)

[Raven]

pven schreef op zondag 18 oktober 2015 @ 22:21:
Wat vaag zeg: maandenlang is die config niet gewijzigd, maar sinds een update via yum kwam ik er dus niet meer in.

Updates en config-files, don't get me started

Laatst heb ik bijv. Raspbian Wheezy ge-distupgrade naar Jessie. Tijdens het upgraden werd meerdere keren door apt-get gevraagd om een config te overschrijven door een nieuwe versie. Die vragen heb ik allemaal bevestigd.

Uiteindelijk werkte Apache niet meer goed (DocumentRoot was verandert) en vsftpd gaf voor elke actie (rm/mv/cp/mkdir) een 550 permission denied error. Daar moest een # weggehaald worden (#write_enable=YES).

Dus ja, het kan kloppen dat die update hier voor heeft gezorgd.