SSH samozřejmě není nová technologie, ale pro Windows nemá moc smysl, tam jsou k dispozici jiné nástroje. Osobně je hodnotím jako modernější, ale mají taky své nevýhody.
SSH klíč bez hesla, když stejně ještě potřebujete heslo k eskalaci práv, není úplný bezpečnostní průšvih. Rozumný admin stejně nevystrčí SSH do světa v beta fázi, maximálně v rámci VPN.
Asi bych betě odpustil, že má omezení, že se třeba této části prostě zatím nevěnovali a zaměřili se na něco jiného.
Problém je že ak sa kvôli nejakej M$ zraniteľnosti dostanú kľúče mimo tak sa dajú hneď použiť.. nato tam je to heslo.. takže žiadne heslo admina tomu nepomôže..
Alebo si niekto pripojí daný disk do iného systému a kľúče si skopíruje ..
Takže tu zrejme niekto v M$ dosť nerozumie bezpečnosti.. tak im treba.
Ale samozrejme, kedze z pohladu typickeho Windows usera je masina viac-menej pouzitelna len lokalne, alebo z inej desktopom ovencenej masiny na ktorej je mozne si desktop inkriminovanej masiny remotne zobrazit, tak SSH ako take pre bezneho pouzivatela windowsu moc zmysel nema. Vzdialeny pristup sa v tych ekosystemoch pouziva len na manazment alebo hasenie problemov aj to len cez specializovane API, ktore ma nahodou PowerShelli connector, takze sa tam nemusi liezt cez GUIkovu aplikaciu, ale da sa to oskriptit.
To nikomu neberiem, ze PowerShell je asi celkom uzitocny ako nastroj na vzdialenu spravu masin. Sice som ho (takto) nikdy nepouzival, ale asi to takto funguje.
Tu skor ide o to, co je mimo krabicku beznych widlich userov. Bezni widli useri (programatori a podobna haved) neautomatizuju a neskriptuju. Pretoze nic okrem manazmentu masiny sa oskriptit neda. A tym padom, ze veci oskriptit nejde (sic!) nie je treba ani SSH, lebo co by na nom clovek spustal, co uz dnes nemoze spustat na PowerShelli? No predsa nic. A co nema GUIko a zaroven nie je servisom, to nebezi.
Ale tento moj postoj sa zle chape zvnutra krabicky.
A kedze neexistencia headless workflowov brani tomu aby sa openssh pouzivalo a nepouzivanie openssh brani tomu, aby sa rozsirili headless workflowy prajem celemu windowsu aby jeho popol tlel dlho.
Slyšel jste někdy o Windows Nano Server. Slyšel jste o možnosti nainstalovat windows server (no v podstatě i win10) za použití serial konzole. mimochodem často pouzivane v FreeBSD bhyve... mimochodem řekněte mě, co neni možné skriprovat pomocí powershell... já osobně používám powershell pro kompletni správu a procesovani OLAP kostek, ke spouštění report subscriprions pomocí soap api ssrs, backupy, atd...
Powershell v Linuxu ale už dávno je a dokonce i funguje, viz - https://github.com/PowerShell/PowerShell
No myslel jsem i tam ještě tu parodii na Bash ... a nakonec člověk udělá nejlépe, když si stáhne nějakou od třetí strany, kterou někdo stvoří, protože už chudák nemůže dál jinak. Naštěstí v tom dělám jenom pár desítek úkonů denně ... ale komédie to teda je. Nechal bych to být, ale vždycky když na adresu windows někde slyším ty kecy o vymoženostech, 21. stol. a technologickém náskoku, tak by jeden zvracel ... Možná jsem měl jenom tu smůlu, že jsem několik let vyvýjel linux only a teď jsem rok na widlích. To se pak člověk nestačí divit, co se dá všemožně kdemožně spáchat za zločiny proti lidstvu (vzhledem k rozšířenosti) :-)
To mi připomnělo kolegu, který leta administroval jen Linux a pak dostal i MS Windows Server 2012. Použil powershell.
Výborný byl jeho komentář: "Tak začnu klasika, hledám náhrady za to, co znám, a nenacházím. Oni to dělají nějak divně jinak. Hledám rovnáky na ohýbáky a co čert nechtěl, oni tam nemaji ani rovnáky ani ohýbáky!"
Už to dělá déle než dva roky a powershell si pochvaluje natolik, že ho používá i na Linuxu (Oracle Linux). Protože co potřebuje to to umí a na obou OS to funguje víceméně stejně (na Linux není powershell, ale "jen" powershell core). Windows nemusí doteď, jen ten powershell považuje za překvapivě dobrý nástroj.
Samozřejmě. Když děláš věci které Powershell umí, tak se není čemu divit, že se to v powershellu dělá dobře ...
Ale jo, místo $ tail -f my.log psát > $ Get-Content -Path "C:\a\b\c\d\e\f\my.log" -Wait protože v Potěmkinově WSL se seká a bez enteru se pak ani nehne, to je fakt výhra. Že tu vymoženost ještě na serveru nemám ...
Ale sranda teprve začíná, pokud máš nějaké exe verze programů které ti jedou i na serverech, WSL se hroutí a potřebuješ je na widlích v konzolích (třeba na shell scripty a commandy např. nějaké testy apod), nebo paralelní práci. Na linuxu local? No problem. Widle? Přeji příjemnou zábavu ...
Jenže vy přenášíte linuxovou (obecně unixovou) filozofii a srovnáváte ji s použitelností na Windows. Na Windows se pracuje docela odlišně, úkony, které na Linuxu považujete za kruciální, ve Windows v praxi ani nepotkáte. Oni zas takoví pitomci nejsou, jen Vám se nechce používat ten systém tak, jak byl navržený.
Opačně by to platilo stejně, kdybych vypíchl příklady použití na Windows serverech, které jsou velmi jednoduché přes powershell, ale v Linuxu se opupínkujete.
Každý z těch systémů je o něčem jiném, ale nejde říct, že by powershell byl špatný; a nejde to říct ani o bashi nebo o tcsh.
@Miroslav Šilhavý
tak napr. aktualizace systemu se ve Windows dela ne? ;-)
v GNU/Linux Debian: apt update && apt upgrade
jak to udelas v PowerShellu? ja na to vidim sadu PowerShell scriptu co maji ~280000 znaku ;-)
https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc
ja mam treba virtual, v nem W7, a mam automatizovane ze ze strany GNU/Linuxu nahraju do virt image script do po spusteni, pustim virtual, nabehne, zkontroluje aktualizace, pokud jsou tak se nainstalujou a system se restartuje a znovu zkousi hned vyhledat (a nainstalovat), pokud nejsou tak se virtual vypne, na strane GNU/Linuxu pokracuju tim ze celej virt disk stahnu do WIM, a vytvorim instalacni DVD W7 co obsahuje jiz nainstalovane aktualizace...
tenhle postup se tezko dela tvojim "nejak rucne tuknu, nebo ono se to nejak samo nekdy udela"
chapu ze mas "pravnickou namyslenost" ktera se promita do vseho co napises a asi i na co pomyslis, ale okecavat hovadinama to ze neco nemaji Windows snadno a to fuckci ktera je normalni a nejaka uchylarna, kdy navic pro WindowsStore aplikace ta podpora z shellu pro aktualizace/instalace je... no je to proste tva uchylna uchylka a snad se take bavis, protoze pro ostatni ses k smichu ;-)
dokážeš být konkrétnější? Ne, že bych ti nevěřil a chtěl důkaz, ale zarazila mě ta jistota. Nevíš jaký OS používá, jaký prohlížeč používá a společných částí napříč prohlížeči a OS zase tolik není.
Napadá mě jediné vysvětlení, programuješ v javascriptu a na rootu se tvoje scripty používají, ale pohledem jich zase není tolik a ty sdílené knihovny mají mnoho autorů, těžko si budeš připisovat zásluhy za tým.
Kdyby ještě MS implementoval aliasy na běžné linuksové programy (ls, tr, cat, head, tail, cut, find, grep, vim) a zařídil, aby se po spuštění grafickýho programu nezahazoval jeho výstup na stdout, tak už by stačilo dodat tomu bash-like shell a rozumný balíčkovací SW a budu možná považovat Windows za operační systém.
Ako chápem to rozčarovanie z toho, že ti to vo Windows nejde, ale zamyslime sa, či to predsa nie je len trochu prasačina ktorá sa na unixoch robí "lebo to ide". Pre nejakú konzistenciu dát bežiacej aplikácie je to priam balzam...
Už chápem vetu, ktorou si chalani z tímu supportujúceho SAP robili srandu z unixákov: "Operačný systém je na to, aby bežal."
Kdybys necet jen root tak bys vedel ze unix utils jsou tu snad uz od win2000
https://www.microsoft.com/en-us/download/details.aspx?id=2391
A na lepsi balickovani je Chocolatey
https://chocolatey.org/
První otázka zní, proč to dělat. Tím uděláte akorát paseku v prostředí a můžete do budoucna způsobit nějaké nepředpokládané chování. Pokud to přesto chcete udělat, potom spusťte powershell s eskalovanými oprávněními.
Balíčky vylistujete např.: Get-AppxPackage *xbox*
A všechny tyto smažete: Get-AppxPackage *xbox* | Remove-AppxPackage
Tak v mem pripade pokus o odmazani *xbox* dopadne nasledovne (spusteno jako administrator):
PS C:\WINDOWS\system32> PowerShell -Command "Get-AppxPackage *Xbox*|Remove-AppxPackage"
Remove-AppxPackage : Deployment failed with HRESULT: 0x80073CFA, Odebrání se nezdařilo. Obraťte se na dodavatele softwa
ru. (Výjimka na základě hodnoty HRESULT: 0x80073CFA)
error 0x80070032: AppX Deployment Remove operation on package Microsoft.XboxGameCallableUI_1000.16299.15.0_neutral_neut
ral_cw5n1h2txyewy from: C:\Windows\SystemApps\Microsoft.XboxGameCallableUI_cw5n1h2txyewy failed. This app is part of Wi
ndows and cannot be uninstalled on a per-user basis. An administrator can attempt to remove the app from the computer u
sing Turn Windows Features on or off. However, it may not be possible to uninstall the app.
NOTE: For additional information, look for [ActivityId] 2c7fc183-9f4a-0008-23e0-7f2c4a9fd301 in the Event Log or use th
e command line Get-AppxLog -ActivityID 2c7fc183-9f4a-0008-23e0-7f2c4a9fd301
At line:1 char:24
+ Get-AppxPackage *Xbox*|Remove-AppxPackage
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : WriteError: (Microsoft.XboxG...l_cw5n1h2txyewy:String) [Remove-AppxPackage], IOException
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.RemoveAppxPackageCommand
Chocolatey vypada dobre, nekdy to na widlich zkusim. Jestli mi kazdej druhej soft po startu nebude nutit aktualizace, poustet si "CompanyAutoUpdaterTray.exe" a jestli to umi nejak nakladat s knihovnama a tedy se nebude SW stahovat ve forme 20MB software + 100MB knihovny, ktery pouziva uz jinej software, tak by to byl paradni luxus :)
ta vetsina uzivatelu popisuje realne duvody proc je to spatne, z realnych zkusenosti s windows...
narozdil od vetsiny tech co Windows vychvalujou s nima maji mnohem vetsi zkusenosti...
ten kdo hejtuje, jsou v naproste vetsine ti co nadavaji na GNU/Linux, vetsinou s nim maji velmi male ci zadne zkusenosti...
kdyz nevidis ten rozdil ses slepej, vedome ci nevedome...
> Zapomnel jsem na jedno - mely by widle nejak rozumne
> nakladat s drivery. Nemyslim si, ze je nutne "instalovat
> ovladace" pro vsechny mozny kombinace UMS, HID zarizeni
> a konkretniho USB portu - a uz vubec neni nutne, abych na to
> obcas cekal treba i minutu nebo dele.
Termín "instalace" je zde nepřesný, resp. neznamená to, že by systém nutně lezl např. na Windows Update, aby nalezl vhodný ovladač pro dané zařízení a provedl jeho instalaci podle přiloženého INF souboru. Obvykle (zejména u HID, USB a podobných zařízení, se kterými si poradí obecný ovladač od MS) se prohledávají již nainstalované ovladače podle hardware ID zařízení, popř. dalších kriterií.
> To nebylo pointou meho prispevku. Prohledat drivery a
> "nasadit" prislusny modul je nutne i u Linuxu. Akorat
> flashka/mys pripojena do linuxu mi vetsinou funguje za par
> stovek milisekund, na widlich v radu sekund az minut.
Při prvním připojení daného zařízení to obvykle pár vteřin trvá, protože se sice zařízení stejného typu (např. flashky) shodují v některém z hardware ID či compatible ID (nepamatuji si, jaká je to přesně kategorie), ale to se v seznamu ID nachází hodně vzadu (jako jedno s posledních). Mezi prvními jsou ID udávající číslo výrobce (VID), produktu (PID) a jeho verzi (REV), takže je snaha matchovat nejprve proti těmto ID.
Proto první připojení chvíli trvá (pár vteřin). Minuty už jsou divné, to by se asi chtělo během toho připojování podívat třeba do eventlogu (případně celý proces sledovat v Device Manageru, pozorovat změny stromu a stavů zařízení).
Jo, a na linuxu se to matchuje telepaticky, a proto to netrva. O takovych krasach jako ze kdyz se clovek splete, a ten USBckovej seriak prehodi jinam, tak ma i dalsi COM s jinym cislem === prestane vsechno fungovat, ani nemluve. Ze by to aspon pridelilo to samy pri navratu zpatky ... lol. Takze beznej widlostav pak je takovej, ze widle maji nainstalovany 20x com a nefunguje ani jeden.
Přesně tak. Třeba kolegovi s USB diagnostikou:
"Tady mi to hlásí, že nemám připojenou diagnostiku!"
"Hele, Dejve a neměl si to minule strčený o port vedle?"
"Máš recht, protože teď jsem to tam strčil zpátky a najednou už to zase funguje. To jsou mi teda věci..."
"Tak to strč tam, kde si to měl původně, ať víme, že to neni jenom divnej HW."
"Mám a už to zase nejede."
"A teď zas do toho portu, kde ti to před chvílí fungovalo."
"Je to tam a v pohodě."
"Tak si ten port označ lihovkou a strkej to tam vždycky, protože přesně tohle už jsem zažil nevim kolikrát."
Ale Lael a spol. nám určitě hned vysvětlí, že to přece vůbec neni možný, protože MS už má tohle léta zmáknutý a vždycky jim to všechno perfektně funguje.
> Ale Lael a spol. nám určitě hned vysvětlí, že to přece vůbec
> neni možný, protože MS už má tohle léta zmáknutý a vždycky
> jim to všechno perfektně funguje.
Možné to samozřejmě je. Například implementace u obecného ovladače disku je taková, že pro každý nalezený disk vytvoří symbolický link \DosDevices\PhysicalDriveX, kde X je z intervalu <0,255>. Interně je toto číslování řešeno jednou proměnnou, která se po vytvoření nového diskového zařízení prostě inkrementuje. Nevím, jak je v tomto ohledu implementován třeba ovladač sériového portu, ale nečekal bych velký rozdíl.
V MSDN se ale dá najít, že tyto názvy (jedná se přímo o názvy objektů zařízení) nejsou persistentní. Místo nich by měly aplikace využívat mechanismus notifikací o připojení zařízení hledaných typů (funkce RegisterDeviceNotification v uživatelském režimu, IoRegisterPlugPlayNotification pro ovladače). Je ale pravda, že v rámci notifikace je jméno zařízení reportováno jako celkem nevzhledný řetězec; rozhodně ne ve smyslu COM10.
Cílem je nebýt závislý na konkrétních jménech objektů zařízení či symbolických linků (vyjma možnosti dát ostatním vědět, že určité zařízení disponuje např. rozhraním disku či sériového portu). Rozhodně to ale není kompatibilní s tím, jak se s takovými zařízeními pracuje jinde... a ani dotažené k dokonalosti (pokud si např. uděláte vlastní obdobu obecného ovladače disku pro svojí verzi virtuálních disků, musíte určité symbolické linky ručně vytvořit, jinak máte zaděláno na problém třeba ve Správci disků ne že by vlastní obecný ovladač disku (i pro specifické použití) byl doporučený postup).
USB se takhle nechová, tam se předává nějaké device ID. COM se takhle chová - každý port má vlastní fixní číslo - UART protokol nemá jak poznat, co se vlastně připojilo, takže těžko bude fungovat stylem "já, to je ta kamera, tak to bude COM4". Co fyzický port to jiné COM číslo.
Co to celé zhorší, je virtuální COM po USB kabelu (všechna ta Arduina apod.) USB ovladač zjistí, že se mu připojilo něco, co chce komunikovat po COM. Tak si od Windows nechá vygenerovat číslo virtuálního COM portu a na tom pak funguje. Když to zařízení pak připojíte do jiného USB portu, tak se generuje nové číslo COM portu. Problém je, že občas si to prostě nechá vygenerovat nové i na tom samém portu a to se pak divíte, že ještě včera to na COM11 normálně komunikovalo a dneska to sedí na COM7.
U nás jsme to chvíli řešili tím, že jsme přímo pro daný USB port nastavovali fixní číslo COM portu. Takže to nebylo náhodné a pamatovalo si to. Jenže i tak byl problém když to někdo připojil do jiného USB portu. Sice jsme nakonec skončili u toho, že jsme do PC na linkách nakoupili karty s COM porty a jedeme "nativně", ale i tak se občas stane, že technik prohodí kabely od barcode readeru a kamery a pak se diví, že "to nečte".
Unix je operačním systémem už dobrých 50 let, jeden z prvních, které se tak dal nazývat a doteď platí jeho ochranná známka. V současné době již ale jako samostatných operační systém prakticky neexistuje a žijí jeho následovníci. Je starší než celý Microsoft.
Dři si kolik uší chceš, považuješ co chceš za co chceš, ale realitu nezměníš, klidně si ale vytvoř svoji.