Skip to content

Instansåtkomst ​

Öppna en interaktiv terminal på din egen instans med fm shell. Instansens agent ringer ut till Frostmoln och terminalen färdas på den anslutningen, så den här vägen kräver ingen publik IP, ingen öppen port, ingenting som lyssnar på instansen och ingen nyckel från dig — och den öppnar ingen inkommande väg att nå.

Det är inte SSH: den använder inte port 22, ingen nyckel är inblandad, och det finns inget för dig att öppna i en säkerhetsgrupp — därför heter kommandot fm shell och inte fm ssh (både fm ssh och fm session fungerar fortfarande som alias). Det här ändrar ingenting på själva instansen: det den lyssnar på lyssnar den fortfarande på, och SSH till din egen instans är oförändrat och fullt ut stött. Instansåtkomst är ett ytterligare sätt att komma in, användbart just när SSH inte är det: en instans utan publik IP, en säkerhetsgrupp som stänger ute dig, en nyckel du inte längre har.

Den väljs när instansen skapas ​

Den kan inte läggas till på en befintlig instans

En instans kan nås på det här sättet bara om den skapades med instansåtkomst påslagen. Agenten hämtar sin identitet från instansen vid första uppstarten, och det finns ingen väg att registrera en instans som redan är igång. För att ge en befintlig instans en terminal får du skapa om den.

Slå på det när instansen skapas, från CLI:t eller från Terraform. Portalens formulär för att skapa instanser erbjuder det inte ännu.

bash
fm compute instance create \
  --name web-1 \
  --image <image-id> \
  --flavor gp1.small \
  --instance-access
hcl
resource "frostmoln_instance" "web" {
  name            = "web-1"
  instance_access = true
  # ...
}

I Terraform går instance_access bara att sätta vid skapandet. Att ändra huruvida agenten installeras tvingar fram en ersättning (false och osatt betyder båda ingen agent, så att gå mellan de två gör det inte). API:t returnerar det inte och terraform import lämnar det osatt, så instance_access = true på en importerad instans planerar en ersättning.

Avbilden måste kunna köra agenten, och instansen måste fortsätta nå Frostmoln utgående så länge du vill ha en terminal. Plattformens avbilder gör redan båda. Startar du din egen avbild, se Egna avbilder för vad installationen behöver och för de två sätt som registreringen misslyckas tyst.

Instansåtkomst finns bara för x86_64-Linux: agenten behöver den arkitekturen samt systemd och cloud-init, så Windows-instanser kan inte använda den. Nå dem via konsolen i stället.

Öppna en terminal ​

bash
fm shell 9b6b2d0e-1f4c-4a7e-9c3d-2b8f5e6a1d04

Argumentet är instansens id, inte dess namn. Skriv början på endera så fyller tab-komplettering i id:t.

Lägg ett kommando efter -- för att köra det i stället för att öppna en terminal:

bash
fm shell 9b6b2d0e-... -- systemctl is-active nginx

Den formen är skriptsäker — utdata radbrytningsmanglas inte, och kommandots egen slutkod blir fm😒 slutkod. En sak att känna till vid omdirigering: kommandots stdout och stderr kommer sammanslagna på fm😒 stdout, så fm shell … -- cmd > out.txt fångar båda. Lägg till --tty om du ändå behöver en terminal.

Vilken användare du blir ​

Du hamnar som avbildens standardanvändare — debian på Debian, ubuntu på Ubuntu, och så vidare. På plattformens avbilder är det samma användare som SSH ger dig. Logga in som någon annan med --user:

bash
fm shell 9b6b2d0e-... --user deploy

En egen avbild utan användbar standardanvändare ger dig en root-terminal

Inloggningsanvändaren härleds från avbilden när instansen skapas, och varje sätt som den härledningen kan misslyckas på landar dig på root i stället — tyst. Den misslyckas när avbilden inte anger någon standardanvändare, när dess distribution inte är en plattformen känner igen, och när namnet den anger inte går att använda som inloggningskonto. Det sista är fällan: ett namn med versaler, till exempel MyUser, godtas när du laddar upp avbilden och visas som inloggningsanvändare, men sessionen körs ändå som root.

Vill du inte ha en root-terminal, ge avbilden en standardanvändare skriven med gemener innan du skapar instanser från den, och kontrollera vilken användare du faktiskt hamnar som första gången.

Sessioner är tidsbegränsade ​

En session avslutas efter 10 minuter utan aktivitet, eller 1 timme totalt — det som inträffar först. Status 255 betyder att sessionen dog — en gräns, en bruten anslutning, eller att fm självt dödades. Kan fm inte öppna sessionen alls avslutas det med 1 och ett meddelande på stderr. Varje annan slutkod kommer från ditt eget kommando.

Vad som styr åtkomsten ​

  • Din egen organisations instanser. Du kan öppna en terminal på instanser i de tenants din organisation äger. Allt annat är hittades inte — samma svar oavsett om instansen inte finns eller inte är din.
  • Bara där du slagit på det. Instansåtkomst gäller per instans och väljs när instansen skapas. En instans som skapades utan den kan över huvud taget inte nås på det här sättet, av någon.
  • Tidsbegränsat. Ingen session hålls öppen hur länge som helst.

Ingen begränsning per medlem ännu — och en tenant är inget stängsel

Varje aktiv medlem i din organisation kan öppna en terminal på vilken instans som helst med instansåtkomst påslagen, oavsett roll, och i vilken som helst av de tenants din organisation äger — inte bara den de normalt arbetar i. Betrakta alltså inte en separat tenant som en åtkomstgräns här: att lägga en känslig arbetslast i en egen tenant håller inte dina andra medlemmar borta från den. Vilken API-nyckel som helst i den tenanten kan också öppna en session.

Ingen inställning smalnar av det till vissa personer, och ingen åtkomstpolicy stängslar in det heller.

Tills något gör det är valet vid skapandet gränsen: låt instansåtkomst vara avstängd på de instanser där det spelar roll, och nå dem via SSH, där du bestämmer vem som har en nyckel.

Särskilt för API-nycklar är sessions:pty den behörighet som kommer att avgränsa det här, och inget annat träder i dess ställe — varken compute:* eller ett jokertecken, som en nyckel inte får ha. Ge den redan nu till nycklar som kör fm shell, så att de är rätt från början. Lita inte på den som gräns ännu: den kontrolleras inte när en session öppnas, så i dag öppnar en nyckel utan den ändå en. Se API-nycklar.

Vad påslaget lägger på instansen ​

Värt att veta innan du slår på det, för det är din maskin:

  • Agenten kör som root, och medvetet utan den sandlådning plattformen använder på sina egna hanterade instanser — den måste kunna starta en terminal som vilken användare du än ber om.
  • Dess identitetsuppgift är läsbar för varje process på instansen, samma hållning som en instansroll-uppgift hos andra moln.
  • En ögonblicksbild eller avbild av en registrerad instans bär med sig den identiteten, och något återställt från den kan agera som originalet. Behandla en avbild tagen från en registrerad instans som känslig, och bygg hellre avbilder från instanser som aldrig haft instansåtkomst påslagen.
  • Sessioner skapar ingen inloggningspost, så who, last och utmp visar dem inte. Revidera inne i instansen om du behöver ett spår.

När det inte fungerar ​

Vad fm säger till digVad du gör
instance not found or instance access not enabledId:t är fel, instansen tillhör inte den här tenanten, eller så skapades den utan instansåtkomst. På en nyss skapad instans kan agenten fortfarande hålla på att installeras.
this instance can't do terminal sessionsInstansen har en agent, men inte en som betjänar terminaler. fm föreslår också att uppdatera agenten; någon väg att uppdatera agenten finns ännu inte, så att skapa om instansen är enda vägen.
the instance's agent is offlineInstansen är stoppad, startar fortfarande, eller har tappat sin utgående väg till Frostmoln. Försök igen om en stund.
the instance agent is up and at its session limitFör många sessioner är öppna på instansen samtidigt. Stäng en — att bara försöka igen hjälper inte. Kvarstår det när du inte har någon öppen, kontakta supporten.
session ended by the platformGränsen för inaktivitet eller total tid tog slut, eller så bröts anslutningen. Öppna en ny session.

Om en helt ny instans aldrig accepterar en session misslyckades registreringen: på instansen anger /var/log/frostmoln-managed-agent-install.log och /var/log/cloud-init-output.log orsaken. Fungerade det och slutade sedan, kontrollera att instansen fortfarande når Frostmoln utgående. Egna avbilder täcker båda i sin helhet, inklusive vad en nedbantad avbild oftast saknar.

Begränsningar ​

  • Bara vid skapandet. Instansåtkomst kan varken slås på eller av på en befintlig instans.
  • Bara CLI och Terraform. Portalen kan inte slå på den och erbjuder ingen terminal.
  • Bara x86_64-Linux — agenten behöver den arkitekturen, systemd och cloud-init.
  • Inte på startmallar eller skalningsgrupper — ingendera har någon inställning för instansåtkomst, så instanser de skapar får aldrig en terminal.
  • 10 minuter inaktiv, 1 timme totalt per session, och ett begränsat antal samtidiga sessioner per instans.
  • Ännu ingen begränsning per medlem eller per nyckel (se ovan).

Relaterat ​