Externe verbinding via console met Ubuntu-server. Terminal-opstelling

" U bent een beginnende beheerder en wilt bijvoorbeeld uw webserver opzetten. Ga naar internet, zoek een artikel dat bij je past en ga je gang! Laten we op één belangrijk punt letten: in bijna al deze artikelen wordt een minimum aan opdrachten gegeven om de noodzakelijke services te starten. Oké - het werkte! Heb je er alles aan gedaan om ervoor te zorgen dat het niet meer werkt? SSH gebruiken via internet? Waarom benadrukt niemand in zijn artikelen de problemen die nieuwe beheerders kunnen krijgen met deze benadering van het opzetten van een server, omdat de artikelen specifiek voor beginners zijn geschreven. Om ervoor te zorgen dat u tijdig aandacht besteedt aan het veiligheidsprobleem, zal ik in mijn artikelen zeker aantekeningen en links naar dit materiaal maken. Een gewaarschuwd mens - voorarm!"

SSH (secure shell) is dus een beveiligde terminalserver die externe toegang tot het systeem biedt. Veilig omdat al het verkeer tussen client en server is gecodeerd. Is het veilig met standaardinstellingen? Als je een server hebt met de mogelijkheid om via SSH verbinding te maken via internet, zullen er zeker mensen zijn die een wachtwoord willen kiezen om in te loggen. Ik denk dat het niet nodig is om uit te leggen dat een mogelijke aanvaller vrijwel onbeperkte toegang tot het systeem kan krijgen.

In alle moderne Ubuntu-distributies proberen ontwikkelaars het beveiligingsniveau te verhogen met standaardparameters, maar dit is niet altijd voldoende, en soms kiezen we zelf voor het verkeerde concept en maken we fouten.

Een SSH-server installeren in Ubuntu.

Het installeren van een SSH-server in Ubuntu doe je met het volgende commando:

Sudo apt-get install ssh openssh-server

Na installatie wordt de SSH-server automatisch geregistreerd bij het opstarten. U kunt het starten, stoppen of herstarten ervan regelen met behulp van de opdrachten:

Sudo-service ssh stop | begin | opnieuw opstarten

Hoofdconfiguratiebestand van SSH - server - bestand /etc/ssh/sshd_config, alleen leesbaar of bewerkbaar door de supergebruiker (root). Om de wijzigingen toe te passen, moet u de ssh-server opnieuw opstarten.

Beveiligingsinstellingen voor SSH-server.

Standaardprotocol.

Nogmaals, moderne distributies implementeren standaard het SSH2-protocol. Als in jouw geval zoiets als:

Protocol 2.1

Je hoeft er maar 2 achter te laten:

Protocol 2

Het gebruik van het onveilige SSH1-protocol wordt niet aanbevolen.

In recente versies van Ubuntu is de toegang van rootgebruikers via SSH standaard beperkt.

PermitRootLogin zonder wachtwoord

VergunningRootLogin nr

Met deze instellingen kan de rootgebruiker niet inloggen via SSH.

Deze optie is ook handig als meerdere beheerders met de server werken onder een supergebruikersaccount. Beheerders loggen in onder hun account en krijgen dan pas root-rechten, dit maakt het veel eenvoudiger om de server en de acties die beheerders uitvoeren te controleren.

Iets meer over root in Ubuntu, de standaardgebruiker die is aangemaakt (tijdens de systeeminstallatie) kan alle administratieve taken uitvoeren via sudo. Het activeren van de rootgebruiker voor toegang tot het systeem lijkt mij een onredelijke beslissing.

Verleen alleen toegang aan gespecificeerde gebruikers of groepen.

Laten we ons voorstellen dat er een bepaald aantal gebruikers op uw server is, maar u hoeft slechts enkele gebruikers toegang te verlenen via SSH. Laten we dus de kring van gebruikers die toegang hebben beperken:

Gebruikers toestaan ​​gebruiker1 gebruiker2

U kunt ook de gewenste groep opgeven, bijvoorbeeld beheerders:

AllowGroups-beheerders

Toegang weigeren met "lege" wachtwoorden.

U moet externe toegang met lege wachtwoorden expliciet weigeren:

VergunningLeegWachtwoorden nr

De standaardpoort wijzigen.

SSH draait standaard op poort 22. Dienovereenkomstig zal het grootste deel van de aanvallen specifiek op deze poort worden gericht, waarna met behulp van de selectie van een gebruikersnaam en wachtwoord pogingen zullen worden ondernomen om toegang te krijgen tot de server. We hebben de bekendste gebruikersnaam al uitgesloten van de database van een mogelijke aanvaller (root) en alleen toegang verleend aan bepaalde gebruikers, nu zullen we het aantal mogelijke aanvallen (bots die op zoek zijn naar kwetsbaarheden op standaardpoorten) verminderen door de standaardpoort te wijzigen ( de nieuwe haven moet vrij zijn!).

Laten we bijvoorbeeld veranderen naar:

Poort 2220

Het is de moeite waard om te begrijpen dat het wijzigen van de poort u op geen enkele manier zal helpen tijdens een gerichte brute-force-aanval (het raden van wachtwoorden). Een aanvaller kan bijvoorbeeld een poortscanner draaien op het IP-adres waar uw server zich bevindt, waardoor hij een lijst krijgt met alle open poorten.

Onthoud ook dat u nu, om verbinding te maken met de server, naast het IP-adres ook het poortnummer moet opgeven.

Een echt werkende optie voor brute force-beveiliging is het gebruik van RSA-sleutels voor SSH2-authenticatie. Met deze methode genereert de gebruiker een paar sleutels, waarvan de ene sleutel privé is en de andere openbaar. De publieke sleutel bevindt zich op de server en wordt gebruikt om de identiteit van de gebruiker te verifiëren. Bovendien kan de combinatie van sleutel en openbare sleutel worden beveiligd met een wachtwoordzin, waardoor de cryptografische kracht van de autorisatie wordt vergroot. De logica is simpel: als u geen wachtwoord gebruikt voor autorisatie, valt er niets te raden!

We loggen in op het systeem onder de gebruiker voor wie we SSH-toegang tot de server gaan configureren.

Laten we een RSA-sleutel met de lengte 4096 genereren. U wordt gevraagd de opslaglocatie op te geven en deze op de standaardwaarde te laten (/home/Gebruikersnaam/.ssh/id_rsa). U wordt ook gevraagd een wachtwoord in te stellen voor de gemaakte sleutel. Als u geen wachtwoord opgeeft, hoeft u dit niet in te voeren tijdens de authenticatie op de server met behulp van een certificaat; dit is minder veilig. Ik raad u aan een wachtwoord op te geven:

Ssh-keygen -t rsa -b 4096

Er wordt een paar sleutels gemaakt in de opgegeven map:

id_rsa.pub- publiek

id_rsa– privé

Laten we controleren of de bestanden zijn gemaakt:

Cd ~/.ssh ls -al

Stel machtigingen in voor de map en bestanden:

Sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/id*

De privésleutel moet op een veilige manier naar de client worden overgedragen en van de server worden verwijderd om te voorkomen dat de sleutels in gevaar komen.

De id_rsa-sleutel wordt doorgegeven aan de client:

/home/Gebruikersnaam/.ssh/id_rsa

Waarna het van de server wordt verwijderd:

Sudo rm /home/Gebruikersnaam/.ssh/id_rsa

Laten we een geautoriseerde_sleutels-bestand maken (we bevinden ons in het systeem onder dezelfde gebruiker “Gebruikersnaam” waarvoor het certificaat is gemaakt) en kopiëren de inhoud van het bestand ernaartoe id_rsa.pub, Laten we de eigenaar bepalen en de rechten op de map en het bestand instellen.

Cd ~/.ssh sudo touch geautoriseerde_sleutels sudo chown Gebruikersnaam: Gebruikersnaam geautoriseerde_sleutels sudo cat id_rsa.pub >> geautoriseerde_sleutels sudo chmod 0700 ~/.ssh/ sudo chmod 0600 ~/.ssh/authorized_keys

Laten we controleren of de tekst is gekopieerd:

Sudo cat /home/Gebruikersnaam/.ssh/authorized_keys

Als de tekst succesvol is gekopieerd, kunt u de openbare sleutel verwijderen:

Sudo rm /home/Gebruikersnaam/.ssh/id_rsa.pub

Sudo nano /etc/ssh/sshd_config

U moet de regels verwijderen en de parameters als volgt instellen:

# autorisatie toestaan ​​met sleutels PubkeyAuthentication ja # Pad waar de sleutels komen te staan ​​waarmee u voor iedere gebruiker uw eigen bestand in zijn directory kunt koppelen. AuthorizedKeysFile %h/.ssh/authorized_keys

Laten we de SSH-server opnieuw opstarten:

Sudo-service ssh opnieuw opstarten

Nadat u certificaten heeft gegenereerd voor alle gebruikers (die SSH-toegang nodig hebben), raad ik u aan de wachtwoordverificatie uit te schakelen door hetzelfde bestand te bewerken /etc/ssh/sshd_config

Let op: zorg ervoor dat u toegang heeft tot de sleutel voordat u de wachtwoordauthenticatie uitschakelt

WachtwoordAuthenticatienr Verbinding maken met een SSH-server via PuTTY met behulp van een certificaat.

Eerst moet u de privésleutel (Gebruikersnaam-gebruikerssleutel) converteren, die we eerder van de server hebben gehaald.

Hiervoor hebben we het PuTTYgen-programma nodig.

Upload het privésleutelbestand " Conversies - Sleutel importeren".

Als u dit heeft ingesteld, voert u het wachtwoord in.

Selecteer " Bewaar privésleutel" en sla het resulterende ppk-bestand op. Het moet worden opgeslagen op een plaats waar het niet kan worden aangetast.

Open het PuTTY-programma en configureer de verbinding:

Sessie - Hostnaam (of IP-adres) IP-adres van de host waarop de SSH-server is geconfigureerd;

Sessie - Haven Poort gespecificeerd in de SSH-serverinstellingen;

Sessie - Opgeslagen Sessie Naam van sessie (verbinding);

Verbinding - Gegevens - Gebruikersnaam voor automatisch inloggen Gebruikersnaam;

Verbinding - SSH - Auth - Privésleutelbestand voor authenticatie Pad naar ppk-bestand;

Sessie - Opslaan Bewaar de sessie;

Sessie - Opgeslagen sessie(selecteer onze sessie) - Laden - Open- De sessie zou moeten beginnen;

Voer het wachtwoord in en druk op Enter, waarna we in het systeem komen.

Als het certificaat van de gebruiker is aangetast, trekken we het certificaat in en weigeren we de toegang aan de gebruiker.

Om de toegang van Gebruikersnaam tot de Host te blokkeren met behulp van een certificaat, gaan we naar de map waar zijn certificaat is opgeslagen:

Cd ~/.ssh

Verwijder het openbare certificaatbestand geautoriseerde_sleutel van de OpenSSH-server, als u onzorgvuldig geen bestanden hebt verwijderd id_rsa.pub En id_rsa, verwijder ze. We bekijken de inhoud van de map met behulp van het commando "ls".

Wij verwijderen de benodigde bestanden:

Sudo rm geautoriseerde_sleutel id_rsa.pub id_rsa

Het is ook een goede gewoonte om de tijd voor het invoeren van gegevens voor autorisatie te beperken, evenals een time-out in geval van inactiviteit.

In het onderstaande voorbeeld is deze tijd beperkt tot 30 seconden:

InloggenGraceTime 30

Time-out wanneer er geen verbindingsactiviteit is.

Verbreekt automatisch de verbinding na een bepaalde tijd waarin inactiviteit in de console wordt geregistreerd.

KlantAliveCountMax – De parameter geeft het totale aantal berichten aan dat door de ssh-server is verzonden om ssh-clientactiviteit te detecteren. De standaardwaarde is 3.

KlantAliveInterval– De parameter geeft de wachttijd in seconden aan. Na het verlopen stuurt de ssh-server een verzoekbericht naar de client. De standaardwaarde van deze parameter is 0. De server verzendt geen bericht ter verificatie.

Ssh-client automatisch uitschakelen na 5 minuten (300 seconden):

ClientAliveInterval 300 ClientAliveCountMax 0

samenvatting: Het artikel beschrijft geavanceerde OpenSSH-functies die het leven van systeembeheerders en programmeurs die niet bang zijn voor de shell aanzienlijk kunnen vereenvoudigen. In tegenstelling tot de meeste handleidingen, die niets anders beschrijven dan toetsen en -L/D/R-opties, heb ik geprobeerd alle interessante functies en gemakken die ssh met zich meebrengt te verzamelen.

Waarschuwing: posten Erg volumineus, maar vanwege het gebruiksgemak heb ik ervoor gekozen om het niet in stukken te snijden.

Inhoudsopgave:

• sleutelbeheer
• bestanden kopiëren via ssh
• I/O-streams doorsturen
• Externe FS monteren via ssh
• Uitvoering van code op afstand
• Aliassen en opties voor verbindingen in .ssh/config
• Standaardopties
• X-server doorsturen
• ssh als sokken-proxy
• Port forwarding - vooruit en achteruit
• Omgekeerde Sox-proxy
• tunneling van L2/L3-verkeer
• Autorisatieagent doorsturen
• Ssh tunnelen via ssh via een niet-vertrouwde server ( waarschijnlijk weet je dit niet)

Sleutelbeheer

Sleutelgeneratie

De sleutel kan worden vergrendeld met een wachtwoord. Dit wachtwoord wordt (in normale GUI's) één keer gevraagd en wordt enige tijd bewaard. Als het wachtwoord leeg is, wordt er bij gebruik niet om gevraagd. Het is onmogelijk om een ​​vergeten wachtwoord te herstellen.

U kunt het wachtwoord voor de sleutel wijzigen met behulp van de opdracht ssh-keygen -p.

Sleutelstructuur

Kopieer de sleutel naar de server

Als u het wachtwoord van de gebruiker kent, kan het proces worden vereenvoudigd. Team ssh-copy-id gebruiker@server Hiermee kunt u de sleutel kopiëren zonder bestanden handmatig te bewerken.

Opmerking: in oude ssh-handleidingen wordt geautoriseerde_sleutels2 vermeld. Reden: er was de eerste versie van ssh, daarna was er een tweede (huidige), ze maakten er hun eigen set configuraties voor, iedereen was er erg moe van, en de tweede versie schakelde lang over naar versies zonder enige "2" tijd geleden. Dat wil zeggen, altijd geautoriseerde_sleutels en denk niet aan verschillende versies.

Als je ssh op een niet-standaard poort hebt, dan vereist ssh-copy-id een speciale truc tijdens het werken: ssh-copy-id "-p 443 user@server" (let op de aanhalingstekens).

Serversleutel

Als de serversleutel is gewijzigd (de server is bijvoorbeeld opnieuw geïnstalleerd), schreeuwt ssh dat de sleutel vervalst is. Let op: als de server niet is aangeraakt, maar ssh schreeuwt, dan breek je in op de verkeerde server (er verscheen bijvoorbeeld een andere computer met hetzelfde IP-adres op het netwerk, allerlei lokale netwerken met 192.168.1.1, waarvan er zijn er enkele miljoenen in de wereld, die hier vooral last van hebben). Het “evil man in the middle aanval”-scenario is onwaarschijnlijk, vaker is het gewoon een fout met het IP-adres, maar als “alles in orde is” en de sleutel is veranderd, is dit een reden om het niveau van paranoia een paar niveaus te verhogen (en als je autorisatie hebt met behulp van een sleutel, en de server plotseling om een ​​wachtwoord vraagt, dan kan paranoia voor 100% worden ingeschakeld en hoef je geen wachtwoord in te voeren).

U kunt een bekende serversleutel verwijderen met het commando ssh-keygen -R-server. In dit geval moet u ook de IP-sleutel verwijderen (deze worden afzonderlijk opgeslagen): ssh-keygen-R 127.0.0.1.

De serversleutel wordt opgeslagen in /etc/ssh/ssh_host_rsa_key En /etc/ssh/ssh_host_rsa_key.pub. Ze kunnen zijn:
a) kopiëren van de oude server naar de nieuwe.
b) genereren met behulp van ssh-keygen. Het is niet nodig om een ​​wachtwoord op te geven (d.w.z. leeg). De ssh-server kan de sleutel met het wachtwoord niet gebruiken.

Houd er rekening mee dat als u servers kloont (bijvoorbeeld in virtuele machines), de ssh-sleutels van de server opnieuw moeten worden gegenereerd.

Het is beter om oude sleutels uit know_hosts te verwijderen, anders zal ssh klagen over dubbele sleutels.

Bestanden kopiëren

Scp-pad/mijnbestand [e-mailadres beveiligd]:/volledig/pad/naar/nieuw/locatie/

Je kunt ook het tegenovergestelde doen:
scp [e-mailadres beveiligd]:/volledig/pad/naar/bestand /pad/naar/plaats/hier

Fish waarschuwing: Ondanks dat mc verbinding kan maken via ssh, zal het kopiëren van grote bestanden erg pijnlijk zijn, omdat... fish (de mc-module voor het werken met ssh als virtuele fs) is erg traag. 100-200 kb is de limiet, daarna begint de test van geduld. (Ik herinnerde me mijn vroege jeugd, toen ik, zonder iets van scp af te weten, ~5GB via fish naar mc kopieerde, het duurde iets meer dan 12 uur op FastEthernet).

Het is geweldig om te kunnen kopiëren. Maar ik wil "opslaan als" - en onmiddellijk naar de server. En om in de grafische modus te kopiëren, niet vanuit een speciaal programma, maar vanuit een bekend programma.

Dit is ook mogelijk:

sshfs

Eigenlijk is er een uitzondering: O_DIRECT wordt helaas niet ondersteund (dit is geen sshfs-probleem, dit is in het algemeen een zekeringprobleem).

Gebruik: installeer het sshfs-pakket (het sleept de zekering mee).

Eigenlijk een voorbeeld van mijn script dat desunote.ru (bevindt zich op mijn thuiscomputer - foto's ervan worden in dit artikel getoond) op mijn laptop:

#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o opnieuw verbinding maken

We maken het bestand +x, noemen het, gaan naar een willekeurige applicatie, zeggen opslaan en zien:

sshfs-opties die belangrijk kunnen zijn: -o opnieuw verbinden (zegt probeer opnieuw verbinding te maken in plaats van fouten).

Werk je veel met data vanuit root, dan kun (moet) je een idmap maken:

-o idmap=gebruiker. Het werkt als volgt: als we verbinding maken als de gebruiker pupkin@server, en lokaal werken als de gebruiker vasiliy, dan zeggen we “neem aan dat pupkin-bestanden vasiliy-bestanden zijn.” nou ja, of “root”, als we verbinding maken als root.

In mijn geval is de idmap niet nodig, omdat de gebruikersnamen (lokaal en extern) hetzelfde zijn.

Houd er rekening mee dat we alleen comfortabel kunnen werken als we een ssh-sleutel hebben (zie het begin van het artikel). Als dat niet het geval is, is wachtwoordautorisatie vervelend voor 2-3 verbindingen.

Je kunt het weer uitschakelen met de opdracht fusermount -u /pad Als de verbinding echter vastzit (er is bijvoorbeeld geen netwerk), dan kun/moet je dit doen vanaf de root: sudo umount -f /path.

Uitvoering van code op afstand

Ssh-gebruiker@server ls /etc/

Zal de inhoud van /etc/ op de server weergeven, terwijl we een lokale opdrachtregel zullen hebben.

Sommige toepassingen willen een bedieningsterminal hebben. Ze moeten worden uitgevoerd met de optie -t:
ssh gebruiker@server -t remove_command

Overigens kunnen we zoiets als dit doen:
ssh gebruiker@server cat /some/file|awk "(print $2)" |local_app

Dit brengt ons bij de volgende functie:

Voorwaarts stdin/uit

Ssj [e-mailadres beveiligd] opdracht >mijn_bestand

Laten we zeggen dat we lokale uitvoer op afstand willen uitvoeren

Mijnopdracht |scp - [e-mailadres beveiligd]:/pad/remote_file

Laten we het voorbeeld ingewikkelder maken - we kunnen bestanden overbrengen van server naar server: We maken een keten om stdin op 10.1.1.2 te plaatsen, die niet van buitenaf voor ons toegankelijk is:

Mijnopdracht | ssh [e-mailadres beveiligd]"scp - [e-mailadres beveiligd]:/pad/naar/bestand"

Er is ook zo'n raadselachtige techniek voor het gebruik van pijp (vriendelijk voorgesteld in de reacties op LJ):

Tar -c * | ssh gebruiker@server "cd && tar -x"

Tar pakt bestanden lokaal in met een masker, schrijft ze naar stdout, vanwaar ssh ze leest, brengt ze over naar stdin op een externe server, waar cd ze negeert (leest stdin niet), en tar leest ze en pakt ze uit. Het scp is, om het zo te zeggen, voor de armen.

Aliassen

In een min of meer groot bedrijf blijken de servernamen er vaak zo uit te zien: spb-MX-i3.extrt.int.company.net. En de gebruiker daar is niet gelijk aan de lokale. Dat wil zeggen, u moet als volgt inloggen: ssh [e-mailadres beveiligd]. Elke keer dat je typt, krijg je geen genoeg van tunnelsyndromen. In kleine bedrijven is het probleem het tegenovergestelde: niemand denkt aan DNS en de toegang tot de server ziet er als volgt uit: ssh [e-mailadres beveiligd]. Kortom, maar toch vervelend. Er is zelfs nog meer drama als we een niet-standaard poort hebben, en bijvoorbeeld de eerste versie van ssh (hallo tegen de Cisco's). Dan ziet alles er zo uit: ssh -1 -p 334 [e-mailadres beveiligd]. Hang jezelf op. Over het drama met scp wil ik het niet eens hebben.

Je kunt systeembrede aliassen op IP (/etc/hosts) registreren, maar dit is een kromme oplossing (zowel de gebruiker als de opties worden nog steeds afgedrukt).

Bestand ~/.ssh/config Hiermee kunt u verbindingsparameters instellen, inclusief die specifiek voor servers, wat het belangrijkst is, verschillend voor elke server. Hier is een voorbeeldconfiguratie:

Host ric Hostnaam ooo-horns-and-hooves.rf Gebruiker Beheerder ForwardX11 ja Compressie ja Host thuis Hostnaam myhome.dyndns.org Gebruiker vasya WachtwoordAuthenticatie nee

Alle beschikbare opties zijn te zien in man ssh_config(niet te verwarren met sshd_config).

Standaardopties

Host * Gebruikersrootcompressie ja

Hetzelfde kan worden gedaan in /etc/ssh/ssh_config (niet te verwarren met /etc/ssh/ssh D _config), maar hiervoor zijn rootrechten vereist en dit geldt voor alle gebruikers.

X-server doorsturen

Theorie: Grafische applicaties in Unix gebruiken meestal de X-server (wayland is onderweg, maar nog steeds niet klaar). Dit betekent dat de applicatie start en verbinding maakt met de X-server om te tekenen. Met andere woorden, als je een bare metal-server hebt zonder gui en een lokale x-server (waar je werkt), dan kun je applicaties van de server op je bureaublad laten tekenen. Normaal gesproken is verbinding maken met een externe X-server niet het meest veilige of triviale iets. Met SSH kunt u dit proces vereenvoudigen en volledig veilig maken. En de mogelijkheid om het verkeer te verminderen, stelt u ook in staat om met minder verkeer rond te komen (dat wil zeggen, het kanaalgebruik te verminderen, dat wil zeggen de ping te verminderen (meer precies, de latentie), dat wil zeggen vertragingen te verminderen).

Toetsen: -X - X server doorsturen. -Y autorisatie doorsturen.

U hoeft alleen de combinatie ssh -XYC user@SERVER te onthouden.
In het bovenstaande voorbeeld (de bedrijfsnamen zijn fictief) maak ik niet voor niets verbinding met de ooo-horns-i-kopyta.rf-server, maar om toegang te krijgen tot de Windows-server. We kennen allemaal de beveiliging van Microsoft wanneer we op het netwerk werken, dus het is ongemakkelijk om kale RDP buiten bloot te leggen. In plaats daarvan maken we via ssh verbinding met de server en voeren daar vervolgens de opdracht rdesktop uit:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200

En een wonder, een inlogvenster in Windows op onze desktop. Houd er rekening mee dat het zorgvuldig is gecodeerd en niet te onderscheiden is van regulier ssh-verkeer.

Sokken-proxy

Gesloten havens brengen bijzondere problemen met zich mee. Jabber wordt gesloten, daarna IMAP, of iets anders.

Een gewone VPN (pptp, l2tp, openvpn) werkt in dergelijke situaties niet; deze wordt simpelweg niet doorgelaten. Experimenteel is bekend dat poort 443 het vaakst wordt verlaten, en in de CONNECT-modus, dat wil zeggen dat het wordt doorgegeven "zoals het is" (normale http kan ook transparant in een SQUID worden verpakt).

De oplossing is sokken-proxy ssh-bedrijfsmodus. Het principe: een ssh-client maakt verbinding met de server en luistert lokaal. Nadat het verzoek is ontvangen, stuurt het dit (via een open verbinding) naar de server, de server brengt een verbinding tot stand volgens het verzoek en verzendt alle gegevens terug naar de ssh-client. En hij antwoordt de persoon die erom vroeg. Om te werken, moet u applicaties vertellen dat ze “sokken-proxy moeten gebruiken”. En geef het proxy-IP-adres op. In het geval van ssh is dit meestal localhost (op deze manier geef je je kanaal niet aan vreemden).

Een verbinding in de sok-proxy-modus ziet er als volgt uit:
ssh -D 8080 gebruiker@server

Omdat de wifi van anderen meestal niet alleen waardeloos is, maar ook traag, kan het een goed idee zijn om de optie -C (verkeer comprimeren) in te schakelen. Het blijkt bijna een opera-turbo te zijn (alleen drukt hij niet op de foto's). Bij echt surfen op http duurt het ongeveer 2-3 keer (lees - als je de pech hebt van 64 kbit, dan open je megabytepagina's niet binnen twee minuten, maar binnen 40 seconden. Het is rot, maar het is nog steeds beter). Maar het belangrijkste: geen gestolen cookies of afgeluisterde sessies.

Ik zei niet voor niets over gesloten havens. Poort 22 wordt op precies dezelfde manier gesloten als de “onnodige” jabberpoort. De oplossing is om de server op poort 443 te hangen. Het is niet de moeite waard om uit 22 te verwijderen, soms zijn er systemen met DPI (deep packet inspection) die uw “pseudo-ssl” niet toestaan.

Zo ziet mijn configuratie eruit:

/etc/ssh/sshd_config:
(fragment)
Poort 22
Poort 443

En hier is een stukje ~/.ssh/config van een laptop dat vpn beschrijft

Host vpn Hostnaam desunote.ru Gebruiker vasya Compressie ja DynamicForward 127.1:8080 Poort 443

(let op de luie vorm van het schrijven van localhost - 127.1, dit is een volledig legale methode om 127.0.0.1 te schrijven)

Poort doorsturen

Om de situatie te begrijpen, verwijzen alle onderstaande voorbeelden naar dit diagram:

Opmerkingen: Twee grijze netwerken. Het eerste netwerk lijkt op een typisch kantoornetwerk (NAT), het tweede is een "gateway", dat wil zeggen een server met een witte en een grijze interface, die naar zijn eigen privénetwerk kijkt. Bij verdere redenering gaan we ervan uit dat “onze” laptop A is, en de “server” B.

Taak: We hebben een applicatie die lokaal draait, we moeten een andere gebruiker (buiten ons netwerk) toestaan ​​deze te bekijken.

Oplossing: stuur de lokale poort (127.0.0.1:80) door naar een publiek toegankelijk adres. Laten we zeggen dat onze “openbaar toegankelijke” B poort 80 heeft bezet met iets nuttigs, dus we zullen doorsturen naar een niet-standaard poort (8080).

Definitieve configuratie: verzoeken voor 8.8.8.8:8080 gaan naar localhost van laptop A.

Ssh-R 127.1:80:8.8.8.8:8080 [e-mailadres beveiligd]

Optie -R Hiermee kunt u omleiden vanaf een externe ( R emote) serverpoort naar uw eigen (lokaal).
Belangrijk: als we het adres 8.8.8.8 willen gebruiken, moeten we GatewayPorts inschakelen in de instellingen van server B.
Taak. Op server “B” luistert een bepaalde daemon (bijvoorbeeld een sql-server). Onze applicatie is niet compatibel met de server (andere bitsnelheid, besturingssysteem, kwaadaardige beheerder die limieten verbiedt en oplegt, enz.). We willen lokaal toegang krijgen tot de externe localhost.

Laatste configuratie: verzoeken aan localhost:3333 op "A" moeten worden bediend door de daemon op localhost:3128 "B".

Ssh-L 127.1:3333:127.1:3128 [e-mailadres beveiligd]

Optie -L staat lokale gesprekken toe ( L ocal) rechtstreeks naar een externe server.

Taak: Op server “B” luistert een bepaalde dienst op de grijze interface en we willen een collega (192.168.0.3) de mogelijkheid geven om naar deze applicatie te kijken.

Definitieve configuratie: verzoeken aan ons grijze IP-adres (192.168.0.2) gaan naar de grijze interface van server B.

Ssh-L 192.168.0.2:8080:10.1.1.1:80 [e-mailadres beveiligd]

Geneste tunnels

Laten we de taak ingewikkelder maken: nu willen we onze collega een applicatie laten zien die draait op localhost op een server met het adres 10.1.1.2 (op poort 80).

De oplossing is ingewikkeld:
ssh-L 192.168.0.2:8080:127.1:9999 [e-mailadres beveiligd] ssh-L 127,1:9999:127,1:80 [e-mailadres beveiligd]

Wat gebeurt er? We vertellen ssh om lokale verzoeken van ons adres om te leiden naar localhost van server B en onmiddellijk na het verbinden, starten we ssh (dat wil zeggen de ssh-client) op server B met de optie om te luisteren op localhost en verzoeken door te sturen naar server 10.1.1.2 (waar de client moet verbinding maken). Poort 9999 is willekeurig gekozen, het belangrijkste is dat deze overeenkomt bij de eerste oproep en bij de tweede.

Omgekeerde Sox-proxy

Als het vorige voorbeeld je eenvoudig en voor de hand liggend leek, probeer dan te raden wat dit voorbeeld zal doen:
ssh -D 8080 -R 127.1:8080:127.1:8080 [e-mailadres beveiligd] ssh-R 127.1:8080:127.1:8080 [e-mailadres beveiligd]

Als u een beveiligingsfunctionaris bent wiens taak het is om het gebruik van internet op server 10.1.1.2 te verbieden, dan kunt u zich beginnen de haren uit uw kont te trekken, omdat dit commando de internettoegang voor server 10.1.1.2 regelt via een sox-proxy die draait op computer “A”. Het verkeer is volledig gecodeerd en niet te onderscheiden van ander SSH-verkeer. En het uitgaande verkeer van de computer is, vanuit het oogpunt van het “192.168.0/24”-netwerk, niet te onderscheiden van het reguliere verkeer van computer A.

Tunnelen

(Helaas, ik heb dit zelf niet gebruikt).

Het is gemakkelijk te begrijpen dat het onder dergelijke omstandigheden onmogelijk is om dergelijke tunnels te vangen met enige DPI (deep packet inspection) - ssh is toegestaan ​​(lees - doe wat je wilt), of ssh is verboden (en je kunt zo'n veilig afsluiten gezelschap van idioten zonder ook maar de minste spijt te voelen).

Toestemming doorsturen

Met OpenSSH kunt u servers gebruiken als springplank om verbinding te maken met andere servers, zelfs als die servers niet worden vertrouwd en naar believen kunnen worden misbruikt.

Ik herhaal de foto:

Laten we zeggen dat we verbinding willen maken met server 10.1.1.2, die klaar is om onze sleutel te accepteren. Maar we willen het niet naar 8.8.8.8 kopiëren, omdat het een openbare tuin is en de helft van de mensen sudo heeft en door de mappen van anderen kan snuffelen. Een compromis zou zijn om een ​​“andere” ssh-sleutel te hebben die autorisatie zou verlenen [e-mailadres beveiligd] naar 10.1.1.2, maar als we niet zomaar iedereen van 8.8.8.8 naar 10.1.1.2 willen laten gaan, dan is dit geen optie (vooral omdat ze de sleutel niet alleen kunnen gebruiken, maar deze ook voor zichzelf kunnen kopiëren “voor een regenachtige dag”).

Ssh biedt de mogelijkheid om een ​​ssh-agent door te sturen (dit is een dienst die voor een sleutel om een ​​wachtwoord vraagt). Optie ssh-A stuurt autorisatie door naar een externe server.

De oproep ziet er als volgt uit:

Ssh-A [e-mailadres beveiligd] ssh [e-mailadres beveiligd]

Een externe ssh-client (op 8.8.8.8) kan aan 10.1.1.2 alleen bewijzen dat wij ons zijn als we met deze server zijn verbonden en de ssh-client toegang hebben gegeven tot zijn autorisatieagent (maar niet de sleutel!).

In de meeste gevallen werkt het.

Als de server echter volledig slecht is, kan de root van de server de socket gebruiken voor imitatie wanneer we verbonden zijn.

Er is een nog krachtigere methode: het verandert ssh in een eenvoudige pipe (in de zin van “pipe”) waarmee we met de externe server werken.

Het belangrijkste voordeel van deze methode is de volledige onafhankelijkheid van het vertrouwen van de tussenliggende server. Hij kan een nep-ssh-server gebruiken, alle bytes en alle acties loggen, alle gegevens onderscheppen en deze vervalsen zoals hij wil - de interactie vindt plaats tussen de "resulterende" server en de client. Als de gegevens van de eindserver vervalst zijn, komt de handtekening niet overeen. Als er niet met de gegevens wordt geknoeid, wordt de sessie in de beveiligde modus tot stand gebracht, zodat er niets te onderscheppen valt.

Ik kende deze coole omgeving niet, dus heb ik hem redrampage opgegraven.

De installatie is gebaseerd op twee ssh-opties: de -W-optie (die ssh in een “pipe” verandert) en de config-optie ProxyCommand(er lijkt geen opdrachtregeloptie te zijn), die zegt: "voer het programma uit en koppel het aan de stdin/out". Deze opties zijn onlangs verschenen, dus centos-gebruikers zitten in de problemen.

Het ziet er zo uit (nummers voor de afbeelding hierboven):

Ssh/config:
Host raep Hostnaam 10.1.1.2 Gebruiker user2 ProxyCommand ssh -W %h:%p [e-mailadres beveiligd]

Welnu, de verbinding is triviaal: ssh raep .

Laat me een belangrijk punt herhalen: de 8.8.8.8-server kan geen verkeer onderscheppen of spoofen, geen gebruikersautorisatieagent gebruiken of op een andere manier verkeer wijzigen. Verboden – ja, dat kan. Maar als u het toestaat, zal het via u passeren zonder decodering of wijziging. Om de configuratie te laten werken, moet u uw eigen openbare sleutel in geautoriseerde_sleutels hebben [e-mailadres beveiligd], en binnen [e-mailadres beveiligd]

Uiteraard kan de verbinding worden uitgerust met alle andere snuisterijen: port forwarding, het kopiëren van bestanden, sokkenproxy's, L2-tunnels, X-servertunneling, enz.
ssh-tunneling Tags toevoegen

In dit artikel vertellen we je hoe je SSH op Linux, Windows en Mac installeert, hoe je het configureert en hoe je het gebruikt! Elk detail! Het zal interessant zijn!

SSH is een populair protocol voor het op afstand besturen (beheer) van besturingssystemen gebaseerd op de Linux- en Unix-kernels. Voor Linux-beginners is het niet helemaal duidelijk hoe je dit protocol moet installeren, configureren en gebruiken, dus hebben we besloten dit artikel te schrijven om het probleem op te lossen!

Een van de meest populaire besturingssystemen die op de Linux-kernel draaien is Ubuntu, dus we zullen het gebruiken om uitleg te geven over ssh.

Eerst zullen we alle stappen uitleggen aan de hand van het voorbeeld van Linux, en daarna in Mac en Windows!

SSH installeren op Linux-besturingssysteem

In 99,99% van de gevallen heeft Linux al een ssh-client geïnstalleerd, waarmee je verbinding kunt maken met een externe machine. Maar als u verbinding wilt maken met de computer waarop u zich momenteel bevindt of met een andere computer, moet u “de ssh-server downloaden”.

Dit is heel gemakkelijk te doen, alles wat je nodig hebt staat al in de repositories (a la een softwarewinkel), open een terminal en voer de opdracht in:

Sudo apt install openssh-server

Dat wil zeggen: het is noodzakelijk servergedeelte, waardoor de computer via het ssh-protocol toegankelijk is op het netwerk. Eten cliënt deel, dat al op uw computer is geïnstalleerd, en als u dit gebruikt, maakt u verbinding met een externe computer.

Verbinding via SSH (met wachtwoord)

Open een terminal en voer de opdracht in om verbinding te maken met de externe machine:

Ssj Gebruikersnaam@IP-adres

Eerst schrijven we ssh, dan de gebruikersnaam die op de externe machine staat, dan het @-teken (hond) en het IP-adres. Hier is een voorbeeld:

Ssh sasha @ 100.08.30.48

In de regel vindt de ssh-verbinding plaats op poort 22; als u deze met kracht wijzigt, moet u deze opgeven. Om dit te doen, schrijft u het -p-nummer aan het einde. Hier is een voorbeeld:

Ssh sasha @ 100.08.30.48 -P 3040

Nadat u verbinding heeft gemaakt, en als dit de eerste verbinding met de machine was, moet u de machine toevoegen aan de vertrouwde machines - schrijf ja en druk op Enter. Dit wordt één keer gedaan.

Maak een SSH-sleutel aan en maak verbinding zonder wachtwoord!

Om het wachtwoord niet te onthouden en niet elke keer in te voeren, vooral als je veel Linux-servers hebt, kun je een speciale SSH-sleutel aanmaken. Met deze sleutel kunt u verbinding maken vanaf een reeds “bekende” machine met een “bekende” server, zonder een wachtwoord te gebruiken.

Hoe maak je een SSH-sleutel aan?

We zullen een sleutel aanmaken op de computer die u momenteel gebruikt, en dan moet u deze naar onze server kopiëren!

Maak een sleutel voor de huidige computer:

Ssh-keygen -t rsa

De sleutel is aangemaakt, nu moet je deze toevoegen aan de externe machine of server.

Hoe voeg ik een SSH-sleutel toe aan de server?

Om dit te doen, voert u de opdracht in:

Ssh-copy-id sasha @ 100.08.30.48

U heeft nu de mogelijkheid om verbinding te maken met een server of andere machine zonder een sleutel te gebruiken, simpelweg door uw gebruikersnaam en wachtwoord in te voeren!

Windows SSH-client

Een van de meest populaire programma's voor het werken met Linux-servers via SSH op Windows is het programma Putty. U kunt deze Windows SSH-client downloaden op dit adres - putty.org.

Verbinding maken via SSH met een wachtwoord in Windows

Verbinding maken met Putty via SSH is heel eenvoudig! Voer het IP-adres in als u de poort hebt gewijzigd, geef vervolgens een andere poort op en klik op Openen:
en na het verbinden, login en wachtwoord!

Verbinding maken via SSH met behulp van een sleutel in Windows

Als je niet elke keer een wachtwoord wilt invoeren, maar in Putty een ssh-sleutel wilt gebruiken, dan moet je, net als in Linux, eerst een sleutel aanmaken en deze vervolgens naar de server overbrengen.

Maak een sleutel

Sluit het programma nog niet en voer Putty uit om verbinding te maken

Een sleutel overdragen

Mac SSH-client

Omdat macOS gebaseerd is op een UNIX-systeem, kun je rechtstreeks vanaf de terminal verbinding maken via ssh!

Als u geen wachtwoord wilt gebruiken, moet u eerst Homebrew installeren:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Er is ook een handige mac ssh-client - Termius.

SSH-client voor Android en iOS

De handigste SSH-client voor iOS en Android is de Termius-applicatie!

Bestanden overbrengen en downloaden via SSH (SCP)

Om een ​​bestand van uw lokale machine naar de server te uploaden via ssh in Linux en macOS:

Scp-bestand1.tar root@ip_adres:/home/dir

Kopieer een bestand van de server naar uw lokale Linux- of macOS-computer:

Scp-gebruikersnaam@ip_adres:/home/file1.tar /var/www/

Van server naar server:

Scp-gebruiker@server_ip1:/home/bestand.txt gebruiker@server_ip2:/home/

Voor Windows

Om bestanden via SSH op Windows te verplaatsen, wordt pscp gebruikt.

pscp.exe bestand.zip root@ip_server: /var/www/

SSH instellen

Als u een SSH-login rechtstreeks als root moet toevoegen:

De SSH-poort wijzigen

Omdat ssh standaard op poort 22 is geconfigureerd, wordt het onveilig om de server te gebruiken. Daarom is het de moeite waard om de poort te veranderen!

en wijzig de poortwaarden in de vereiste waarden:

# Welke poorten, IP's en protocollen we luisteren naar poort 22

Alleen inloggen met de SSH-sleutel:

Bewerk met behulp van nano het sshd_config-document en voer de opdracht in:

Sudo nano /etc/ssh/sshd_config

Wijzig de WachtwoordAuthenticatie-waarden van ja in nee:

RSAAuthenticatie ja PubkeyAuthenticatie ja WachtwoordAuthenticatie nee

Heeft u nog vragen? Schrijf ze in de reacties, vertel ons wat je hebt gedaan of andersom!

Dat is het! Lees meer nuttige artikelen en instructies in de sectie. Blijf op de site, het wordt nog interessanter!

Dit wordt een serie artikelen over het installeren en configureren van een eenvoudige server voor een team van webontwikkelaars. De server heeft Git, FTP, SSH, Apache 2, PHP 5.4, MySQL, cron, subdomeinen, memcached, Composer. De artikelen zijn van toepassing op Ubuntu 14.04. Ik geloof dat de server voor zakelijke doeleinden zal worden gebruikt, en niet voor eindprojecten. Hoewel, als het toegestaan ​​is dat een project zich op een ontwikkelserver bevindt, waarom dan niet...

Ik maak meteen een reservering. Ik heb niet genoeg ervaring met serverbeheer en ik doe het niet professioneel, dus ik kan niet garanderen dat de hieronder beschreven acties 100% correct zijn. De instructies zijn een herinnering voor het snel inzetten van een server die aan mijn behoeften voldoet. Als je een voor de hand liggende fout ziet of "dit hoort niet in de productie te gebeuren" (hoewel ik heb bepaald dat projecten niet op de dev-server mogen worden bewaard), dan zou ik het op prijs stellen als je de juiste oplossing in de reacties beschrijft.

Er wordt van uitgegaan dat Ubuntu 14.04 al op de server is geïnstalleerd (bijvoorbeeld op een VPS/VDS) en dat je toegang hebt tot de rootconsole.

1. Gebruikers en SSH

Laten we beginnen.

Servergebruikers

Eerst een korte lijst met opdrachten voor het werken met gebruikers.

Voeg een nieuwe gebruiker toe

Gebruiker verwijderen

Wachtwoord wijzigen

Log in als gebruiker

Terug naar de root:

Wijzig de thuismap

Stel de eigenaar en groep van een map in (en de volledige inhoud ervan)

Laten we beslissen over gebruikers

• mygit - om te demonstreren hoe je met Git-repository's kunt werken;
• myftp - om te demonstreren hoe u met FTP kunt werken;
• myssh - om te demonstreren hoe u met SSH kunt werken.

Als het duidelijk is met myssh, dan is op het eerste gezicht SSH-toegang tot mygit en vooral myftp niet nodig. U kunt de toegang tot SSH aan specifieke gebruikers weigeren (of alleen bepaalde gebruikers toestaan). /etc/ssh/sshd_config maar mygit gebruikt SSH voor Git-autorisatie. Daarom zullen we vervolgens een andere methode overwegen die geen SSH-reboot vereist en die je enerzijds geen toegang geeft tot de console via SSH mygit, maar je anderzijds SSH laat gebruiken om met Git te werken.

SSH

Voorbereiding

Installatie van OpenSSH-client en server wordt uitgevoerd met het commando:

Apt-get installeer ssh

Configuratie

Gebruik de mcedit-editor (of nano, in het geval van mcedit moet u eerst mc installeren) om het bestand te openen /etc/ssh/sshd_config:

Mcedit /etc/ssh/sshd_config

Controleer of de volgende parameter de opgegeven waarde heeft:

VergunningLeegWachtwoorden nr

Hier kunt u een andere poort voor SSH opgeven, maar in dit geval zal het verbindingscommando er als volgt uit moeten zien als u vervolgens verbinding maakt via clients:

Ssj -p POORT inloggen@server

U kunt de SSH-server opnieuw opstarten met het commando:

Service ssh opnieuw opstarten

Klanten

Voor gebruikers die via SSH of Git (via SSH) verbinding maken met de server, moet een SSH-client zijn geïnstalleerd en moeten er sleutels zijn gegenereerd. U kunt controleren of de sleutel is gegenereerd door de aanwezigheid van het bestand ~/.ssh/id_rsa.pub. Als het ontbreekt, moet u het bijvoorbeeld genereren met behulp van de volgende opdracht:

Ssh-keygen -t rsa -C "e-mail@server"

U hoeft geen wachtwoord in te stellen.

Voeg vervolgens de sleutel toe aan ssh-agent:

Ssh-voeg ~/.ssh/id_rsa toe

Autorisatie via sleutel

Om te voorkomen dat je elke keer dat je verbinding maakt met SSH en Git een wachtwoord moet invoeren (het werkt ook via SSH), moet je een bestand aanmaken ~/.ssh/geautoriseerde_sleutels die gebruikers op de server, waarmee verbindingen worden gemaakt.

Let op: om de .ssh-map (als die er niet is) en het geautoriseerde_sleutels-bestand te maken, moet u geautoriseerd zijn onder dezelfde gebruiker in wiens thuismap de acties worden uitgevoerd. Of stel vervolgens de juiste rechten, groep en eigenaar in. Wanneer u in de toekomst het bestand geautoriseerde_sleutels wijzigt, moet u hier ook rekening mee houden.

In dit bestand moet elke regel de inhoud van de publieke sleutel bevatten ( ~/.ssh/id_rsa.pub) klanten van deze gebruiker. Aan het einde van het bestand geautoriseerde_sleutels moet een lege regel staan.

Met andere woorden, als we server_user_1 hebben, waartoe via ssh toegang zal worden verkregen door clients client_user_1 en client_user_2, dan zou in de homedirectory van de gebruiker server_user_1 het bestand ~/.ssh/authorized_keys drie regels moeten hebben:

Inhoud van id_rsa.pub client_user_1 inhoud van id_rsa.pub client_user_2 (lege tekenreeks)

Hallo! Ik ben geïnteresseerd in de vraag: hoe maak je via SSH verbinding met je thuiscomputer via internet. Ik heb thuis een FreeSSHd-server geïnstalleerd. Zoals ik het begrijp, moet ik op de een of andere manier poort 22 op het externe IP-adres openen, Alex

Ja, de behoefte komt vaak voor. Ik heb in dat artikel over veel dingen gesproken, maar hier zullen we het uitsluitend over SSH hebben, aangezien Alex ons zo vriendelijk was deze mogelijkheid te bieden. Bovendien ben ik zelf ontzettend geïnteresseerd in SSH, en hier is het ook op Windows... mmm.

Wat is SSH en waarom is het nodig?

Het punt is dat SSH dat is S zeker SCH el. Protocol voor veilige toegang tot de besturingshell. Daarom biedt het specifiek toegang tot de opdrachtregel, omdat Shell wordt vertaald als schelp en hier in de betekenis tekstbesturingsshell. Maar over het algemeen valt dit protocol op vanwege het feit dat het al het andere verkeer erin toestaat, en wel in gecodeerde vorm. Het beveiligde verbindingsprotocol voor het bestandssysteem wordt dus SFTP genoemd en draait bovenop SSH. Maar het kan absoluut alle andere verbindingen tunnelen, of het nu HTTP of zelfs RDP is. In essentie blijkt het een “VPN op de knie” te zijn.

Hier heeft Alex al de helft van het werk gedaan dat hij FreeSSHd op zijn thuiscomputer heeft geïnstalleerd en gestart. Hierdoor kun je via SSH verbinding maken met Windows. In dit geval wordt heel sterk ‘toegestaan’ gezegd. Omdat deze oplossing op de een of andere manier op Windows werkt. Ten eerste heeft het geen fatsoenlijke tekstinterface: een opdrachtregel voor bediening.

Met de gewone cmd kun je in ieder geval weinig doen met de externe machine. Er is ook Powershell - dit is een modernere en krachtigere oplossing. Met Freesshd kun je de console wijzigen in powershell, maar ik kon er geen verbinding mee maken. Ik heb verbinding gemaakt met CMD - maar het is volledig onbruikbaar:

Ten tweede kon ik in het geval van FreeSSHd geen verbinding maken met een Windows-computer, zelfs niet via een lokaal netwerk, om nog maar te zwijgen van de verbinding via internet. Of beter gezegd, het is mogelijk om verbinding te maken, maar de service loopt vast en crasht; je kunt de Windows-host niet op deze manier beheren.

Daarom neem ik aan dat Alex een ssh-server op Windows nodig had om verbinding te maken met het bestandssysteem of om het als VPN te gebruiken, waarbij iets via SSH werd geproxyd. Hoewel ik betwijfel of FreeSSHd dit zal toestaan. Omdat ten derde: het slaat de instellingen niet eens op als de service opnieuw wordt opgestart, alles gaat verloren. Over het algemeen hoop ik echt dat Alex ons in de reacties zal vertellen waarom hij dit nodig had.

Hoe kun je anders SSH op Windows uitvoeren?

Er is een meer werkbare oplossing: Powershelserver. Hoewel het ook bugs bevat, crasht het tenminste niet. Daarom zou ik aanraden om het te gebruiken om via SSH verbinding te maken met Windows-servers.

Ten eerste werkt het stabiel zonder crashes. En hierdoor kun je vensters echt bedienen via powershell.

Alle instellingen worden normaal opgeslagen. Dezelfde functies zijn beschikbaar als in FreeSSHd en zelfs meer - u kunt SCP gebruiken - dit is het kopiëren van bestanden via SSH.

Maar het meest chique is de console! Het werkt, heren!

Ik maakte eenvoudig verbinding, zonder gedoe met het toevoegen van gebruikers (dit moet in freesshd worden gedaan). En dat simpele commando om de routeringstabel te bekijken werkte perfect en leverde de nodige informatie op. Frisssh “viel” precies voor mij toen ik netstat -rn probeerde te bekijken

Hier kun je echt zien dat Russische karakters niet worden weergegeven. Het is dus gemakkelijk bij ons in te stellen. Ik stel gewoon de codering in die ik nodig heb op de powershellserver, start opnieuw op, maak opnieuw verbinding...

Codering instellen in Powershellserver

Nu hebben we volledige SSH en kunnen we Windows volledig beheren via de console.

Microsoft gaat zijn eigen SSH-oplossing creëren

Overigens maakte Microsoft in de zomer al bekend dat het ging ontwikkelen oorspronkelijk SSH-ondersteuning voor Powershell in nieuwe versies van Windows. Er zijn nieuwsaankondigingen op Habré en op pcweek (en meer). Daarom kunnen we alleen maar uitkijken naar dit mijlpaalevenement, aangezien het werkelijk een doorbraak zal zijn voor het werk in heterogene netwerken.

Ik heb de andere functies - sftp en scp - niet gecontroleerd, maar om de een of andere reden weet ik zeker dat ze ook prima zullen werken.

Hoe open ik een SSH-poort van buitenaf?

We zijn dus bij het geheime punt gekomen waarvoor dit artikel in de eerste plaats is begonnen. Ik zal de vraag van de lezer beantwoorden.

Port forwarding op een router of modem

Om van buitenaf verbinding te maken met een computer, moet u echt NAT gebruiken, of, in een specifiek geval, . Hoe u dit doet, is afhankelijk van het apparaat dat als gateway wordt gebruikt. Dit kan een ADSL-modem of . In de meeste gevallen kunnen gedetailleerde instructies voor uw apparaat eenvoudig worden gevonden met zoekopdrachten als 'port forwarding' apparaat_model" of "poort doorsturen apparaat_model»

Zo ziet het eruit op mijn Zyxel Keenetic Lite-thuisrouter:

En zo ziet het eruit op een ADSL-modem met de functionaliteit van de Linksys WAG200G-router bij de hand:

Bovendien is dit bij sommige providers misschien technisch niet mogelijk omdat ze geen "wit" aanbieden.

Een poort doorsturen naar een externe server met behulp van een SSH-tunnel

In dit geval is de enige beschikbare manier om verbinding te maken via SSH vanaf een lokale Windows-machine (dezelfde waarmee we via SSH verbinding willen maken) met een externe server. In dit geval moet u SSH-toegang hebben tot een bepaalde server op internet.

Een omgekeerde SSH-tunnel opzetten

Dit doorsturen kan eenvoudig worden gedaan met behulp van een eenvoudige SSH-client Putty (die is er ook). Vervolgens kunt u via de doorgestuurde poort verbinding maken met deze zeer externe server.

Als u de Windows SSH-poort met de wereld wilt delen, volstaat het om ip_server:3322 als bestemming op te geven in de omgekeerde tunnelinstellingen. U kunt via SSH verbinding maken met Windows vanaf elke plek waar toegang is tot deze server.

Hoe controleer ik of de poort correct is doorgestuurd?

Heel eenvoudig. U moet controleren of deze open is. In het geval van SSH reageert de open poort met een bericht over de versie ervan. De eenvoudigste manier om een ​​poort te controleren is het telnet-hulpprogramma.

Typ gewoon op de opdrachtregel, gescheiden door spaties:

telnet domein_of_IP-poort

Als de poort beschikbaar is, ziet u zoiets als dit:

SSH-antwoord als poort beschikbaar is

Als de poort om wat voor reden dan ook niet beschikbaar is, ziet u 'verbinding geweigerd' of 'verbindingstime-out'. In het eerste geval zal dit onmiddellijk gebeuren en betekent dit dat de poort wordt afgesloten door een firewall.

In het tweede geval ziet het eruit als een “vastlopen” en kan het enkele minuten duren - de telnet-client zal proberen een verbinding tot stand te brengen. Dit kan ook een blokkering door een firewall betekenen, maar dan van een ander type. Ofwel simpelweg dat de opgegeven host niet beschikbaar is, ofwel dat de poort daarop gesloten is.

Als u verbinding kon maken via telnet, drukt u op de toetsencombinatie Ctrl+] en voert u in ontslag nemen, en voer vervolgens in. Anders kunt u de sessie niet onderbreken en moet u een nieuw consolevenster openen als u dit nog steeds nodig heeft.