I samband med att jag haft nätverksproblem (där anslutningen mellan det två servarna jag har försvunnit många gånger) har replikeringen av snapshots slutat fungera. Det blir en "connection refused" från ssh.
Sshdemonen är igång men om jag ansluter manuellt via commandopromt funkar inte root-lösenordet. Hur felsöker man? Jag vet ju i te ens som vilken användare ssh används när snappsen åker till backupsevern.....
Sshdemonen är igång men om jag ansluter manuellt via commandopromt funkar inte root-lösenordet. Hur felsöker man? Jag vet ju i te ens som vilken användare ssh används när snappsen åker till backupsevern.....
Diversearbetare
· Göteborg
· 9 665 inlägg
Radera nycklarna på resp. maskin och logga in på nytt. Nycklarna ligger i en dold mapp i hemmappen ".ssh/known_hosts". Du redigerar filen med en vanlig editor.
Redigerat:
Det är idag helt normalt att man inte tillåter "root" att logga in via ssh. Man förväntas logga in som en "vanlig" användare och sedan använda "sudo" för viktiga kommandon. Vill man absolut få en shell som root får man skriva "su -" eller möjligen "sudo su -".
Det är fine men om man ändå vill tillåta så kan man ändra i /etc/ssh/sshd_config: PermitRootLogin yesb_hasse skrev:
Eller nåt sånt, orkar inte kolla utan skriver från minnet.
EDIT: Kolla så att det inte finns under services -> ssh i FN-guit, då är det kanske bättre att ändra där istället. Tänker att FN har nån databas där den håller koll på vad man ställer in i guit, så man ska i första hand ändra i guit om man vill ha gui/underliggande helt i sync. Det lär ju inte spela nån större roll här men ska man vara petig...
Redigerat:
Det är av säkerhetsskäl man inte vill tillåta att root loggar in direkt. Anledningen är förstås att det då räcker att knäcka ett enda lösenord. Med root blockerad så måste "hackaren" få fram ett användarnamn (som har rätt att göra sudo) med tillhörande lösenord.
För att inte ge ledtrådar så ser man inte om det är användarnamnet eller lösenordet som är felaktigt när man gör en misslyckad inloggning. Man får alltså lösenordsfrågan även om användarnamnet inte existerar.
För att inte ge ledtrådar så ser man inte om det är användarnamnet eller lösenordet som är felaktigt när man gör en misslyckad inloggning. Man får alltså lösenordsfrågan även om användarnamnet inte existerar.
Japp det är av säkerhetsskäl men det är kanske mer relevant i ett världsomspännande företag med välutvecklade processer och SOPar för sin IT. Måttlig prio i hemmiljö.b_hasse skrev:
Däremot är det desto viktigare oavsett miljö att vara på tårna med säkerhetspatchning.
Dessutom, har en mer avancerad hacker väl lyckats få ett shell på hosten så spelar det mindre roll om det är som root/administrator eller opriviligerad användare, privilege escalation är bara ett par sekunder bort iaf...
Jag har min server i ett väggskåp från Ikea (80x40).
Det sitter nästan uppe mot taket men jag har tagit bort bakstycket och satt in två st 120mm fläktar som suger ut luft uppåt för att få det bättre ventilerat.
När den tidigare stod öppet nere efter golvet låg flykthastigheten på 11%. Nu varierar den mellan 18-23%. Kör Xpenology så jag kan bara läsa av temperaturerna via iLO som jag förstått inte är att lita på.
Finns det något sätt för mig att få mer pålitlig temp-info?
Å om jag skulle byta ut processorn (G1610T) mot en i5-3470T eller i5-2390T, skulle jag då sänka tempen märkvärt eftersom processorn inte behöver jobba lika hårt? Å tillräckligt mycket för att motivera köp för runt 800:-?
Eller en Xeon E3 1220L för 1500:-?
Det sitter nästan uppe mot taket men jag har tagit bort bakstycket och satt in två st 120mm fläktar som suger ut luft uppåt för att få det bättre ventilerat.
När den tidigare stod öppet nere efter golvet låg flykthastigheten på 11%. Nu varierar den mellan 18-23%. Kör Xpenology så jag kan bara läsa av temperaturerna via iLO som jag förstått inte är att lita på.
Finns det något sätt för mig att få mer pålitlig temp-info?
Å om jag skulle byta ut processorn (G1610T) mot en i5-3470T eller i5-2390T, skulle jag då sänka tempen märkvärt eftersom processorn inte behöver jobba lika hårt? Å tillräckligt mycket för att motivera köp för runt 800:-?
Eller en Xeon E3 1220L för 1500:-?
M
Marcussjogren
Medlem
· Västra Götaland
· 3 079 inlägg
Marcussjogren
Medlem
- Västra Götaland
- 3 079 inlägg
Nej det tror jag inte du kommer göra - enda vettiga sättet att få till bättre kylning är bättre ventilation av skåpet. Antar att du har luftintag i botten på skåpet och fläktar i toppen? Du behöver nog även leda ut överskottsvärmen till ett annat rum som du inte tar inkommande luft ifrån.kofa skrev:
HP iLO har jag själv aldrig haft problem med vad det gäller temperaturvärdena, dem har alltid fungerat bra. Däremot så mäter dem ju temp på utsatta ställen i chassit, inte i skåpet.
Om jag körJohan Gunverth skrev:
ssh -i /data/ssh/replication 192.168.0.3
så landar jag på min backupserver utan att ange lösenord. Tyder inte det på att nycklarna fungerar?
Under .ssh/ finns en fil som heter "authorized keys" och i den filen finns en nyckel. Menar du att jag ska radera innehållet i filen och lämna filen kvar?
Jag tycker mig ha läst att nyckeln som används för replikering ligger i "replication" ovan, och inte i .ssh/.
known_hosts ligger på datorn man kör på, och används för att säkert identifiera servern man vill logga in på. Man får en fråga första gången och svarar man "ja" så får man i fortsättningen ingen fråga så länge det är samma server. Försöker någon leda om trafiken till en annan server så får man frågan igen.
authorized_keys ligger på servern och används för att säkert identifiera personen/datorn som vill logga in. Informationen måste läggas in på servern i förväg, hos den användare man försöker logga in som.
authorized_keys ligger på servern och används för att säkert identifiera personen/datorn som vill logga in. Informationen måste läggas in på servern i förväg, hos den användare man försöker logga in som.
Redigerat:
Men detta gäller för ssh generelt.
För replikeringen av snaps uppfattar jag att man använder en annan nyckel, enligt sökvägen i mitt inlägg. Den nyckeln som ligger i filen replication verkar stämma med den jag ser i GUIt också. Så egentligen förstår jag fortfarande inte varför ssh inte funkar vid replikering av snaps - det funkar ju när jag kör manuellt enligt ovan.
För replikeringen av snaps uppfattar jag att man använder en annan nyckel, enligt sökvägen i mitt inlägg. Den nyckeln som ligger i filen replication verkar stämma med den jag ser i GUIt också. Så egentligen förstår jag fortfarande inte varför ssh inte funkar vid replikering av snaps - det funkar ju när jag kör manuellt enligt ovan.
Det är det som står sist i något entry i authorized_keys som ska matcha det som står sist i .pub-filen. För att hitta den authorized_keys som kommer användas på servern måste man veta som vilken användare inloggningen kommer göras (det kan vara något annat än det som står i .pub-filen).
Kolla vad som står sist i /data/ssh/replication.pub
Det kan hända att replikeringen försöker logga in som en annan användare än den som står där.
Exempel: det kan t.ex i replication.pub stå "apa@mindator"
Loggar man in med den filen utan att ange någon annan användare måste det på servern finnas ett matchande entry i ~/apa/.ssh/authorized_keys
Det kan dock hända att replikeringen försöker logga in som en annan användare, vilket motsvaras av att du t.ex skriver
ssh -i /data/ssh/replication bepa@192.168.0.3
Då är det i ~bepa/.ssh/authorized_keys på servern som det måste finnas ett entry som matchar "apa@mindator"
Kolla vad som står sist i /data/ssh/replication.pub
Det kan hända att replikeringen försöker logga in som en annan användare än den som står där.
Exempel: det kan t.ex i replication.pub stå "apa@mindator"
Loggar man in med den filen utan att ange någon annan användare måste det på servern finnas ett matchande entry i ~/apa/.ssh/authorized_keys
Det kan dock hända att replikeringen försöker logga in som en annan användare, vilket motsvaras av att du t.ex skriver
ssh -i /data/ssh/replication bepa@192.168.0.3
Då är det i ~bepa/.ssh/authorized_keys på servern som det måste finnas ett entry som matchar "apa@mindator"
Diversearbetare
· Göteborg
· 9 665 inlägg
När du satte upp rsync via ssh skapades ett nyckelpar som kopierades via scp till målvärden via inloggad ssh. Detta används istället för användarnamn och lösenord. Tanken är att du kan vara "root" i båda ändar för att t.ex. behålla rättigheter från källan. Nycklarna ligger i authorized_keys. Du borde kunna sätta upp allt igen Och då används det nya nyckelparet istället.
För att det ska funka utan en massa krångel ska man hålla sig till GUI:t och följa dokumentationen: https://doc.freenas.org/9.10/storage.html#replication-tasksMathiasS skrev:
För enkelhetens skull hade jag kört som root också, i en isolerad hemmiljö gör det varken från eller till.
Säkerställ också att båda FreeNAS:arna kör samma version.
Kort summerat ser jag följande scenario:
1. På Source-nas:et gå in under Storage -> Repl tasks -> View public key och kopiera ut nyckeln.
2. På Target-nas:et gå in under Account -> Users -> root -> modify -> SSH public key och kopiera in nyckeln från ovan, lägg sist i listan ifall det finns entries redan.
3. Säkerställ att target har en volym som tar emot snap:arna.
4. Lägg upp en repl task:
Volume/Dataset = Source-snapen
Remote ZFS vol/ds = Target-volymen
Remote hostname = Target
Remote hostkey = tryck SSH key scan så fylls den i
Övriga options efter behov
Kan det funka tro?