Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Ohjelmointi, palvelimet ja muu edistyneempi käyttö => Aiheen aloitti: teele - 12.06.25 - klo:11.13
-
Ubuntu 20.04 -jakelun tukiaika loppui ja jouduin päivittämään pilvikoneeni do-release-upgrade -komennolla. Kaikki näytti menneen hyvin ja pilvikoneella ollut nettisivukin toimi.
Mutta kun yritin pääkäyttäjänä ssh:lla kirjautua koneelle, tuli ilmoitus, että pääkäyttäjäni ei ole enää sudoilulistalla. Nyt en pääse tekemään tarjottuja tietoturvapäivityksiä enkä varmaan paljon muutakaan, mikä olisi tarpeellista.
Miten tilanteesta voi selvitä? Pääkäyttäjä oli tietääkseni ainoa sudoilija, jolleivät jotkut ohjelmat automaattisesti lisänneet itseään sudoilijoiksi.
-
Jäi hiukan itselle epäselväksi, että yrititkö kirjautua roottina vai käyttäjänä ja tehdä ylläpitotöitä sudona? En oikein jaksa uskoa, että käyttäjä tipahtaisi sudoers listalta pois. Mutta ssh:lla voisi kait configissa helposti käydä niin, että /etc/ssh/sshd_config tiedostossa permitrootlogin=true ehto tipahtaisi pois jos järjestelmä päivittää alkuperäiseen muotoon?
-
Onkohan siinä pilvikoneessa mahdollisuutta käynnistää asennuslevykuvasta ja käyttää etäpäätettä? Sillä ainakin pääsisi liittämään levyn ja muokkaamaan tiedostoja.
-
Mutta kun yritin pääkäyttäjänä ssh:lla kirjautua koneelle, tuli ilmoitus, että pääkäyttäjäni ei ole enää sudoilulistalla. Nyt en pääse tekemään tarjottuja tietoturvapäivityksiä enkä varmaan paljon muutakaan, mikä olisi tarpeellista.
Miten tilanteesta voi selvitä? Pääkäyttäjä oli tietääkseni ainoa sudoilija, jolleivät jotkut ohjelmat automaattisesti lisänneet itseään sudoilijoiksi.
Mihin ryhmiin tunnus kuuluu? Tarkista groups-komennolla, kun olet kirjautuneena kyseisellä tunnuksella:
groups
Jos oikeudet ovat oikeasti hävinneet, pilvikoneen tapauksessa käynnistäminen root-kehotteeseen voi olla hankalaa. Periaatteessa se saattaisi onnistua palveluntarjoajan web-käyttöliittymän kautta, jos se tarjoaa tekstikonsolin virtuaalikoneelle. Siellä voisi yrittää päästä GRUB-valikkoon ja sen kautta recovery-tilaan, olettaen että koneella edes on GRUB-lataaja.
Tomin ehdottama asennuslevykuvan tai esim. SystemRescue-levyn liittäminen voisi olla myös yksi mahdollisuus, jos siis pääset virtuaalikoneen konsoliin muutenkin kuin SSH:lla.
-
Pilvikone on hetznerin pienin vaihtoehto, johon ruksattiin käyttikseksi ubuntu muutamia vuosia sitten. En ole sen jälkeen ollut hetznerin kanssa tekemisissä enkä tunne sen etäkonehallintaa :(
Millään ubuntu-kikalla tilanteesta ei selvinne? Hetznerin hallinnointi on ihan uusi alue, jossa pitäisi ymmärtää etäkoneista edes jotain, eikä hallintakonsolia ole tarvinnut käyttää koskaan.
Jos jollain on vihjettä siitä miten hetznerin pilvikoneen voisi käynnistää sellaiseen tilaan, että sudoilijan saa lisättyä, se tieto voisi olla nyt pelastus.
-
Pilvikone on hetznerin pienin vaihtoehto, johon ruksattiin käyttikseksi ubuntu muutamia vuosia sitten. En ole sen jälkeen ollut hetznerin kanssa tekemisissä enkä tunne sen etäkonehallintaa :(
Millään ubuntu-kikalla tilanteesta ei selvinne? Hetznerin hallinnointi on ihan uusi alue, jossa pitäisi ymmärtää etäkoneista edes jotain, eikä hallintakonsolia ole tarvinnut käyttää koskaan.
Jos jollain on vihjettä siitä miten hetznerin pilvikoneen voisi käynnistää sellaiseen tilaan, että sudoilijan saa lisättyä, se tieto voisi olla nyt pelastus.
Eikait tuossa ole muuta vaihtoehtoa kuin tuo nm:n mainitsema etäkonsoliyhteys? Olettaisin että jonkin ticketin joutuu tehdä aspaan.
Mutta mielenkiinnosta vilkaisin https://www.hetzner.com/cloud/ sivun ja pisti silmään 7kpl snapshotteja. Palauta palvelin aiempaan tilaan jos mahdollista? Oletan että kyseessä ei ole siis mikään webkauppa tms. Toihan nimittäin täytyy onnistua jostain tilitiedoista suoraan.
-
Hetznerin ohjeen mukaan virtuaalikoneen voi helposti käynnistää rescue-järjestelmään, johon kirjaudutaan SSH:lla tai selaimessa toimivalla VNC-konsolilla. Rescue-järjestelmän kirjautumistunnus on root, ja Hetznerin pilvikonsoli kertoo salasanan, kun kytket rescue-tilan käyttöön.
https://docs.hetzner.com/cloud/servers/getting-started/rescue-system
https://docs.hetzner.com/cloud/servers/getting-started/vnc-console/
Tuolla voit sitten liittää varsinaisen järjestelmälevyn ja tehdä tarvittavat muutokset asetustiedostoihin.
Virtuaalikone pitää käynnistää uudelleen, jotta pääset pois rescue-järjestelmästä ja saat taas Ubuntun käyntiin.
-
Selvittelin tilannetta
groups kt1
kt1 : kt1 kt2 kt3 i
eli pääkäyttäjäni on kt1 ja sitten olen tehnyt pari muuta käyttäjää linux-oikeuksien harjoitteluun
kt1 ei näytä kuuluvan sudoers -ryhmään, pitäisikö se näkyä
mutta olen muuten vähän jäljessä selvittelyjeni kanssa, seuraavaksi yritän opiskella niitä hetzner-ohjeita, joita jo ollen edellä saanut ....
-
sudo-ryhmään pitäisi kuulua.
Veikkaan, että olet itse muuttanut tunnuksen ryhmiä ja samalla poistanut vahingossa sudo-ryhmän jäsenyyden. Tämä tapahtuu ainakin komennolla "usermod -G ryhmä1,ryhmä2,ryhmä3", jos append-vipu -a on jäänyt komennosta pois.
-
Viimeisin sudo-komento oli do-release-upgrade, ja sitten kun ekan kerran yritin ottaa tarjottuja tietoturvapäivityksiä, yllätys oli, että en enää kuulukaan sudoiluryhmään.
Pilvikoneen päätteessä on vain muutama päivitysten tarkastamiseen ja uudelleenkäynnistämiseen liittyvä komento ollut käytössä, joita ajelen peruuttamalla pari komentoa vanhemman suuntaan, eli en uskoisi, että olen poistanut kt1 -käyttäjää
-
Pilvikoneen päätteessä on vain muutama päivitysten tarkastamiseen ja uudelleenkäynnistämiseen liittyvä komento ollut käytössä, joita ajelen peruuttamalla pari komentoa vanhemman suuntaan, eli en uskoisi, että olen poistanut kt1 -käyttäjää
Jossain vaiheessa olet kuitenkin lisännyt tuon kt1-tunnuksen muiden tunnusten ryhmiin kt2 ja kt3. Se ei tapahdu automaattisesti.
Kuulostaa oudolta, että jakelupäivitys olisi jotenkin poistanut käyttäjätunnuksia sudo-ryhmästä.
-
kokeilin komentoa su ja se näytti toimivan, kysyttiin salasana ja olin kirjautuneena roottina, sitten kokeilin
adduser kt1 sudo
Adding user `kt1' to group `sudo' ...
Adding user kt1 to group sudo
Done.
toivottavasti sudo on oikea ryhmän nimi eikä esimerkiksisudoers tms.
ja sitten yritin niiäpäivityksiä
sudo apt upgrade
[sudo] password for kt1:
kt1 is not in the sudoers file. This incident will be reported.
netissä oli ohje, että komento tulee voimaan, jos koneen käynnistää uudelleen, mutta ainkaan kt1 ei voi laittaa sudo reboot komentoa, kuten edelllä näkyy. uskaltaisiko kokeilla sitä roottina .... ?
muokk.
nyt groups komennolla näkyy
groups kt1
kt1 : kt1 sudo kt2 kt3
-
netissä oli ohje, että komento tulee voimaan, jos koneen käynnistää uudelleen
Riittää että kirjaudut uudelleen sisään.
muokk.
nyt groups komennolla näkyy
groups slam1
kt1 : kt1 sudo kt2 kt4
Ryhmä näyttää olevan nyt voimassa. Onkohan sudo nyt asetettu muuten oikein? Katso roottina, mitä /etc/sudoers-tiedosto sisältää:
cat /etc/sudoers
-
tällaista näyttäisi olevan
su
Password:
root@kt1-hki:/home/kt1# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults use_pty
# This preserves proxy settings from user environments of root
# equivalent users (group sudo)
#Defaults:%sudo env_keep += "http_proxy https_proxy ftp_proxy all_proxy no_proxy"
# This allows running arbitrary commands, but so does ALL, and it means
# different sudoers have their choice of editor respected.
#Defaults:%sudo env_keep += "EDITOR"
# Completely harmless preservation of a user preference.
#Defaults:%sudo env_keep += "GREP_COLOR"
# While you shouldn't normally run git as root, you need to with etckeeper
#Defaults:%sudo env_keep += "GIT_AUTHOR_* GIT_COMMITTER_*"
# Per-user preferences; root won't have sensible values for them.
#Defaults:%sudo env_keep += "EMAIL DEBEMAIL DEBFULLNAME"
# "sudo scp" or "sudo rsync" should be able to use your SSH agent.
#Defaults:%sudo env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"
# Ditto for GPG agent
#Defaults:%sudo env_keep += "GPG_AGENT_INFO"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "@include" directives:
@includedir /etc/sudoers.d
muokk.
kirjauduin pilveen uudellen, sudoilu näytti toimivan kt1:nä, ja otin päivitykset ....
Tämänkin säikeen voinee laittaa ratkaistuksi eikä tarvinnut edes opiskella hetzneriä, mikä on toisaalta helpotus, mutta tulevaisuudessa voi kuitenkin sekin olla edessä.
Yhtenä oppina tilanteesta voisi olla se, että vaikka pilvikoneen ainoa pääkäyttäjä on kadonnut sudoilulistalta ja koneen hallinta ei onnistu tutulla tavalla enää, ei kannata panikoitua, vaan voi kokeilla myös su -reittiä.
Kiitoksia neuvoista :)
-
Yhtenä oppina tilanteesta voisi olla se, että vaikka pilvikoneen ainoa pääkäyttäjä on kadonnut sudoilulistalta ja koneen hallinta ei onnistu tutulla tavalla enää, ei kannata panikoitua, vaan voi kokeilla myös su -reittiä.
Root-kirjautuminen su-komennolla onnistui siksi, että Hetznerin Ubuntu-asennuksissa on nähtävästi asetettu root-käyttäjälle salasana. Normaalisti sitä ei ole asetettu Ubuntussa, eikä sama onnistuisi esimerkiksi AWS:n, Azuren ja GCP.n Ubuntu-virtuaalikoneissa, ellei ylläpitäjä ole itse lisännyt rootille salasanaa.