Login via SSH op Ubuntu VPS lukt niet meer; Shell verprutst?

[Mafioso]

Beste Tweakers,

Ik zit sinds eerder deze avond met een vervelende situatie: ik kan plots niet meer inloggen op mijn Ubuntu 13.04 VPS.
Mijn key wordt niet meer geaccepteerd, en wordt om een wachtwoord gevraagd. Deze wordt echter ook niet geaccepteerd.

Het laatste waarmee ik mee bezig was, is het aanpassen van de shell (via sudo chsh -s ...). Ik zag nl dat ik nog een oude versie van fish-shell gebruikte (1.23 uit de universe repo), en had daarom een nieuwe versie gecompileerde en geïnstalleerd. Ik vermoed dat hier iets bij mis is gegaan.

Ik heb namelijk via de CloudVPS Web Console geprobeerd in te loggen, maar daar gaat het ook mis. Als ik mijn username en password invoer krijg ik meteen weer vraag voor de login. Als ik echter een verkeerd wachtwoord invoer word er nog eens om mijn wachtwoord gevraagd. Dit doet mij vermoeden dat ik wel degelijk het juiste wachtwoord invoer, maar dat misschien de shell voor problemen zorg.

Zover ik weet/herinner heeft de root account geen wachtwoord ingesteld, waardoor ik daarmee ook niets op schiet. Er zijn geen andere gebruikers in het systeem die shell access hebben.
Ik heb het systeem herstart, maar dit heeft niets geholpen.

Is er nog een manier om mijn systeem te redden?

Misschien nog belangrijk om op te merken: er is fail2ban geïnstalleerd op de VPS, maar ik denk niet dat die voor de problemen zorgt. Hier ontvang ik geregeld mailtjes van als er een adres wordt geblokkeerd, maar die heb ik nu niet gehad.

[CyBeR]

ssh user@host /bin/bash

je krijgt geen prompt omdat de shell niet technisch gezien 'interactive' is, maar je kunt er wel commando's mee uitvoeren, zoals het weer terug veranderen van je shell naar een die wel werkt. (evt kun je -i proberen mee te geven.)

[ Voor 7% gewijzigd door CyBeR op 30-04-2013 01:39 ]

[johnkeates]

Met ^

Je kan gewoon een andere shell opgeven, ook als SSH denkt dat je niet een interactief programma gestart hebt.

Waarom heb je trouwens maar 1 user? Voor dit soort dingen is het o.a. heel belangrijk dat je dus minimaal 2 toegankelijke users hebt, waarbij er minimaal 1 met keyboard-interactive kan inloggen. Of heb je alleen de root user? Want dat is ook niet de meest beste setup qua veiligheid

[Mafioso]

Goede truc om te weten dat ssh .. commando, maar het lukt mij helaas niet mee om in te loggen. Misschien heeft het dan toch niet met die shell te maken...

De root user op het systeem gebruik ik noot, en ik was in de veronderstelling dat ik daar access via ssh ook voor had uitgeschakeld.
Mijn 'normale' user account heeft wel toegang en is lid van de sudoers groep voor taken die 'root'-access vereisen.

Maar had zojuist een ingeving.. laat ik toch mijn mail nog eens doorzoeken, en jawel: ik heb ooit na het aanmaken van de VPS het root wachtwoord per email ontvangen. (Deze stond niet in mijn passkee file, dus wacht ik deze niet had.)
En het belangrijkste: ik kan er mee inloggen!

Wat de oorzaak van mijn probleem is weet ik nog niet helemaal, maar zodra ik het weet post ik het hier. Wie weet is het nog eens voor een toekomstige lezer van nut.

[franssie]

wel even dat wachtwoord veranderen, als het over mail gegaan is, is het niet meer veilig.

[Mafioso]

Poging in te loggen vanaf Windows 7 pc, in dit geval in een bash-shell (Git):

# @ client
# ssh -v *****@37.34.xxx.xxx /bin/bash
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/*****/.ssh/identity
debug1: Offering public key: /c/Users/*****/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /c/Users/*****/.ssh/id_dsa
debug1: Next authentication method: password
*****@37.34.xxx.xxx's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
*****@37.34.xxx.xxx's password:

Blijkbaar zorgt toch de ontbrekende shell voor de problemen, voordat het commando (/bin/bash) wordt uitgevoerd wordt al besloten dat ik geen toegang heb.

# tail /var/log/auth.log
Apr 30 00:54:08 lab sshd[1435]: User ***** not allowed because shell /usr/bin/fish does not exist
Apr 30 00:54:08 lab sshd[1435]: input_userauth_request: invalid user ***** [preauth]
Apr 30 00:54:10 lab sshd[1435]: Connection closed by 188.142.xxx.xxx [preauth]

Wat ik ook probeer, chsh werkt niet mee

# chsh -s /bin/bash *****
Password:
chsh: PAM: Authentication failure

# nano /etc/passwd
# .. zelf maar shell veranderd voor mijn user-account

Nog een login poging via ssh, nu wel met succes!

# tail -f /var/log/auth.log
Apr 30 02:34:45 lab sshd[1696]: Accepted publickey for ***** from 188.142.xxx.xxx port 60698 ssh2
Apr 30 02:34:45 lab sshd[1696]: pam_unix(sshd:session): session opened for user ***** by (uid=0)

Nadat ik zeker weet weer toegang via mijn normale account te hebben het root wachtwoord veranderd

# passwd root
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Ik ben er mooi klaar mee!

[Hero of Time]

Tja, weet je nou wat je fout hebt gedaan? Want de error staat duidelijk in je log.

[Mafioso]

Jup, /usr/bin/fish verwees nog naar de locatie van de oude versie van fish-shell. Die had ik echter via sudo apt-get remove fish al verwijderd. Ik vrees dat ik daarna ben vergeten om de shell voor mijn gebruiksaccount te veranderen, of dat dit per ongeluk (alleen) voor de root account heb gedaan.

Ik had beter kunnen wachten met het verwijderen van fish 1.x totdat ik zeker wist dat ik automatisch na het inloggen in de nieuwe versie van fish shell terecht kwam. (Of eerst weer bash instellen).

[Hero of Time]

En vergeet ook niet dat je zelf gecompileerde versie die van je package manager zou vervangen, als je tenslotte 'fish' zou hebben getypt in een prompt, had je die ook gekregen. Echter is standaard /usr/local/ de prefix voor alle zelf gecompileerde programma's. Als je bij ./configure de prefix had opgegeven, was er niets aan de hand geweest. Tenzij de compilatie niet volledig zou zijn geweest en je een kapotte binary krijgt.

[Mafioso]

Klopt ja, dit is weer een wijze les . Ik had de gecompileerde versie wel getest, en ook gecheckt dat deze onderdeel was van $PATH (which fish && fish -V), maar had niet door dat op een of andere manier ik het chsh commando was vergeten, of dat daar iets mis ging.

[synoniem]

Door soortgelijke problemen heb ik tegenwoordig de methode om twee sessies tegelijk starten zodat er één ingelogd blijft terwijl je met de ander probeert of het werkt. Kan het aanbevelen!