[Løst] Hjemmeserver med kryptert backup til naboen...

[anders iver]

Bare for å være sikker.. Routerne deres er satt opp med korrekt forwarding av porter?

[Del]

Sjekk porter, at de er satt opp riktig. Det gjør du slik:

-fra server går du inn på canyouseeme.org og sjekker at porten du forwarder til 22 er åpen, noter deg den eksterne ip-adressen som rapporteres

-sjekk at ip-adressen er den som domenet peker til med:

ping nabo.yourhda.com

Hvis begge er Ok, så skal det holder med:

ssh -p xxx [email protected]

[Gjest Slettet-Pqy3rC]

Jeg gjør dette med en nabo (et par km unna) på en litt annen måte ved hjelp av Nanostation.

 

Vi har begge koblingen som et eget interface på hver vår Atom baserte pfSense boks. Fordelen er dermed at vi i tillegg til site-backup får backup WAN (internet oppkobling).

[HawP]

Inne i sshd_config har jeg fjernet kommenteringen på disse linjene:

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

 

Får fremdeles samme feilmld.

 

Må det samme evt gjøres i ssh_config ift RSA?

Må en der også ta bort kommentartegnet på denne linjen #Port 22, eller vil kommandoen med -p xxx overstyre portnummer den bruker hos naboen?

"Connection refused" og "connection reset by peer" høres ut som at den forsøker å kople til en port som det ikke er noen sshd som lytter på, evt. at porten er stengt.

 

Hvis jeg forstår riktig så bruker dere Fedora... den aktiverer ikke en brannmur by default ved installasjon? I såfall må antakelig porten sshd konfigureres med åpnes der også.

 

ssh -p forteller ssh klienten (deg) hvilken port den skal forsøke å kople til i "andre enden" (naboen).

 

"Port" i sshd_config (hos naboen) styrer hvilken port ssh daemon på hans maskin vil lytte på. Default er port 22 (på alle ip'er maskinen har), derfor står denne kommentert ut by default i sshd_config. Har du/dere ikke fjernet # og endret portnr. (hvis det er planen) så lytter den på port 22.

 

Når du så bruker ssh -p xxx (fra din maskin) så må xxx være samme som sshd_config hos naboen er konfigurert med, ellers får du nok ikke noen forbindelse.

[Crowly]

Mener at brannmuren er aktivert som standard i Fedora, det samme er SELinux. Fant en post om Fedora 11 som sa at iptables ikke blokkerer ssh som standard, SELinux skal heller ikke være ett problem i følge samme innlegg, men i følge http://robbyx.net/blog/?p=353 så kan det se ut som ting er endret på når det kommer til SELinux:

 

How to enable SSH port forwarding in Fedora with SELinux

If this is something that’s been bugging you and you just disabled SELinux altogether to get it working, well there’s another way

setsebool sshd_forward_ports=on

må nok kjøres som root med ett av følgende alternativer

sudo setsebool sshd_forward_ports=on

su -c "setsebool sshd_forward_ports=on"

su -
<root passord>
setsebool sshd_forward_ports=on

eller bruk gui verktøyet

 

Men SELinux pleier å gi advarsler/feilmeldinger når ting blir blokkert, og stort sett så står det også hva som må gjøres for å rette opp eller gi tilgang.

Endret 2. januar 2012 av Crowly

[Del]

Gutter, nå må dere ikke forvirre. Han koblet til lokalt, da er det ingen brannmur som sperrer i Fedora.

 

Har du fått sjekket forwarding med canyouseeme.org labbetus?

[Labbtus]

Jepp, fikk det til å fungere nå, den ene veien...

Jobber nå med å sette opp ruteren hos naben. Viste seg å være en feil i port forwardingen

 

Kommer tilbake med status når alt fungerer.

 

Nyttig med canyouseeme.org

[Gjest]

Quota er vel også noe dere kan vurdere, altså fordele disksplassen til begge to nøyaktig.

[Labbtus]

Liten status i kveld :-)

 

ssh oppe å går mellom begge maskinene :-)

Skal teste resten av oppskriften din Del i løpet av de neste dagene.

 

Kommer med en endelig status når dette er oppe å går.

 

Eneste utfording jeg ser p.t. er at selv om PermitRootLogin i sshd_config er satt til no; kan vi fremdeles logge inn som su fra brukeren eksternt. Skal dette være mulig? Kan en hindre dette på en annen måte?

[Lycantrophe]

Du kan bli root gjennom su etter å ha sshet med en annen bruker, ja, det er bare direkte innlogging som ikke går. Hva er hensikten med å nekte root-su i sin helhet?

[Del]

Det som da ikke skal være mulig er å logge inn som root, altså slik:

ssh -p xxx [email protected]

Å kjøre sudo etter å ha logget inn som vanlig bruker er likevel mulig, men det er ingen grunn til at dere skal ha sudo rettigheter på hverandres maskiner.

 

Merk at for at endringer på tjenester skal tre i kraft må man enten re-boote maskinen, eller fortelle tjenesten at den skal laste inn konfiguraskon på nytt. For ssh på Fedora blir det slik:

sudo /etc/init.d/sshd reload

[HawP]

Eneste utfording jeg ser p.t. er at selv om PermitRootLogin i sshd_config er satt til no; kan vi fremdeles logge inn som su fra brukeren eksternt. Skal dette være mulig? Kan en hindre dette på en annen måte?

Gruppa wheel i /etc/group gir normalt/ofte rettigheter til å kjøre 'su', så hvis deres bruker på hverandres maskiner er medlem i wheel gruppa, så forsøk å fjerne brukerne fra den. Altså du fjerner naboens bruker fra wheel gruppa på din maskin og motsatt.

sudo usermod -R wheel <brukernavn>

 

En annen ting er jo at dere vet hverandres root passord...

[Sokkalf™]

Noen grunn til at du har gått for Fedora 14?

 

As of 09 December 2011, Fedora 14 has reached its end of life for

updates and support. No further updates, including security updates,

will be available for Fedora 14.

[PacAnimal]

Sjekk ut encfs reverse mode. Da kan du montere en konsekvent, kryptert versjon av et filsystem som er ukryptert på disk. Dette er nyttig for å kunne rsync'e krypterte filer til en remote maskin uten at den maskinen må ha nøkkelen. Fordi krypteringen er konsekvent vil rsync fungere som normalt på den krypterte monteringen av filene.

 

Ved bruk av dette ligger all min backup offentlig tilgjengelig.

[Del]

Noen grunn til at du har gått for Fedora 14?

 

As of 09 December 2011, Fedora 14 has reached its end of life for

updates and support. No further updates, including security updates,

will be available for Fedora 14.

Amahi-støtte vil jeg tro.

[Crowly]

fortelle tjenesten at den skal laste inn konfiguraskon på nytt. For ssh på Fedora blir det slik:

 

Alternativt bruk service

sudo service sshd restart

Personlig syntes jeg service er enklere å huske på enn /etc/init.d, men har nok med vane å gjøre. Har sett at det er ikke alle distribusjoner som har tatt i bruk service, eller har det på alt, sånn sett er nok /etc/init.d mer universal. Fedora har hatt støtte for/tatt i bruk service i en god stund (i alle fall siden jeg begynte å ta det i bruk FC5).

[PacAnimal]

det er ikke alle distribusjoner som har tatt i bruk service, eller har det på alt, sånn sett er nok /etc/init.d mer universal.

function service {

local name=$1

shift

/etc/init.d/${name} "$@"

}

 

ftfy

[Labbtus]

Liten oppdatering fra prosjektet. :-)

 

Ift su; jeg har hatt naboens su-passord ifm oppsett av systemet. Men, det er endret nå, slik at det er ikke et problem lengre :-)

 

Når det gjelder valget av Fedora 14 er det som Del indikerte; Amahi fungerer kunne med dette.. Får vurdere å oppgradere når Amahi kommer for Fedora 16.

 

Etter det store gjennombruddet her om dagen (ssh fungerte) har vi støtt på noen små utfordringer. Dette gjelder spesielt hos naboen :-)

Det har seg slik at han er i-fan, og har bare Mac-produkter i dataparken. Dog mange av sorten... Hovedutfordringen har være plasseringen av bildefiler/bibliotek på NAS. Det er en del linker på hvordan vi får Amahi til å støtte AFP (Apple File Protocol) (link), vi gjorde en jobb på dette i går, og han testinger nå hvordan dette fungerer. Han benytter Aperture for bildebehandling, så her blir det litt mer testing ift Masterfiler osv. Alle innspill ift mottas med takk, men er strengt tatt et annet problem ift denne tråden.

 

Men denne problemstilligen har gjort at vi ikke har fått kryptert hans backup disk enda, og da heller ikke byttet disker.

 

Men, jeg har testet litt med noen små mapper på min NAS, og overført disse direkte til min hjemmemappe på hans NAS.

 

Har da benyttet følgende kommandoer:

sshfs -p xxx -o nonempty -o idmap=user [email protected]:backup /backup/files

Måtte legge til -o nonempty for å slippe feilmelding ved montering mot mappe med innhold. Fant også at jeg måtte legge inn idmap=user (ikke endret syntaks), ellers fikk jeg problemer med rettighetene til montert mappe. Uten dette ble rettighetene til mappen gitt til andre brukere på maskinen, og jeg fikk ikke synkronisert innholdet. Der at gruppen på montert mappen enda blir feil, men jeg får synkronisert innholdet...

 

encfs -o nonempty /backup/files/ /var/hda/backup/

Ingen, -o nonempty pga montering av mapper med innhold.

 

rsync -av --delete /var/hda/files/ /var/hda/backup/

Fant at jeg måtte legge til --delete for at innhold skulle slettes i backup når det ble slettet i orginalmappe på min server.

 

fusermount -u /var/hda/backup/

Til slutt demontere... (har jeg da dekket den demonteringen jeg trenger? Husk: Newbee)

 

Noen som har forslag til forbedringer, eller som ser noe som burde vært korrigert?

 

Nå ser det ut som neste punkt på agendaen min blir koding av cron. I følge Wiki (link) må min bruker være listet i /etc/cron.allow.

 

Jeg har ikke denne filen i mitt system; og skal innrømme at jeg ikke har kommet så langt som å google etter hvordan denne skal se ut. Hvis noen har input hadde det vært glimrende, hvis ikke blir det litt googling :-)

 

Jeg har funnet at dersom jeg vil at synkroniseringenskal kjøres hver natt kl 03:00 så (tror jeg) crontab filen ha disse parametrene:

0 3 * * * /backup/backup-fileinstruction

 

Så tror jeg backup-fileinstruction filen vil se noe slikt ut:

sshfs -p xxx -o nonempty -o idmap=user [email protected]:backup /backup/files

encfs -o nonempty /backup/files/ /var/hda/backup/

rsync -av --delete /var/hda/files/ /var/hda/backup/

fusermount -u /var/hda/backup/

 

Jeg fant denne linken (link), ser ut til at han har vært gjennom ca samme prosess, men uten kryptering :-)

Er det slik at kommandoene i denne filen blir kjørt fortløpende, og at maskinen skjønner at forrige kommando må være avsluttet før neste kan kjøres? Tenker det er spesielt viktig dersom fusermount skal ligge som en linje her.

 

Videre hadde jeg håpt å kunne sende eventulle feilmeldinger fra synkroniseringen på en mail til meg selv. Jeg har Loqal som bredbåndsleverandør, og er litt usikker på om de støtter sending av epost direkte fra script. Er det noen som har forslag til hvordan dette løses i scriptet?

[Del]

Etter det store gjennombruddet her om dagen (ssh fungerte) har vi støtt på noen små utfordringer. Dette gjelder spesielt hos naboen :-)

Det har seg slik at han er i-fan, og har bare Mac-produkter i dataparken. Dog mange av sorten... Hovedutfordringen har være plasseringen av bildefiler/bibliotek på NAS. Det er en del linker på hvordan vi får Amahi til å støtte AFP (Apple File Protocol) (link), vi gjorde en jobb på dette i går, og han testinger nå hvordan dette fungerer. Han benytter Aperture for bildebehandling, så her blir det litt mer testing ift Masterfiler osv. Alle innspill ift mottas med takk, men er strengt tatt et annet problem ift denne tråden.

Her skjønner jeg ikke hva du mener. Mac kan bruke delte mapper akkurat som windows, burde være tilstrekkelig å dele de ut.

Har da benyttet følgende kommandoer:

sshfs -p xxx -o nonempty -o idmap=user [email protected]:backup /backup/files

Hvorfor er ikke mappen /backup/files tom før du monterer? Når det gjelder idmap, har du samme brukernavn i begge ender? Isåfall bør det holde med:

sshfs -p nabo.yourhda.com:backup /backup/files

Forresten, fikk du til nøkler for ssh slik at du slipper å skrive inn passord?

encfs -o nonempty /backup/files/ /var/hda/backup/

Ingen, -o nonempty pga montering av mapper med innhold.

Igjen, hvorfor er mappen /var/hda/backup ikke tom før montering? Tøm den før montering. Du trenger ikke slash til slutt, men du trenger å sende med passord når du skal legge det inn i cron. Legg passordet i en fil som kun du har leserett til. Så kan du prøve med:

cat /sti/til/filmedpassord | encfs -S /backup/files /var/hda/backup

Til slutt demontere... (har jeg da dekket den demonteringen jeg trenger? Husk: Newbee)

Jepp, perfekt. Jeg tror ikke du kan kalle deg noob lenger

Nå ser det ut som neste punkt på agendaen min blir koding av cron. I følge Wiki (link) må min bruker være listet i /etc/cron.allow.

Hukser jeg rett er det bare å opprette filen og legge inn brukernavnet ditt i den.

Jeg har funnet at dersom jeg vil at synkroniseringenskal kjøres hver natt kl 03:00 så (tror jeg) crontab filen ha disse parametrene:

0 3 * * * /backup/backup-fileinstruction

 

Så tror jeg backup-fileinstruction filen vil se noe slikt ut:

sshfs -p xxx -o nonempty -o idmap=user [email protected]:backup /backup/files

encfs -o nonempty /backup/files/ /var/hda/backup/

rsync -av --delete /var/hda/files/ /var/hda/backup/

fusermount -u /var/hda/backup/

 

Jeg fant denne linken (link), ser ut til at han har vært gjennom ca samme prosess, men uten kryptering :-)

Er det slik at kommandoene i denne filen blir kjørt fortløpende, og at maskinen skjønner at forrige kommando må være avsluttet før neste kan kjøres?

Jepp.

Videre hadde jeg håpt å kunne sende eventulle feilmeldinger fra synkroniseringen på en mail til meg selv. Jeg har Loqal som bredbåndsleverandør, og er litt usikker på om de støtter sending av epost direkte fra script. Er det noen som har forslag til hvordan dette løses i scriptet?

Du kan bruke mail-kommadoen. Kanskje noen andre har forslag til hvordan du kan logge feilmeldinger?

[Lycantrophe]

Cron kan sende mail ved feil for deg. Skal sove nå, men om du starter før jeg får postet mer; kikk i man-page.