Archiv der Kategorie: English

Blog entries in english

Flexibles Replace dank MatchEvaluator

Eine simple Anforderung soll (unbedingt;) per Regex gelöst werden: Der Ersatz einer Umgebungsvariablen in der alten Schreibweise aus einer Pfadangabe.

Beispiel:

Aus einem %temp%\test123 soll %temp% durch den Pfad des temp-Verzeichns im Benutzerprofil ersetzt werden.

Das Problem: Der Replace-Operator ermöglicht keine Ausdrücke in dem Einsetzwert.

Der folgende Befehl ersetzt lediglich %temp% durch temp:

"%temp%\test1234.dat" -replace "%(\w+)%", '$1'

Statt „temp“ soll z.B. [Environment]::GetEnvironment(Variable($1) eingesetzt werden.

Auch wenn ich einiges ausprobiert hatte, der zweite Wert darf nur aus $1, $S2 usw. bestehen. Ein Ausdruck, bei dem $1 als Operand vorkommt, ist nicht erlaubt.

Zum Glück gibt es eine flexible Alternative. Diese besteht darin, die statische Replace-Methode der Regex-Klasse zu verwenden beim Aufruf einen MatchEvaluator zu übergeben, der bei der PowerShell lediglich aus einem ScriptBlock besteht, dem der Match als Parameterwert übergeben wird:

$t = "%temp%\Test1234.dat" $m = "%(\w+)%" $MatchEval = { param($match) [Environment]::GetEnvironmentVariable($match.groups[1].value) } [Regex]::Replace($t, $m, $MatchEval)

Tipp des Tages: Probleme mit der PowerShell Gallery – TLS 1.0 ist Schuld

Seit ein paar Monate habe ich „Probleme“ mit der PowerShell Gallery. Insbesondere ein Install-Module führte zu seltsamen Fehlermeldungen. Da ich eigentlich nur selten Module benötige, habe ich es nicht weiterverfolgt. Als dann aber die Installation des neuen PowerShellGet-Moduls einfach nicht möglich war und es so aussah, als wäre die PowerShell Gallery nicht nur sporadisch, sondern dauerhaft nicht mehr erreichbar, habe ich mich dann doch auf die Suche der Ursache begeben. die dann auch schnell gefunden war. Es lag offenbar wirklich daran, dass ich auf älteren Windows-Versionen immer noch TLS 1.0 verwende, der Microsoft-Server inzwischen aber TLS 1.2 erwartet.

Abhilfe schafft ein einfacher Aufruf, der als Standardprotokoll TLS 1.2 festlegt:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Danach funktionierte alles wie erwartet.

Fündig wurde ich in einem sehr guten Blockeintrag, bei dem sich der Autor deutlichmehr Mühe gemacht hatte als ich:

PowerShell-Remoting mit Localhost – Access Denied?

PowerShell Remoting ist alles andere als ein neues Thema und die Zeiten, in denen man die Troubleshooting-FAQs vorwärts und rückwärts lesen musste liegen schon ein paar Jahre zurück. Es funktioniert, sofern man es überhaupt benötigt.

Vor kurzem hatte ich wieder einen Fall, dass ein Invoke-Command mit Localhost auf einem Win10-PC einfach nicht funktionieren wollte (der TrustedHosts-Eintrag war natürlich gesetzt). Ich muss zugegeben, dass ich ohne Tante Google nicht so schnell (wenn überhaupt) darauf gekommen werden. Es lag wieder einmal an der LocalAccountTokenFilterPolicy, für die Eintrag in der Registry hinzugefügt werden muss:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Danach ging es auf einmal, ohne dass ich die PowerShell-Konsole neu starten musste. Interessant, dass der Blog-Eintrag, in dem ich die Lösung fand, aus dem Jahr 2020 datiert:

Enabling Powershell Remoting, Access is denied? – Fixya Cloud (wordpress.com)

Es scheint wohl, als ob das Thema immer noch aktuell ist.

PowerShell Conference Europe 2020 – viele spannende Themen

Die PowerShell Conference Europe 2020 hat zwar corona-bedingt nur als reine Online-Konferenz stattgefunden, beim Überfliegen der im Januar veröffentlichten Themen im PowerShell Magazine wird schnell deutlich, dass auch offline eine sehr gute Konferenz geworden wäre:

Auch wenn ich den letzten ca. 15 Jahren bereits einiges mit der PowerShell gemacht habe, es ist immer wieder faszinierend zu sehen, wie kreativ viele Menschen sie einsetzen und vor allem, welche Erweiterungen sie sich einfallen lassen (u.a. Import-Excel oder das Universal Dashboard, um nur einmal zwei der Erweiterungen zu nennen, die sich jeder einmal anschauen sollte).

Ich bin sicher, dass die meisten der ausgefallenen Vorträge 2021 nachgeholt werden. Gleichzeitig ist mein Eindruck, dass die Themen, so spannend sie auch sind, für die meisten Anwender der PowerShell „over the top“, also sehr weit weg sind. Wer den Anschluss nicht ganz verlieren möchte, muss sich lediglich ein wenig ausführlicher und eventuell auch systematischer mit den PowerShell-Grundlagen beschäftigen (einfach einmal per Get-Help about_* alle About-Themen auflisten und sich jeden Tag ein Thema vornehmen) und vielleicht auch in seiner Arbeitsumgebung (sprich Firma) einen Rahmen schaffen, in dem PowerShell-Skripte sinnvoll und langfristig eingesetzt werden.

PowerShell Remoting mit SSH und Public Key-Authentifizierung

Public Key-Authentifizierung bedeutet keine Passwort-Eingabe vor Invoke-Command oder Enter-PSSession mit SSH und ist natürlich ideal.

Klingt für einen reinen Windows-Admins eventuell etwas kompliziert, ist aber sehr einfach.

Da die Schrittfolge an so vielen Stellen im Internet und auch in der offiziellen Micorsoft-Dokumentation beschrieben ist, beschränke ich mich nur auf Stichworte.

Im Folgenden soll gezeigt werden, wie PowerShell-Remoting per SSH zwischen einem Windows- und einem Linux-Computer (mit Ubuntu 18.04) ohne Passworteingabe möglich ist.

Voraussetzung ist, dass unter Windows OpenSSH installiert wurde, auf dem Linux-Computer muss SSH eventuell auch nachinstalliert werden.

Schritt 1: Im ersten Schritt wird per ssh-genkey ein Paar aus privaten und öffentlichem Schlüssel erzeugt. ssh-genkey kann direkt aufgerufen werden, wenn Open SSH installiert wurde.

Das Ergebnis sind zwei Dateien: id_rsa mit dem privaten Schlüssel und id_rsa.pub mit dem öffentlichen Schlüssel.

Schritt 2: Im zweiten Schritt muss der SSH-Agent-Dienst gestartet werden. Wer SSH dauerhaft nutzen möche, setzt den Starttyp auf „Automatic“.

Schritt 3: Im dritten Schritt wird der private Schlüssel dem SSH-Agent übergeben:

ssh-add C:/Users/pemoadmin/.ssh/id_rsa

Damit ist der Windows-Teil erledigt.

Bei mir kam die Frage auf, wie der Public Key auf den Linux-Computer übertragen wird. Als Datei, das ist klar. Aber wo muss die Datei abgelegt werden, spielt der Dateiname eine Rolle und muss ich eventuell noch irgendwelche Berechtigungen setzen?

Nach zahlreichen Versuchen (mit denen ich mir fast einen schönen Sonntagnachmittag etwas verdorben hätte) fand ich am Montagmorgen in einem Blog-Eintrag von Christropher Hart (https://www.chrisjhart.com/Windows-10-ssh-copy-id/) die Lösung. Die Datei muss authorized_keys heißen und wird im (bereits vorhandenen) .ssh-Verzeichnis im home-Verzeichnis auf dem Linux-Computer abgelegt.

Am einfachsten wird die Datei per SSH übertragen:

type $env:USERPROFILE\.ssh\id_rsa.pub | ssh pemo@172.22.153.50 "cat >> .ssh/authorized_keys"

Eine Kleinigkeit fehlt natürlich noch. In der sshd_config-Datei auf dem Linux-Computer muss die Public Key-Authentifizierung durch Ändern eines Eintrags aktiviert werden:

PubkeyAuthentication yes

Die Passwort-Authentifizierung muss nicht deaktiviert werden. Dann stehen beide Varianten zur Auswahl.

Zum Schluss muss der sshd-Dienst auf dem Linux-Computer neu gestartet werden:

service sshd reload

Dank Public Key-Authentifizierung wird ein Invoke-Command jetzt sehr einfach, da weder der SSHTransport– noch der Subsystem-Parameter angegeben werden müssen:

$S1 = New-PSSession -Hostname $Hostname -Username $Username
Invoke-Command -ScriptBlock { Get-Process} -Session $S1
$S1 Remove-PSSession -Session $S1

PS: Eher eine persönliche Erinnerung. Diesen Eintrag habe ich am 21.09.2020 an einem herrlichen Spätsommermorgen auf dem dem Balkon geschrieben.