Accessa en annan dator på nätverket (Hemma)

Permalänk
Medlem

Accessa en annan dator på nätverket (Hemma)

Jag har två Linuxdatorer hemma. En Fedora 21 och en Mint 17.1. Fedora är lite svajig och hänger sig lite nu och då, från jobbet via Teamviewer kan jag inte göra så mycket, då systemet inte reagerar på mina tangent eller musmanövrar. Kan inte starta om datorn eller någonting. Dock kommer jag in på min Mint-dator utan problem. Jag önskar nu fjärra Fedora-datorn från Mint-datorn (från jobbet via TeamViewer) för att starta om (och logga in med x då Teamviewer-sessionen startar med desktopen)
Har läst om SSH, men har inte en susning om hur det funkar. Jag vet inte ens vilken 192-adress min Fedora-burk har.
Hur går jag smidigast till väga? Alternativt hur jagsätter upp så det funkar som jag vill när jag väl är hemma i eftermiddag och kan göra en hard reset.

Permalänk
Medlem

Jag hade gjort ett ARP uppslag, öppna terminalen och skriv bara arp, du kanske behöver använda sudo.
Där kommer nätverkets adresser upp (det gör det för mig iallafall).
Så skriver du ssh username@192.168.xxx.xxx och enter, så borde den prompta om lösenord, sedan skriver du bara reboot.

Detta är avsatt att du har SSH aktiverat på fedora burken (jag tror den har det automatiskt aktiverat).

Testa det.

Permalänk
Medlem
Skrivet av xamber:

Jag hade gjort ett ARP uppslag, öppna terminalen och skriv bara arp, du kanske behöver använda sudo.
Där kommer nätverkets adresser upp (det gör det för mig iallafall).
Så skriver du ssh username@192.168.xxx.xxx och enter, så borde den prompta om lösenord, sedan skriver du bara reboot.

Detta är avsatt att du har SSH aktiverat på fedora burken (jag tror den har det automatiskt aktiverat).

Testa det.

Tax för tips. sudo arp visar bara Nasen och routern (default gateway) inte Fedoraburken, detta trots den är "online" jag kan koppla på mig med teamviewer och se min loginruta men inte klicka runt och/eller starta om.

Permalänk
Medlem

logga in på routern och kolla vad fedoraburken har för dhcp lease ?

Permalänk
Medlem
Skrivet av xamber:

logga in på routern och kolla vad fedoraburken har för dhcp lease ?

Hehe, nu hade den tappat nätkoppling helt. Nåväl, fixa hemma saden. tack för tipsen

Permalänk
Medlem
Skrivet av xamber:

logga in på routern och kolla vad fedoraburken har för dhcp lease ?

Kollade både arp (som bara hittar tidigare accessade enheter tror jag) och installerade nmap. Scannade nätet med

sudo nmap -sP 192.168.1.0/24

men fick inga träffar. Lång tid tog det också.

Starting Nmap 6.40 ( http://nmap.org ) at 2015-03-27 18:08 CET Nmap done: 256 IP addresses (0 hosts up) scanned in 220.61 seconds

Vad måste jag ställa in på klienterna?

Permalänk
Medlem

Säker på att det du inte har 192.168.0.1 ?
Kolla med

sudo ifconfig

Permalänk
Medlem
Skrivet av theailer:

Säker på att det du inte har 192.168.0.1 ?
Kolla med

sudo ifconfig

haha. jag har varit trött denna veckan. Tack!

Permalänk
Medlem

Funkade! Skall bara enabla porten i routern för fjärraccess. Hur ser jag vilken port SSH-tjänsterna använder? Tror 22 är blockerat hos ISP, men är inte säker

Permalänk
Medlem

Du kan göra om till vilken port du vill som vanligen inte används, så är du säker från attacker utifrån också, t.ex. port 2222 eller 4444.

Permalänk
Medlem
Skrivet av Dockland:

haha. jag har varit trött denna veckan. Tack!

Haha gött att jag kunde vara till hjälp iaf
SSH porten är som sagt 22, men du kan ju konfigurera routern/modemet att lyssna på tex port 34340 externt och sedan 22 internt mot lanet.

Permalänk
Medlem
Skrivet av theailer:

Haha gött att jag kunde vara till hjälp iaf
SSH porten är som sagt 22, men du kan ju konfigurera routern/modemet att lyssna på tex port 34340 externt och sedan 22 internt mot lanet.

Tackar. Jag har inte satt mig in i port forwarding och annat på Com Hem-routern ännu. Skall botanisera under dagen.

Permalänk
Hedersmedlem

Gällande portnummer så ska man vara medveten om vad som händer vid övergången mellan portnummer 1023 och 1024. Endast `root` kan binda tjänster till portar med nummer ≤ 1023, och det kan ha säkerhetsimplikationer att ta en tjänst som vanligen binds till en sådan privilegierad port och lägga den i det "allmänna" blocket. Jag minns att jag skrev om detta i ett tidigare inlägg här på forumet:

Skrivet av phz:

Det är högst troligen `root` (eller motsvarande) som administrerar systemets brandvägg, men vad det handlar om här är att enbart `root` får starta tjänster som binder till ett portnummer lägre än 1024 på en viss enhet. Om en vanlig användare vill starta en tjänst så får den snällt välja en port att lyssna på i intervallet 1024–65535 (vid normal konfiguration); huruvida systemets brandvägg släpper igenom anrop till dessa portar överhuvudtaget är en annan fråga.

Skulle man som `root` köra SSH-servern på exempelvis port 2222 så skulle "potentiellt" en elak "vanlig" användare i systemet kunna utnyttja någon bugg, överbelastningsattack eller något annat som gör att SSH-servern dör, och därefter starta sin egen fejk-SSH-server som exempelvis loggar anslutande användares lösenord på samma port.

Även om det handlar om ett enanvändarsystem så skulle en sådan lucka potentiellt kunna nyttjas av en attackerare för att fiska lösenord över rättighetsgränser, ifall de på något sätt kan få kontroll över en av de många servicekonton som vanligen existerar på en dator. I det aktuella fallet när det handlar om att sätta portvidarebefordring på en extern router så ska det extremt mycket till för att detta skulle vara speciellt relevant, men det är en generell kunskap som det inte skadar att ha i bakhuvudet (liksom kunskap sällan gör).

Permalänk
Medlem
Skrivet av phz:

Gällande portnummer så ska man vara medveten om vad som händer vid övergången mellan portnummer 1023 och 1024. Endast `root` kan binda tjänster till portar med nummer ≤ 1023, och det kan ha säkerhetsimplikationer att ta en tjänst som vanligen binds till en sådan privilegierad port och lägga den i det "allmänna" blocket. Jag minns att jag skrev om detta i ett tidigare inlägg här på forumet:

Även om det handlar om ett enanvändarsystem så skulle en sådan lucka potentiellt kunna nyttjas av en attackerare för att fiska lösenord över rättighetsgränser, ifall de på något sätt kan få kontroll över en av de många servicekonton som vanligen existerar på en dator. I det aktuella fallet när det handlar om att sätta portvidarebefordring på en extern router så ska det extremt mycket till för att detta skulle vara speciellt relevant, men det är en generell kunskap som det inte skadar att ha i bakhuvudet (liksom kunskap sällan gör).

Tack för tipsen.

Permalänk
Medlem
Skrivet av theailer:

Haha gött att jag kunde vara till hjälp iaf
SSH porten är som sagt 22, men du kan ju konfigurera routern/modemet att lyssna på tex port 34340 externt och sedan 22 internt mot lanet.

Installerade Mint 17.1 på NUC och plötsligt funkar inget längre. Har avinstallerat SSH klient och server utan framgång. Ändrat port till 44444 i configfilen/etc/ssh/sshd_config och i /etc/ssh/ssh_config, startat om ssh tjänsterna, tillåtitit ufw allow ssh men får fortfarande fel. Får felmeddelande när jag testar mot localhost "ssh: connect to host localhost port 22: Connection refused"

Den snackar fortfarande på port 22 tydligen. Ändrar jag manuellt till port 44444 med switchen -p 44444 fungerar det fint mot local host men inte mot klientdatorn 192.168.0.33 (som jag också gjort alla dessa inställningar på)

Permalänk
Hedersmedlem
Skrivet av Dockland:

Installerade Mint 17.1 på NUC och plötsligt funkar inget längre. Har avinstallerat SSH klient och server utan framgång. Ändrat port till 44444 i configfilen/etc/ssh/sshd_config och i /etc/ssh/ssh_config, startat om ssh tjänsterna, tillåtitit ufw allow ssh men får fortfarande fel. Får felmeddelande när jag testar mot localhost "ssh: connect to host localhost port 22: Connection refused"

Den snackar fortfarande på port 22 tydligen. Ändrar jag manuellt till port 44444 med switchen -p 44444 fungerar det fint mot local host men inte mot klientdatorn 192.168.0.33 (som jag också gjort alla dessa inställningar på)

Det är `sshd` som är servern, dvs den process som lyssnar på anslutningar. `ssh` är klienten, dvs den process med vilken du ansluter till SSH-servrar.

Om du ändrar till port 44444 i `/etc/ssh/sshd_config` så har du ändrat den port mot vilken du behöver ansluta med en SSH-klient för att kunna kommunicera med servern.

Om du inte anger någon speciell port när du ansluter till en server med SSH-klienten så antar den som standard port 22 (precis som din webbläsare antar port 80 för HTTP och port 443 för HTTPS om du inte anger något annat). När du ändrade i `/etc/ssh/ssh_config` (notera skillnaden mot `/etc/ssh/sshd_config`) så ändrade du troligen i `Host *`-blocket, dvs du ändrade standardporten som SSH-klienten använder vid anslutning om inget annat anges för alla anslutningar till att vara 44444. Det vill du inte göra. Ändra tillbaka till 22, eller än enklare: kommentera bort raden, då 22 är standard om man inte anger något annat.

Vill du ansluta till port 44444 till en enstaka värd så får du antingen ange detta genom (se `man ssh`):

ssh -p 44444 192.168.0.1

eller enklare definiera en värd i `~/.ssh/config` (se `man ssh_config`) som exempelvis

Host frysbox HostName 192.168.0.1 Port 44444

och sedan ansluta med `ssh frysbox` (mer eller mindre alla SSH-medvetna verktyg fungerar sömlöst med dessa alias).

Om du kan ansluta lokalt på port 44444 så betyder det att din SSH-server definitivt lyssnar där. Om du inte samtidigt kan ansluta från en extern dator till port 44444 på denna värd så har du antingen någon brandväggsregel eller NAT i vägen.

Permalänk
Medlem
Skrivet av phz:

Det är `sshd` som är servern, dvs den process som lyssnar på anslutningar. `ssh` är klienten, dvs den process med vilken du ansluter till SSH-servrar.

Om du ändrar till port 44444 i `/etc/ssh/sshd_config` så har du ändrat den port mot vilken du behöver ansluta med en SSH-klient för att kunna kommunicera med servern.

Om du inte anger någon speciell port när du ansluter till en server med SSH-klienten så antar den som standard port 22 (precis som din webbläsare antar port 80 för HTTP och port 443 för HTTPS om du inte anger något annat). När du ändrade i `/etc/ssh/ssh_config` (notera skillnaden mot `/etc/ssh/sshd_config`) så ändrade du troligen i `Host *`-blocket, dvs du ändrade standardporten som SSH-klienten använder vid anslutning om inget annat anges för alla anslutningar till att vara 44444. Det vill du inte göra. Ändra tillbaka till 22, eller än enklare: kommentera bort raden, då 22 är standard om man inte anger något annat.

Vill du ansluta till port 44444 till en enstaka värd så får du antingen ange detta genom (se `man ssh`):

ssh -p 44444 192.168.0.1

eller enklare definiera en värd i `~/.ssh/config` (se `man ssh_config`) som exempelvis

Host frysbox HostName 192.168.0.1 Port 44444

och sedan ansluta med `ssh frysbox` (mer eller mindre alla SSH-medvetna verktyg fungerar sömlöst med dessa alias).

Om du kan ansluta lokalt på port 44444 så betyder det att din SSH-server definitivt lyssnar där. Om du inte samtidigt kan ansluta från en extern dator till port 44444 på denna värd så har du antingen någon brandväggsregel eller NAT i vägen.

Tack, skall testa imorgon söndag.

Permalänk
Medlem

Jag hittade felet. Jag hade uppgraderat kärnan på ssh-serverdatorn till senaste. Installerade Debian 8 RC2 och allt funkade direkt. Tack för svaren.

Skickades från m.sweclockers.com