Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Ohjelmointi, palvelimet ja muu edistyneempi käyttö => Aiheen aloitti: Jagster - 19.07.20 - klo:13.16
-
Tämä on (taas) luokkaa aloittelija esittämässä wannabe-edistyneen käytön kysymystä...
Eli lähtötilanne on, että nettiboksi/routerin takana on kaksi windows 10 home konetta, joissa kummassakin tulee olemaan Ubuntun appi (nyt vain toisessa, omassani). Routerin WAN:iin on avattu portti 22 ja LAN suuntaan 2222, jota kuuntelee oman läppärini Ubuntu-appin SSH-server.
Tarve on saada SSH toimimaan molemmissa ja tietysti niin, että ssh yksi@192.168.100.1 menee IP:n mukaiseen koneeseen ja ssh kaksi@192.168.100.2 toiseen. Molemmat eivät tietenkään voi olla servereitä, ellen sitten avaa molemmille omat porttinsa, joka lienee täysin aivokuollut ajatus? Joten johonkin konfiin täytyy kertoa miten ohjaus menee, ymmärtääkseni. Vai ollaanko minulle mystisessä aiheessa routerin porttien ohjaus?
Koska tarvitaan joku serveri, niin voiko se olla jompikumpi win-koneiden ubuntu vai ostanko Raspberryn?
Josta tietysti seuraa se, että maailmalle kummmallakin yhteydellä on sama julkinen IP. Miten DDNS tajuaa kumpi on kampi?
Saa ohjata tiedon pariin netissä. Omat tiedot aiheesta eivät riitä hakutulosten rajaamiseen.
-
Sisäverkossa molemmissa koneissa voi olla SSH-palvelin samassa portissa. Itse käyttäisin porttia 22, ellei ole jotain erityistä syytä vaihtaa porttia.
Reitittimessä voit sitten ohjata vaikka wan-puolen portin 22001 koneen 192.168.100.1 SSH-porttiin ja wan-portin 22002 koneen 192.168.100.2 SSH-porttiin.
Tällöin saat siis netistä julkisen IP-osoitteen portista 22001 yhteyden kotiverkkosi koneen 192.168.100.1 SSH-palveluun, ja vastaavasti portista 22002 toiselle koneelle.
DDNS ei vaikuta porttiohjauksiin mitenkään.
-
Jos ssh:ta mietitään, niin silloin komento on mallia ssh tunnus@julkinen-ip:portti ja aina jokaisella koneella täytyy olla WAN:ssa oma portti auki. EIhän tuo kovinkaan näppärältä tunnu.
Joten, jos laitankin läppärin (johon ei muistikortilla Ubuntu asennu) SSH-serverinä kuuntelemaan routerin LAN:n porttia vaikka 2222 (tai 22 selvyyden vuoksi), niin saanko sen jollain kikka kolmosella siirtämään yhteyden haluttuun sisäverkon IP:hen esim. tunnuksen perusteella? Tosin, mitä jos molemmissa on sama tunnus käytössä ja kun ssh tunnus@julkinen-ip tulee routerin WAN-porttiin 22, niin ei kai ne molemmat voi huutaa, että mulle tämä käyttäjä?
Kyllä, olen aivan untamo verkko/serveri-hommissa edelleenkin, mutta voisin kuvitella, että moinen olisi serverin peruskauraa.
-
Useampi sata välilehteä selaimessa auki tällä hetkellä Ja koska on kuuma ja kahvi on loppu, niin alkaa tuskatuttamaan ja väitän, että yleisesti esitetty asenna-linux-niin-saat -helpolla-näppärän-kotiverkon ei ihan niinku sillai pidä paikkaansa ;)
99 % netin ohjeista aiheessa SSH, serveri ja sisäverkko kertovat, että tarvittava komento on apt install openssh-server ja sitten conclusions on, että nyt sinulla on toimiva ssh.
Njooh. Se angstista.
Lähdenkö seuraamaan mitä löytyy sshd_config tiedoston asetukselle AllowTcpForwarding yes vai liittykö se edes mitenkään aiheeseen?
-
Mitä enemmän googletan, niin sitä enemmän tulee (taas) sellainen olo, että yritän pakottaa ruuvumeisseliä vasaraksi tekemään jakoavaimen hommia. Olisi ehkä kohteliaampaa editoida aloitusta, mutta kokemuksesta tiedän, että se sotkee vielä enemmän - eli koska en enää itsekään ymmärtänyt mitä olin selittänyt, niin ratkaistava asia on tämä:
Käyttäjä1 haluaa päästä maailmalta komennolla ssh käyttäjä1@ddns.url sisäverkossa olevaan käyttäjä1 tietokoneen shelliin.
ja
Käyttäjä2 haluaa päästä maailmalta komennolla ssh käyttäjä2@ddns.url sisäverkossa olevaan käyttäjä2 tietokoneen shelliin.
ja
molemmat ovat saman julkisen IP:n takana, samassa sisäverkossa ja ddns.url on sama, mutta toki voi tehdä eri subdomainin
ja
erillisen WAN-portin käyttäminen ei ole vaihtoehto
-
Nyt on mielessä sen verran erikoinen setuppi, että en tiedä onko kukaan tehnyt tuollaista. Itse tekisin ennemmin tuon kahdella eri portilla ja säätäisin vaikka ssh-asiakkaan asetustiedostoon omat nimet niille, jottei tarvitse muistaa portteja tai käyttäjänimiä.
Vaihtoehtoisesti voisit paljastaa vain yhden palvelimen ulkoverkkoon ja yhdistää sieltä ssh:lla toiselle koneelle sisäverkossa. Tämä on myös hyvin yleinen tapa. OpenSSH:ssa on JumpProxy-asetus tuota varten. Huomaa, että silloin yhdistät sen ulkoverkkoon auki olevan koneen käyttäjänä ensin ja sitten yhdistät sieltä toiselle koneelle sen toisen koneen käytäjänä. Tämä on vähän kuin tuo mainitsemasi konfiguraatio joskin vaatii hieman enemmän säätöä asiakkaan puolelta.
Ehkä olisi myös mahdollista tehdä jokin viritys, jossa toisena käyttäjänä kirjautuminen tuolle ulkoverkkoon auki olevalle koneelle yhdistäisi automaattisesti ssh:lla toiselle koneelle, mutta en lähtisi virittelemään ellei kyseessä ole jokin hyvin erityinen tarve sellaiselle. Tämän voisi toteuttaa .bashrc-tiedostolla tai vaihtamalla käyttäjän shellin johonkin sopivaan skriptiin/ohjelmanpätkään.
Toinen alidomain ei tässä auta, koska ssh tai reititin ei sitä tiedä saati ymmärrä.
-
Mitä en tajua? Miten se voi olla erikoinen setup koska noinhan sisäverkot aina toimii? On serveri johon otetaan ulkoa yhteyttä ja sitten pääsee halutulle työasemalle, ns. siihen omaan koneeseen.
Juu, minä olen aina ollut loppukäyttäjä. Ja se taatusti näkyy.
Mutta olenko todellakin poikkeus maailmassa siksi, että minulla on kotiverkossa useampi kone ja haluan päästä niihin erikseen käsiksi yhteisen portin 22 kautta, en asentamalla erillistä WAN-porttia per laite?
-
Mitä en tajua? Miten se voi olla erikoinen setup koska noinhan sisäverkot aina toimii? On serveri johon otetaan ulkoa yhteyttä ja sitten pääsee halutulle työasemalle, ns. siihen omaan koneeseen.
Juu, minä olen aina ollut loppukäyttäjä. Ja se taatusti näkyy.
Mutta olenko todellakin poikkeus maailmassa siksi, että minulla on kotiverkossa useampi kone ja haluan päästä niihin erikseen käsiksi yhteisen portin 22 kautta, en asentamalla erillistä WAN-porttia per laite?
Ei tuossa ole mitään erikoista. Erikoinen oli tuo vaatimus siitä, että yhdistämällä yhteen koneeseen tiettynä käyttäjänä se menisikin toiselle koneelle. Ssh-yhteyksiä voi kyllä ketjuttaa kuten kerroin viestissäni vaihtoehtona tuolle eri porttien ohjaukselle, mutta silloin yhdistetään ensin sille ulkoverkkoon näkyvälle koneelle (koneelle, johon se portti on ohjattu) ja siltä sitten seuraavalle.
-
Melkoisen googlettelun jälkeen tosiaan näyttää siltä, että on aika mahdotonta saada SSH:ta ulkoa millään tapaa yhdestä portista sisäverkon erillisille koneille ilman, että avataan ikioma WAN-portti jokaiselle laitteelle erikseen. Joka on siis niin kaukana käytettävyydestä, ettei muusta väliä.
Ainoa löytämäni tapa on laittaa yksi kone ottamaan vastaan kaiken portin 22 liikenteen, jolloin jokainen kirjautuu ensin sinne. Sieltä sitten jatketaan sisäverkon IP-osoitteilla erillisellä ssh-komennolla omalle koneelle . Ehkä tuon jatkon saisi automatisoitu, en tiedä.
Palomuuri ja NAT ei auta, koska se ei tiedä kuka tulee
Joten laitanko otsikkoon RATKAISTU merkityksellä mahdoton ajatun?
Silti en kykene lakata ihmettelemästä, että miten muut, joilla on saman katon alla samassa wifissä useampi kone ja käyttäjä, pärjäävät? Vai oikeastiko tosiaan aukaisette maailmalla jokaiselle ikioman portin ja taotte päähän, että se on vaan pakko muistaa -p 221 tai mikä se milloinkin on?
-
Oli kramppaava sormi ja lähetti, vaikka esitettiinkin nöyrä pyyntö, että joku vastasi; luetaanko.
Oukkidoukki. Eli jatkan toteutusta ketjuttamisella. Jolloin seuraava kysymys on: millaisiin ongelmiin voin törmätä arjen käytössä, jahka systeemi pyörii? Riskejä?
-
Ainoa löytämäni tapa on laittaa yksi kone ottamaan vastaan kaiken portin 22 liikenteen, jolloin jokainen kirjautuu ensin sinne. Sieltä sitten jatketaan sisäverkon IP-osoitteilla erillisellä ssh-komennolla omalle koneelle . Ehkä tuon jatkon saisi automatisoitu, en tiedä.
Näin se yleensä toimii eli yhdelle koneelle pitää päästä yhdistämään ja sieltä voi sitten yhdistää eteenpäin uudella ssh-komennolla. Sen voi automatisoida ainakin OpenSSH:a (= se ssh-komento, jota Linuxissa yleensä käytetään) käytettäessä ProxyJump-asetuksella. Tässä on sekin hyvä puoli, että tarvitsee vain se yksi kone turvata erityisen hyvin. https://www.man7.org/linux/man-pages/man5/ssh_config.5.html
Silti en kykene lakata ihmettelemästä, että miten muut, joilla on saman katon alla samassa wifissä useampi kone ja käyttäjä, pärjäävät? Vai oikeastiko tosiaan aukaisette maailmalla jokaiselle ikioman portin ja taotte päähän, että se on vaan pakko muistaa -p 221 tai mikä se milloinkin on?
Tuo on yksi tapa toki, mutta ei sitä tarvitse varsinaisesti muistaa. Itselläni on noita eri palvelimia aika paljon ~/.ssh/config-tiedostossa.
Host omaserveri
HostName omadomain.example.com
Port 12345
User tomi
ja tuonne voin sitten yhdistää komentamalla "ssh omaserveri". Lisää noista: https://www.man7.org/linux/man-pages/man5/ssh_config.5.html (https://www.man7.org/linux/man-pages/man5/ssh_config.5.html).
-
Lopetin lukemisen ~/.ssh/config asettamisesta kun selvisi, että se täytyy tehdä siihen koneeseen, josta otetaan yhteyttä. Siinä vaiheessa roikuin ajatuksessa, että homma täytyy toimia samalla tavalla mistä tahansa koneesta. Jossain vaiheessa sitten totesin, että vaatimus on sinällään älytön, koska en ole milloinkaan vuosien saatossa ottanut vieraasta koneesta omaan laitteeseen minkäänlaista yhteyttä (edes Windowsien välillä) ;D
Joka tapauksessa, kokeilen nyt molempia mainstream-tapoja - jokaiselle oma WAN-portti tai yhden keskitetyn serverin kautta (serveritoteutuksessa oli jokin joka häiritsi, mutta kaipa se tulee kun pääsen sinne asti; VPN ja DDNS ehkä?)
Nyt olen jonkun tunnin tapellut nippelin kanssa... miten saan verkon laitteille host namen toimimaan? Se olisi mukavampaa kuin IP:n käyttö - joku sisäinen DNS, ei kai?
edit: vaihteeksi google kertoi heti - /etc/hosts tai DHCP+DNS
-
Silti en kykene lakata ihmettelemästä, että miten muut, joilla on saman katon alla samassa wifissä useampi kone ja käyttäjä, pärjäävät? Vai oikeastiko tosiaan aukaisette maailmalla jokaiselle ikioman portin ja taotte päähän, että se on vaan pakko muistaa -p 221 tai mikä se milloinkin on?
Tyypillisesti verkon reunalla kuuntelee vain yksi SSH-palvelin. Yhteydet muihin koneisiin hoituvat ProxyJump-ketjutuksella, kuten Tomi ehdotti, tai manuaalisesti ottamalla ensin yhteys siihen nettiin näkyvään koneeseen ja sitten sieltä ssh:lla eteenpäin. Sekin riittää ihan mukavasti, jos yhteyksiä ei tarvitse avata kymmentä kertaa päivässä.
Nyt olen jonkun tunnin tapellut nippelin kanssa... miten saan verkon laitteille host namen toimimaan? Se olisi mukavampaa kuin IP:n käyttö - joku sisäinen DNS, ei kai?
edit: vaihteeksi google kertoi heti - /etc/hosts tai DHCP+DNS
DNS-SD:tä (https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-SD_with_multicast) tukevat systeemit kuten Ubuntu löytävät toisensa lähiverkosta suoraan nimellä hostname.local (missä hostname on siis Ubuntun asennuksen yhteydessä koneelle annettu nimi ja määritelty tiedostossa /etc/hostname). WSL:ssä tuo ei ilmeisesti toimi, joten joudut käyttämään /etc/hosts-tiedostoa tai pystyttämään lähiverkkoon nimipalvelimen.
-
Meinasin alkaa kiukuttelemaan, että ei ainakaan viime yönä hostnamet toimineet tuossa uudessa serveri-asennuksessa - mutta olenkin hiljaa, koska en todellakaan ole enää ollenkaan varma missä olin tekemässä mitäkin, koska hypin niin paljon laitteilta toiselle. Mutta kun kyseessä on kolme käyttäjää, niin /etc/hosts lienee ehdottomasti helpoin tapa varmistaa hostnamet. Minulla ei ole suuriakaan estoja rakentaa, mutta DNS:n kanssa tuli sellainen olo, että tässä menee omien säätöjen opettelun raja - ei riittävää hyöty/vaiva-suhdetta ;)
Plus että en halua kuitenkaan ihan päättömästi panostaa tuon serverin rooliin nostetun läppärinraadon säätöön, koska edelleenkin heilun kahden välillä - kuunnellako sen hurinaa vai sijoittaa Raspiin ja alkaa taas opettelemaan uutta asiaa.
Pidän WSL:stä melkoisesti. Minun mielestäni se on yksi järkevimmistä ratkaisuista mitä kotitasolle on aikoihin tullut. Toki se on vielä rajoittunut, ja vastaan tulee muitakin ristiriidan tapaisia kuin vain .local nimen ymmärtämättömyys (joka on pieni vaiva koska aliakset on keksitty), mutta se on oikea liike kohti aitoa hybridijärjestelmää desktopeissa - tai olisi, jos Redmond saisi wintoosan toimimaan X:n tapaan. Mutta joo, nyt liukuu OT:hen.
Kohti seuraavaa ongelmaa, ennenkuin saa tämän pystyyn... Teen tästäkin kokemuksesta taas jutun ketjun vinkkien perusteella, joten nöyrästi kiittää hän!
-
Voiko tämä olla tosiaan näin vaikeaa? Mutta nyt ollaan (edelleen) aika lähtöasemissa.
Routerissa on maailmalla auki 22 ja LAN:n suuntaan 220.
Serverin (192.168.199.45), jossa on Ubuntu 20.04, SSH kuuntelee routerin porttia 220. Maailmalta yhteys tähän koneeseen onnistuu ongelmitta.
Lisäksi on avattu portti 22 ajatuksena sisäisempi liikenne, joten /etc/ssh/sshd_config on tuolta osin:
Port 220
Port 22
UFW on käytössä ja molemmat portit sallittu.
Jos yritän toiseen koneeseen, kutsutaan sitä vaikka asiakkaaksi, ssh tunnus@192.168.100.40 niin saan odotella yhteyden muodostumista varmaan maailman tappiin asti - eli ihan samaa ei-kerrota-mitään käyttäytymistä kuin jos yrittää kirjautua ilman avainta ssh-serverille, jossa salasanat on estetty.
Ping sen sijaan toimii:
PING 192.168.100.40 (192.168.100.40) 56(84) bytes of data.
64 bytes from 192.168.100.40: icmp_seq=1 ttl=128 time=1.60 ms
Ja toisinpäin.
Kotiverkossa on vain yksi toinen kone, oma läppäri (192.168.100.40), jossa on siis WSL2. SSH on laitettu kuuntelemaan porttia 222. UFW ei ole käynnissä. iptables -L näyttää vain tyhjät tablesit ja jokaisessa oletuskäytäntönä on accept.
Tällä ei pääse tuolle serverikoneelle, vaan ssh tunnus@192.168.199.45 kertoo ssh: connect to host 192.168.199.45 port 22: No route to host
Kun kokeilin pingiä serverille eli ping 192.168.199.45 niin se vaihtaa 10-osoitteeseen ja kertoo, että paketit filtteröidään.
PING 192.168.199.45 (192.168.199.45) 56(84) bytes of data.
From 10.64.198.66 icmp_seq=4 Packet filtered
Joten... täh? Onko minulla joku oleellinen asia kommentoituna tai laittamatta rasti ruutuun? Vai johtuuko tämä siitä, että läppäri, asiakas, on routeriin yhteydessä wifillä ja serveri verkkokaapelilla? En vaan tajua mitä merkitystä moisella olisi, mun IP:tä kuitenkin etsitään?
-
Kuuluvatko osoitteet 192.168.100.40 ja 192.168.199.4 samaan verkkoon?
-
Lisäksi on avattu portti 22 ajatuksena sisäisempi liikenne, joten /etc/ssh/sshd_config on tuolta osin:
Port 220
Port 22
UFW on käytössä ja molemmat portit sallittu.
Koneesta ei tarvitse avata kuin tuo portti 22 ja SSH:n tarvitsee kunnella ainoastaan sitä. Reititin (ja asiakas) on ainut, jonka tarvitsee tietää, mikä portti on auki internetiin päin.
Jos yritän toiseen koneeseen, kutsutaan sitä vaikka asiakkaaksi, ssh tunnus@192.168.100.40 niin saan odotella yhteyden muodostumista varmaan maailman tappiin asti - eli ihan samaa ei-kerrota-mitään käyttäytymistä kuin jos yrittää kirjautua ilman avainta ssh-serverille, jossa salasanat on estetty.
Onhan Salasanakirjautuminen kuitenkin sallittu tai vaihtoehtoisesti tuon koneen julkinen avain kopioitu toisen authorized_keys-tiedostoon?
-
Jos samaan verkkoon kuuluminen tarkoittaa saman routerin takana olemista, niin kyllä. Muutoin - ei hajuakaan edes miten moisen selvittäisi, koska ainoa IP-tieto tulee Huawein boksista. Siellä on erikseen jaettu wifissä ja kaapelilla olevat, mutta se on varmasti vain informatiivinen jako - tuskin niitä sen mukaan eri verkkoihin jaetaan. Tai sitten jaetaan, jos syy löytyy wifi vs. ethernet jaosta - ja jos se on tuosta, niin minulla loppuu tämä projekti tähän, koska minulla ei ole pienintäkään hajun tapaistakaan mistä silloin lähtisi hakemaan syytä.
Eri asia, omalla tavallaan. Mutta Windows löytää wifin takaa routeriin kaapelilla liitetyn kovin.
-
Koneesta ei tarvitse avata kuin tuo portti 22 ja SSH:n tarvitsee kunnella ainoastaan sitä. Reititin (ja asiakas) on ainut, jonka tarvitsee tietää, mikä portti on auki internetiin päin.
Tuo on se mitä en tajua ollenkaan.
Yhtä porttia voi kuunnella vain yksi palvelu. Joten router kuuntelee maailman suuntaan porttia 22 koska se on standardinomainen. Sitten se viedään purkin läpi porttiin 220, jota kuuntelee serverin SSH-serveri. Serverillä ylimääräinen 22, joka on auki sisäverkkoon päin, on sinänsä turha, mutta sen pitäisi olla kuitenkin toimiva ja taas ideana ei ole muuta kuin mahdollistaa asiakkailla "standardimaisemman" tavan ottaa yhteyttä.
Niin tai näin, niin ei homma toiminut silloinkaan kun serverillä oli vain yksi portti sshc_conf tiedostossa.
Sisäverkossa olevat asiakaskoneet pyörittävät omaa SSH-serveriään, jotka tarvitsevat myös portin auki maailmalle - suomeksi toisilleen - ja sehän täytyy olla eri kaikilla? Paitsi että ei tietenkään tarvitse, sama porttihan se on useimmissa maailman koneissa... sarjaa urautunut ajatusvirhe ajatuksesta, että samaa porttia ei voi kuunnella kaksi palvelua, mutta eihän nuo ole samoja, vaan eri koneita. Tyhmä minä.
Mutta pitäisihän kaiken silti toimia, kun ssh tunnus@ip -p XXX kertoo sen portin, jota kohde kuuntelee?
Juu, on salasanan käyttö päällä. Pikkuinen pakko, kun sattuneesta syystä ssh-copy-id ei toimi.
-
Koneesta ei tarvitse avata kuin tuo portti 22 ja SSH:n tarvitsee kunnella ainoastaan sitä. Reititin (ja asiakas) on ainut, jonka tarvitsee tietää, mikä portti on auki internetiin päin.
Tuo on se mitä en tajua ollenkaan.
Yhtä porttia voi kuunnella vain yksi palvelu. Joten router kuuntelee maailman suuntaan porttia 22 koska se on standardinomainen. Sitten se viedään purkin läpi porttiin 220, jota kuuntelee serverin SSH-serveri. Serverillä ylimääräinen 22, joka on auki sisäverkkoon päin, on sinänsä turha, mutta sen pitäisi olla kuitenkin toimiva ja taas ideana ei ole muuta kuin mahdollistaa asiakkailla "standardimaisemman" tavan ottaa yhteyttä.
Ah, teitkin noin päin. Tuon 220-portin käytöstä ssh:lle ei ole hyötyä, koska voit ohjata reitittimestä ihan minkä tahansa portin mihin tahansa sisäverkon koneen porttiin. Yleensä ulkoverkkoon avataan jonkin muu kuin portti 22, koska se vähentää "koputteluja", vaikka ei sinänsä parannakaan tietoturvaa.
Tuli tuo edellinen viesti lähettyä vähän kiireessä, kun ukkonen yllätti ja piti sammuttaa kone. Täällä maaseudulla niitä ei parane jättää seinään eikä ainakaan päälle.
-
Ei kai tässä muu auta kuin siirtää läppäri kaapelilla kiinni routeriin ja katsoa sitten, että löytävätkö ne toisensa.
Kauhea vähti siinäkin, toisella puolella tölliä.
Mutta... JOS ongelma on wifi vs. verkkokaapeli, niin törmään samaan uudestaan kun/jos ostan Raspin.
-
Mutta pitäisihän kaiken silti toimia, kun ssh tunnus@ip -p XXX kertoo sen portin, jota kohde kuuntelee?
Joo, pitäisi toimia, kun portin määrittelee noin.
Ubuntussa /var/log/auth.log kertoo kirjautumisista, ja järjestelmälokin puolella saattaa näkyä myös jotain. WSL:ssä lokitukset toimivat ehkä eri tavalla tai olla toimimatta: https://unix.stackexchange.com/questions/518997/monitor-ssh-attempts-in-windows-subsystem-linux
Ongelman selvittelyä varten /etc/ssh/sshd_config-tiedostossa voi asettaa LogLevel VERBOSE, niin lokissa näkyy enemmän.
SSH-clientin puolella vipu -vvv listaa kaiken mahdollisen yhteydenottoyrityksestä. Sitä voi sitten verrata toimivaan yhteyteen.
Toimiiko SSH-yhteys lokaalisti sillä koneella, jossa SSH-palvelin sijaitsee?
ssh localhost
-
Meillä maalla kaivettiin sähkökaapelit maahan ja revittiin puhelinpiuhat kokonaan pois. Helpottanut aika paljonkiin ukkosstressiä.
Ei minua koputukset tässä suuremmin häiritse tässä tapauksessa. Siksi toiseksi script kiddiet löytää kuitenkin avoinaiset portit. Mutta toki, joku epstandardinomainen auttaisi, malliin 35000.
Mun on pakko tehdä asiat tunnistettavasti. Muuten en kohta tiedä mitä missä ja miksi. Sen takia haluaisin pitää LAN:n suuntaan eri portin kuin maailmaan. Jos kaikki on 22 niin hetken kuluttua en tiedä itsekään mistä kakskakkosesta puhun ;D
-
Juu, toimii ssh localhost. Molemmissa.
Kuinka monta kierrosta muuten tuota itseensä kirjautumista voi tehdä :o
-
Mun on pakko tehdä asiat tunnistettavasti. Muuten en kohta tiedä mitä missä ja miksi. Sen takia haluaisin pitää LAN:n suuntaan eri portin kuin maailmaan. Jos kaikki on 22 niin hetken kuluttua en tiedä itsekään mistä kakskakkosesta puhun ;D
Kuulostaa kyllä nurinkuriselta etenkin noin päin että LAN-puolella on jokin muu portti kuin 22. Koneen nimellä/ip-osoitteella erotat ne palvelimet toisistaan. Paljon helpompaa, kun ei tarvitse lähiverkon puolella arpoa, millä koneella on mikäkin portti käytössä.
Juu, toimii ssh localhost. Molemmissa.
Okei, sitten ongelma lienee joko palomuurissa tai verkkoliikenteessä. Kannattaa kokeilla aluksi ilman UFW:tä.
sudo ufw disable
Erilliset aliverkot 192.168.100.0 ja 192.168.199.0 wifille ja ethernetille ovat jokseenkin outoja, ja selvästi sotkevat asiaa ainakin jompaan kumpaan suuntaan. Johtuu varmasti reitittimen asetuksista, joten kannattaa tutkia sieltä, miten molemmille koneille saisi 192.168.100 -alkuisen osoitteen
-
Edeltäviä en vielä kokeillut, mutta laitoin palomuurin päälle, koska kokeilin toimisiko sen kanssa. Eli ei toiminut silloinkaan kun ei ollut päällä.
Wifillä ei ole asian kanssa mitään tekemistä, Ei onnistu kaapelillakaan.
Mielenkiintoista sen sijaan on, että Windowsin komenkehoitteesta ping menee serveriksi kutsutulle ihan nätistä. Joten syy täytyy olla tavalla tai toisella WSL:ssä tai sen sisällä.
Minulle tuli yöllä Windowsiin 2004 päivitys ja sen jälkeen otin käyttöön WSL2:sen. PowerShell vaihtaa sitä juuri takaisin ykkösversioon, niin pääsen karsimaan sen - tai osoittamaan syylliseksi.
-
Okei, oliko nyt niin, että ongelmallinen SSH-palvelin on nimenomaan WSL:ssä? Linux-koneessa sijaitseva SSH-palvelu toimii kaikkialta ongelmitta?
Minulla ei varsinaisesti ole WSL:stä omaa kokemusta, mutta se on lähinnä suunniteltu devaajien kehitysalustaksi, eikä niinkään palvelujen pyörittämiseen, joten niiden kanssa voi tulla erinäisiä mutkia matkaan.
-
Eikä johtunut WSL:n versiosta.
Tuota... jos kerron jotain, niin lupaatteko, että ette suutu?
Ihmettelin nimittäin hieman ehdotusta saada kaikki IP:t samalle 198.168.100 alkuiselle. Kuin myös ihmettelyä, että kuuluvatko ne samaan verkkoon. Kun kaikki nimenomaan ovat aina samalla, ainoastaan viimeiset digitit muuttuu.
Routerin IP-lista ei anna kopypeistata. Siksi käytän bashin historiaa ja jos jotain täytyy kopioida, niin teen sen tietysti jostain vanhemmasta komennosta. Joten nyt ollaan sillai justjajust mahdollisuuksien rajoissa, että minun ei olisi koskaan edes pitänyt yrittää 198.168.199-alkuista osoitetta...
Joten koko sählinki ja päivittely johtuivat vain siitä, että en ymmärrä eroa 100 ja 199 välillä.
Anteeksi!
Niin, ja kun koittaa hieman erilaisella IP:llä, kuten oikealla, niin sitten toimii.
-
Saisikohan joku ylläpitävämpi siivota tämän ketjun? Suunnilleen siitä asti kun ensimmäisen kerran yhteysongelmat tuli? Toisaalta ihan hyvä oppi, että älä luule kirjoittaneesi oikein, vaan tarkista ja tarkista - vaikka merkkisokeaksi tuleekin helposti.
Njooh. Uusi yritys, koska ongelma on edelleen. Väittäisin jopa, että töpeksimistä huolimatta lähdin liikkeelle oikeasta ongelmasta. Vasta typotetun IP:n myötä homma eskaloitui.
Routerissa on WAN-portti 22 auki maailmalle ja portti 22 LAN:n suuntaan on auki IP:lle 192.168.100.45, joka on serveriksi kutsuttu Ubuntu 20.04 serveriasennuksella. SSH ulkomaailmasta onnistuu serverille.
Serveri on verkkokaapelilla kiinni routerissa. SSH:lle on laitettu sshd_configissa portti 22. Siitä saa yhteyden ulkomaailmaan ilman ongelmia. Myös ping 192.168.100.40 toimii ja tuossa IP:ssä on asiakkaaksi kutsumani Win10, jossa Ubuntun töitä tekee WSL2. Sen sijaan ssh tunnus@192.168.100.40 jää vain odottamaan, eikä mitään tapahdu, UFW on tilassa inactive eikä iptablesissa ole sääntöjä sekä jokaisen tablesin policy on ACCEPT.
Jos sammutan asiakkaalta Avastin, niin mitään muutosta ei näy missään. Jos otan myös Windows Defenderin pois päältä, niin serveri yrittäessään asiakasta ilmoittaa ssh: connect to host 192.168.100.40 port 22: Connection refused.
Defenderissä on sallittu liikenne sisään ja ulos OpenSSH Server, SSH Server ja sshd.
Asiakas on wifillä routerissa kiinni ja ssh tunnus@192.168.100.45 serverille onnistuu kauniisti. UFW on inactive ja iptables myös tyhjä. sshd_configissa on sallittu salasana ja portti on 22. Myös maailmalle pääsee ongelmitta.
Sitten vaihdoin noiden paikkoja. Laitoin WSL-koneen serveriksi ja Ubuntun asiakkaaksi. En enää päässyt ulkoa sisälle, eli ongelma on tavalla tai toisella WSL:ssä. Pääsen ulos, mutta en kirjautumaan sisälle. Ja tuo on uutta, koska ennen tätä showta WSL nimenomaan kuunteli ulkomaailmaa. Siltä osin ainoa mikä on varsinaisesti muuttunut, on se Windowsin 2004 päivitys (joka oli major, mutta jo jonkun kuukauden ikäinen) ja sen mukana myös WSL:n muutos kakkosversioon - joka vaati kernelin päivityksen.
Tiedä häntä. Joko joku pikkudetalji on edelleen pielessä tai sitten seuraava peliliike on asentaa WSL ja Ubuntu uusiksi. Kun hiukan ihmettelen sitäkin, että kun yritin käynnistää UFW:n, niin tulos oli tämä:
ERROR: problem running ufw-init
iptables-restore v1.8.4 (legacy): Couldn't load match `limit':No such file or directory
Error occurred at line: 63
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
iptables-restore v1.8.4 (legacy): Couldn't load match `limit':No such file or directory
Error occurred at line: 8
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
Problem running '/etc/ufw/before.rules'
Problem running '/etc/ufw/user.rules'
-
Öh... ongelma liittyy tuohon uuteen WSL2:seen ja johonkin hemmeti virtuaalijotain juttuun, josta en ymmärrä yhtään mitään, mutta jonka takia minulla on laittessa tällä hetkellä virtuaalinen eth0
Ja tässä homma pissii:
ifconfig
inet 172.27.152.62 netmask 255.255.240.0 broadcast 172.27.159.255
Tuolla IP:llä ei ole mitään tekemistä minun sisäverkkoni kanssa.
Viisaammat ja osaavammat ymmärtänevät tästä enemmän:
https://github.com/microsoft/WSL/issues/4150 (https://github.com/microsoft/WSL/issues/4150)
Tietysti yöllä näiden kanssa painiminen on jotain, mutta juuri nyt mielenkiintoni WSL:ään painui aika paljon. Eihän minulla ole vaihtoehtoja, mutta silti.
Eniten tässä pännii se, että jos olisin tajunnut googlettaa tarkemmin aiemmin, niin ei olisi tuhlannut aikaan tuntitolkulla jahdatessasi varjoja (enkä teidän, koska en olisi typonnut sitä perhanan IP:tä...)
No, pääsen sisäverkon IP:llä portin 22 kautta ja Win-tunnuksella komentokehoitteeseen ja siitä sitten komennolla wsl WSL:ään. Parempi sekin.
-
Öh... ongelma liittyy tuohon uuteen WSL2:seen ja johonkin hemmeti virtuaalijotain juttuun, josta en ymmärrä yhtään mitään, mutta jonka takia minulla on laittessa tällä hetkellä virtuaalinen eth0
Ja tässä homma pissii:
ifconfig
inet 172.27.152.62 netmask 255.255.240.0 broadcast 172.27.159.255
Tuolla IP:llä ei ole mitään tekemistä minun sisäverkkoni kanssa.
Viisaammat ja osaavammat ymmärtänevät tästä enemmän:
https://github.com/microsoft/WSL/issues/4150 (https://github.com/microsoft/WSL/issues/4150)
Jep, tuo vaatii porttiohjausten lisäämisen Windowsin palomuuriin. Onnistunee issuen kommenteissa olevalla skriptillä, ainakin peukutusten perusteella: https://github.com/microsoft/WSL/issues/4150#issuecomment-504209723
WSL on tosiaan toistaiseksi jokseenkin hankala alusta jatkuvasti ajettaville palveluille, vaikka aika kattava ja kehittyvä systeemi sinänsä kyseessä.
-
Google löysi useammankin, jolla ei ole toiminut. Eikä toiminut minullakaan. Liekö versiokysymys, mikä PowerShell on asennettuna tai jotain muuta - ei hajuakaan. Mutta toistaiseksi hyväksyn sen, että
- tuhlasin ihan perhanasti aikaa asiaan, jossa itseasiassa ei ollut mikään rikki, vaan käyttäytyminen oli muuttunut
- homma toimii silläkin, että kirjaudun Windowsiin ja etenen sieltä erillisellä bash-komennolla Ubuntuun
Teen yhteenvedon näistä - mutta pakko myöntää, että näiden parin päivän kokemusten perusteella se alunperin ehdottamasi oma-portti-jokaiselle ratkaisu olisi kylläkin ollut kaikista helpoin. Mutta taas kertyi hiukan lisää oppia.
Seuraavaksi sitten yritän hahmottaa, että ostaako seuraavaksi Raspi eli tarvitsenko edes harrastuksen nimissä erillistä purkkia - mutta siinä ei oikein yhteisä voi auttaa.