Remote Access

Aus expecco Wiki (Version 25.x)
Zur Navigation springen Zur Suche springen
Language: Deutsch  • English

Fernzugriff bezeichnet die Möglichkeit, einen entfernten Rechner oder ein entferntes Netzwerk aus diesem expecco-Image heraus zu bedienen — Shells zu öffnen, Befehle abzusetzen, Dateien zu verschieben oder ein Testgerät anzusteuern. Drei Protokoll-Familien sind unterstützt, in absteigender Empfehlungsreihenfolge:

  • SSH und SFTP (empfohlen) — verschlüsselte Shell und sichere Dateiübertragung über einen SSH-2-Tunnel. Reine Smalltalk-Implementierung in exept:libcrypt/ssh; keine externe Abhängigkeit von OpenSSL oder libssh. Für alles mit Zugangsdaten oder sensiblen Nutzdaten.
  • Lokale Kommando-Shell — fork + exec auf der lokalen Maschine. Für die Anbindung lokaler Werkzeuge und für die lokale Seite eines hybriden Workflows.
  • Telnet (veraltet) — Klartext-Terminalsitzung. Keine Verschlüsselung, Passwörter im Klartext auf der Leitung. Nur einsetzen, wenn die Gegenstelle keine Alternative bietet.

SSH und SFTP

Der SSH-Stack deckt das vollständige SSH-2-Protokoll ab (RFC 4251–4254, RFC 5656, RFC 8709, RFC 8731) inklusive der chacha20-poly1305-Transportchiffrierung von OpenSSH sowie das SFTP-v3-Subsystem (draft-ietf-secsh-filexfer-02). Zwei Schichten:

  • SSH::Client — programmatischer SSH-Zugriff (entferntes exec, TTY-Shell, Agent-Weiterleitung, ProxyJump-Bastion).
  • SSH::SftpFilename — eine

Filename-Unterklasse, die es dem restlichen ST/X erlaubt, einen entfernten SFTP-Pfad zu behandeln wie eine lokale Datei.

Die folgenden Abschnitte sind nutzeraufgaben-zuerst aufgebaut: zuerst das, was der Anwender sieht und tut, darunter die expecco-Bibliotheks-Anbindung, ganz unten Implementierungsdetails für Interessierte.

Aus dem FileBrowserV2

Im Adress-Dropdown eine sftp://-URL einfügen. Der Browser-Tab füllt sich wie bei einem lokalen Pfad. Baum-Ausklappen, Spaltensortierung (Name / Größe / mtime), Vorschau und Doppelklick zum Öffnen im Editor verhalten sich normal. Der erste Klick auf einen Host dauert ~200–500 ms (TCP + KEX + Auth); folgende Klicks nutzen die gepoolte Verbindung weiter.

URL-Syntax: 

sftp://[user@]host[:port]/remote/path

Fehlt user, wird der lokale Login-Name verwendet, Port ist standardmäßig 22, Pfad standardmäßig /.

Die Schaltfläche Refresh in der Symbolleiste (Pfeil-Kreis-Symbol zwischen Forward und DirectoryUp) liest Baum und Inhalts-Panel auf Anforderung neu ein. Funktioniert einheitlich für lokale und SFTP-Pfade; bei SFTP wird zusätzlich der per-Datei-STAT-Cache geleert, sodass Änderungen, die direkt auf der Gegenseite gemacht wurden, sofort sichtbar werden — ohne auf den Ablauf der 5-Sekunden-Cache-TTL zu warten.

Der kleine Pfeil neben dem Refresh-Symbol öffnet ein Aufklappmenü mit einem einzelnen Kontrollkästchen, Automatic Refresh, das den Hintergrund-Task an- bzw. abschaltet, der alle expandierten Baumeinträge auf externe Änderungen prüft. Die Vorgabe richtet sich nach der aktuellen Wurzel:

  • Lokales Dateisystem → an (10-Sekunden-Zyklus, entspricht dem bisherigen Verhalten).
  • SFTP → aus. Jeder Zyklus kostet einen STAT-Roundtrip pro Kind — für eine Handvoll lokaler Verzeichnisse harmlos, über das Netz schmerzhaft. Bei Bedarf manuell auf Refresh klicken, um Änderungen zu sehen.

Beim Wechsel zwischen lokalen und SFTP-Wurzeln wird der Schalter automatisch umgelegt — aber nur, sofern man ihn für die vorherige Wurzel nicht selbst verstellt hat. Eine explizite Benutzerwahl bleibt über Navigationen hinweg erhalten.

Das Menü Tools im FileBrowserV2 bietet vier Aktionen — die drei SSH-spezifischen sind nur bei geladener SSH-Bibliothek sichtbar:

  • Generate SSH Key Pair... — öffnet den Schlüsselerzeugungs-Dialog, siehe #Einen SSH-Schlüssel erzeugen unten.
  • SSH Connect... — öffnet ein interaktives VT100-Terminal zu einem entfernten Host.
  • SFTP Connect... — navigiert diesen Browser-Tab über SFTP auf ein entferntes Dateisystem.
  • Filesystem Info... — zeigt Größe, freien Platz und Belegung des Dateisystems, das das aktuell angezeigte Verzeichnis enthält. Funktioniert einheitlich für lokale und SFTP-Pfade; bei SFTP setzt der Aufruf voraus, daß der Server die Erweiterung

statvfs@openssh.com ankündigt (jedes moderne OpenSSH tut das). Größen werden in IEC-Binäreinheiten ausgegeben (MiB, GiB, TiB) — gewählt wird die größte Einheit, die einen Wert ≥ 1 liefert, damit ein TB-großes Volume als X TiB statt 10240 GiB erscheint.

Aus expecco-Aktionen

Das Expecco-RemoteAccess-Plugin (Expecco::RemoteAccessImportPlugin) stellt folgende Testaktionen in der expecco-Aktionspalette bereit:

  • CmdShell - Open SSH Remote Connection — öffnet eine SSH-Sitzung über das plattformeigene ssh-Binary (PuTTYs plink unter Windows).
  • CmdShell - Open SSH Remote Connection and PublicKey — dasselbe, jedoch mit expliziter Public-Key-Authentifizierung.

Voraussetzung: ein eingerichtetes Schlüsselpaar (privater Schlüssel auf dieser Maschine, öffentlicher Teil in der ~/.ssh/authorized_keys des Zielhosts). Schlüssel erzeugen entweder über den Dialog unten oder über ssh-keygen.

Das Plugin fügt zusätzlich eine Settings-Seite hinzu: Extras → Settings → Plugins → Remote Access — SSH Keys mit einer einzelnen Schaltfläche Generate SSH Key Pair..., die denselben Dialog öffnet.

Einen SSH-Schlüssel erzeugen

Der Dialog (FileBrowserV2 / Settings-Seite)

Der Dialog fragt alle Parameter in einem Formular ab:

  • Comment — wird in den erzeugten Schlüssel eingebettet (Voreinstellung stx@<hostname>).
  • Storage:
    • Save to disk file only — schreibt

~/.ssh/id_ed25519_stx (oder wohin man will) samt zugehöriger .pub-Datei daneben.

    • Save to disk AND load into ssh-agent — schreibt die Datei UND übergibt den Schlüssel dem laufenden ssh-agent.
    • Load into ssh-agent only — der Schlüssel lebt nur im Speicher des Agents; nach Agent-Neustart ist er verloren.
  • Private key file — vollständiger Pfad; ausgegraut im Agent-only-Modus.
  • Passphrase / Confirm — leer lässt die On-Disk-Datei unverschlüsselt (Agent-only-Modus ignoriert die Passphrase, da das OpenSSH-Agent-Wire-Protokoll nur den entschlüsselten Schlüssel transportiert).

Bei Generate wird die Public-Key-Zeile (dieselbe ssh-ed25519 AAAA... comment-Zeichenfolge, die ssh-keygen ausgibt) in die System-Zwischenablage kopiert — zum direkten Einfügen in die ~/.ssh/authorized_keys des Zielhosts.

Aus einem Workspace

Für Headless-Deployments, Sandbox-Builds oder Skripte stellt SSH::Client einen reinen Smalltalk-Schlüsselgenerator bereit, dessen Ausgabe bit-kompatibel zu ssh-keygen -t ed25519 ist: 

| seed comment priv |
seed    := SSH::Client generateEd25519Seed.
comment := 'stx@', OperatingSystem getHostName.

"/ Passphrase-verschlüsselt auf Platte speichern"
priv := (Filename homeDirectory / '.ssh' / 'id_ed25519_stx') pathName.
SSH::Client
    saveOpenSshEd25519Seed:seed
    toFile:priv
    comment:comment
    passphrase:'choose-something-long'.

"/ UND in den laufenden Agent laden"
SSH::Client addEd25519SeedToAgent:seed comment:comment.

"/ Public-Key-Zeile zum Einfügen in authorized_keys ausgeben"
Transcript showCR:
    (SSH::Client authorizedKeysLineForEd25519Seed:seed comment:comment).

Die so erzeugten Schlüssel sind mit den OpenSSH-Werkzeugen voll interoperabel (ssh-keygen -y -f ... rekonstruiert den öffentlichen Schlüssel, ssh-keygen -p -f ... ändert die Passphrase usw.).

Mit den Shell-Werkzeugen

Der klassische Weg funktioniert weiterhin: 

ssh-keygen -t ed25519 -C "stx@your.host"
ssh-copy-id user@remotehost
ssh-add ~/.ssh/id_ed25519

ssh-agent vorbereiten

Der Weg über den Agent ist dem direkten Lesen von Schlüsseldateien deutlich vorzuziehen: er hält verschlüsselte private Schlüssel einmal pro Sitzung entsperrt und kann Identitäten verwalten (hardware-tokengestützte Schlüssel, KeePassXC-Einträge), die ST/X nie direkt sehen soll.

ST/X erkennt den Agent-Pfad automatisch, sobald $SSH_AUTH_SOCK zum Zeitpunkt des Starts von stx in der Prozessumgebung gesetzt ist. Eine spätere Zuweisung aus einem Workspace nützt nichts.

Linux / macOS

Die meisten Desktop-Distributionen starten einen Agent automatisch beim Login (gnome-keyring unter GNOME, ssh-agent.service unter systemd, KWallet unter KDE). Prüfen im Terminal: 

echo $SSH_AUTH_SOCK    # /run/user/1000/keyring/ssh oder ähnlich
ssh-add -l             # listet geladene Identitäten
ssh-add ~/.ssh/id_ed25519   # eigene laden, falls nicht da

Läuft gar kein Agent, dieses Snippet in die Shell-rc-Datei aufnehmen: 

# ~/.bashrc oder ~/.zshrc
if [ -z "$SSH_AUTH_SOCK" ]; then
    eval "$(ssh-agent -s)" > /dev/null
fi

ST/X muss aus einer Shell gestartet werden, die diese rc bereits gelesen hat — ein Desktop-Launcher aus dem Dateimanager erbt die Variable nicht. Empfehlung: ein kleines Wrapper-Skript unter ~/.local/bin/, das die rc sourcet und dann stx startet.

Die Settings-Seite (Extras → Settings → Plugins → Remote Access — SSH Keys) zeigt an, ob das laufende Image einen Agent sieht.

Permanente Einrichtung via systemd

Für einen wirklich sitzungsübergreifenden Agent (überlebt Desktop- Abmeldung, kommt beim nächsten Login wieder hoch) die bei den meisten Distros mit dem Paket openssh-clients ausgelieferte Per-User-systemd-Unit aktivieren: 

systemctl --user enable --now ssh-agent.service

Anschließend SSH_AUTH_SOCK in der Shell-rc auf den User-Service-Socket zeigen lassen (ersetzt das eval $(ssh-agent -s)-Snippet oben): 

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Schlüssel automatisch beim ersten Einsatz laden

Um den manuellen ssh-add-Schritt zu sparen, kann OpenSSH Schlüssel beim ersten Bedarf selbst in den Agent laden. In ~/.ssh/config eintragen: 

Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519

Die erste SSH-Verbindung fragt dann einmal nach der Passphrase und übergibt den entsperrten Schlüssel an den Agent; weitere Verbindungen nutzen die gespeicherte Identität ohne Prompt.

Windows

Windows 10+ bringt das native OpenSSH inklusive Agent-Dienst mit. Einmalige Einrichtung:

  1. Dienste (services.msc) als Administrator öffnen.
  2. OpenSSH Authentication Agent suchen, Starttyp auf Automatisch setzen, Starten anklicken.
  3. In PowerShell: ssh-add $HOME\.ssh\id_ed25519.
  4. Prüfen: ssh-add -l.

Der Windows-OpenSSH-Agent lauscht auf einer Named Pipe (\\.\pipe\openssh-ssh-agent), nicht auf einem Unix-Socket. ST/X unterstützt beide Transporte, jedoch setzt das Windows-ssh-add SSH_AUTH_SOCK nicht selbst. Daher einmalig systemweit setzen:

  1. Vorlage:Key drücken → "Umgebungsvariablen" → „Systemumgebungs- variablen bearbeiten".
  2. Umgebungsvariablen → unter Benutzervariablen, Neu klicken.
  3. Name: SSH_AUTH_SOCK
  4. Wert: \\.\pipe\openssh-ssh-agent
  5. Ab- und wieder anmelden (oder stx neu starten), damit die neue Umgebung übernommen wird.

PowerShell-Schnelleinrichtung

Derselbe Aufbau aus einer Administrator-PowerShell heraus, z.B. für Skripte oder unbeaufsichtigte Bereitstellung: 

# Agent jetzt und bei jedem Neustart starten (permanent).
Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent

# SSH_AUTH_SOCK dauerhaft für den Benutzer setzen (übersteht Reboots).
[Environment]::SetEnvironmentVariable(
    'SSH_AUTH_SOCK',
    '\\.\pipe\openssh-ssh-agent',
    'User')

# Schlüssel laden (fragt nach Passphrase, falls die Datei verschlüsselt ist).
ssh-add $HOME\.ssh\id_ed25519

Für einen einmaligen Agent-Start ohne dauerhafte Aktivierung (z.B. Einzelsitzung) die Set-Service-Zeile weglassen und nur Start-Service ssh-agent ausführen. Die env-var-Zeile lässt sich ebenfalls weglassen, wenn SSH_AUTH_SOCK nur in der aktuellen Shell gebraucht wird — dann statt der [Environment]-Variante $env:SSH_AUTH_SOCK = '...' verwenden.

Auf stark abgespeckten Windows-Installationen ist der ssh-agent-Dienst eventuell nicht vorhanden. Einmalig nachrüsten über Einstellungen → Apps → Optionale Features → OpenSSH- Client.

Alternative Agenten:

  • PuTTY pageant — eigenes Protokoll; von ST/X's

SSH::Agent nicht unterstützt. Schlüssel zu OpenSSH migrieren.

  • Git für Windows ssh-agent — funktioniert;

SSH_AUTH_SOCK auf den dort veröffentlichten Socket zeigen lassen.

  • WSL 2 — ein ST/X innerhalb der WSL sieht den WSL-eigenen Agent normal; ein ST/X auf der Windows-Seite nicht. Eine Brücke per npiperelay + socat ist möglich.

Prüfung über die Settings-Seite (Extras → Settings → Plugins → Remote Access — SSH Keys) — die Anzeige dort meldet, ob das laufende Image den Agent sieht.

Schlüssel automatisch beim ersten Einsatz laden

Windows-OpenSSH speichert agent-geladene Schlüssel nicht über Agent-Neustarts hinweg. Um nicht nach jedem Reboot manuell ssh-add aufrufen zu müssen, dieselbe Lazy-Load- Konfiguration in %USERPROFILE%\.ssh\config eintragen: 

Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519

OpenSSH lädt den Schlüssel dann beim ersten Einsatz in den Agent (fragt einmal nach der Passphrase) und nutzt ihn für die übrige Sitzung weiter.

Konfiguration

Alle Stellschrauben sind klassenseitig auf SSH::SftpFilename erreichbar:

Accessor Voreinstellung Steuert
#idleEvictionSeconds: 240 (4 Min) Wie lange

eine gepoolte Verbindung im Leerlauf liegen darf, bevor sie beim nächsten Zugriff proaktiv geschlossen und neu geöffnet wird. Liegt knapp unter dem typischen ClientAliveInterval × ClientAliveCountMax des sshd, damit wir uns recyceln, bevor der Server uns mit TCP-RESET trennt. nil setzt auf Voreinstellung zurück.

#attrsCacheTtlSeconds: 5 Maximales Alter (s)

eines gecachten STAT, bevor #ensureAttrs neu am Server fragt. Eltern-listDir stempelt ohnehin frische Attribute auf alle Kinder, daher zahlt das Navigieren im offenen Verzeichnis das TTL nicht. 0 schaltet den Cache ab.

#closeAllConnections (Aktion) Reißt jede

gepoolte Verbindung ab. Nützlich nach einem bekannt schlechten Netzereignis, vor einem bewussten Identitätswechsel oder zum sauberen Image-Shutdown.

Diagnose

SemaphoreMonitor

SemaphoreMonitor über das Untermenü „Status" des Launchers öffnen. Der pro-Host-SFTP-Mutex erscheint als SFTP/<user@host:port>, der pool-weite Mutex als SFTP/pool. Per Rechtsklick:

  • Copy Waiters Stack to Clipboard — schreibt den Walkback des letzten Eigners samt aller Waiter als Text in die Zwischenablage. Unverzichtbar, wenn ein Prozess in

readWait innerhalb von withSftpClientDo: klemmt.

  • Copy List to Clipboard — die ganze Tabelle, ideal für eine E-Mail-Diagnose.
  • Detect Deadlocks — DFS über den Wait-for-Graph, meldet Zyklen.

Logger

Interessante Ereignisse werden über Logger geloggt:

  • warning: bei automatischem Reconnect nach toter Verbindung.
  • warning: bei Idle-Verdrängung eines Pool-Eintrags.
  • warning: wenn eine SSH-Schlüsseldatei nicht geparst werden konnte — die Datei wird übersprungen.

Einschränkungen

  • Nur SFTP v3. Kein SETSTAT (kein entferntes chmod / chown / utime), kein SSH_FXP_READLINK exponiert (#isSymbolicLink liefert immer false,

#linkInfo die normale stat-Info). Einige SFTPv5+-Annehmlichkeiten werden dennoch über OpenSSH-spezifische SSH_FXP_EXTENDED-Aufrufe nutzbar — siehe #OpenSSH-SFTP-Erweiterungen weiter unten.

  • Serialisierung pro Host. Zwei gleichzeitige Operationen am selben Host stehen am Host-Mutex an. Siehe #Ausblick.
  • #renameTo:-Fallback hat ein TOCTOU-Fenster. Bei Servern, die posix-rename@openssh.com ankündigen (jedes moderne OpenSSH tut das), ist das Überschreiben atomar. Beim seltenen Server, der das nicht tut, wird auf Delete-dann-Rename ausgewichen und ein anderer Prozess kann sich dazwischenschieben.
  • #isNonEmptyDirectory ist eine Heuristik. Liefert immer #isDirectory (die genaue Antwort würde drei Roundtrips pro Verzeichnis-Symbol kosten, was das ursprüngliche Baum-Ausklappen unerträglich gebremst hatte).

Implementierungsdetails

Für Leser, die die Architektur verstehen wollen. Fünf Klassen, von oben nach unten:

Klasse Aufgabe
SSH::SftpFilename Filename-Unterklasse, die

öffentliche API. Bildet sftp://...-URLs auf entfernte Dateien ab und stellt directoryContents, readingFileDo:, renameTo: usw. bereit.

SSH::SftpClient SFTP-v3-Protokoll

(Request/Response-Codec, listDir, stat, open, read, write, mkdir). Wird von SftpFilename angesteuert.

SSH::Channel SSH-Kanal-Multiplexer (CHANNEL_OPEN,

DATA, EOF, CLOSE, WINDOW_ADJUST). Eine logische Sitzung pro Channel-Instanz.

SSH::Client High-Level-SSH-Client: öffnet den

Transport, führt KEX, Hostschlüssel-Prüfung und userauth durch und verteilt anschließend Kanäle.

SSH::Transport Drahtschicht. Banner- und

KEXINIT-Austausch, ChaCha20-Poly1305-Paket-Framing, sendSeq / recvSeq, Heartbeat, SSH_MSG_DISCONNECT.

OpenSSH-SFTP-Erweiterungen

SFTP v3 (Entwurf draft-ietf-secsh-filexfer-02) ist bewusst minimal gehalten. OpenSSH bringt einen offenen Erweiterungsmechanismus mit: der Server listet im SSH_FXP_VERSION-Reply die Erweiterungsnamen auf, die er versteht, und der Client ruft sie über SSH_FXP_EXTENDED(200)-Pakete mit dem Erweiterungsnamen als erstem String auf. Jede Erweiterung wird über SSH::SftpClient>>supportsExtension: feature-detektiert; Aufrufer fallen zurück, wenn der Server sie nicht ankündigt.

Der Stack nutzt heute vier OpenSSH-Erweiterungen:

  • posix-rename@openssh.com — atomares rename-mit-Überschreiben. Wird automatisch von

SftpFilename>>renameTo: aufgegriffen; die Delete-dann-Rename-Fallback-Variante kommt nur bei Servern zum Einsatz, die die Erweiterung nicht haben.

  • hardlink@openssh.com — Erzeugt einen POSIX-Hardlink. Verfügbar als SftpFilename>>createHardLinkAs:.
  • statvfs@openssh.com — POSIX-

statvfs(3)-typische Dateisystem-Statistik. Verfügbar als SftpFilename>>fileSystemInfo; das Ergebnis ist form-kompatibel zu OperatingSystem getDiskInfoOf:, sodass Aufrufer lokale und entfernte Pfade einheitlich behandeln können. Treibt den Menü-Eintrag Tools → Filesystem Info... an, der am Anfang dieser Seite beschrieben ist.

  • fsync@openssh.com — schreibt den serverseitigen Schreibpuffer eines geöffneten Handles auf Platte. Liegt als

SftpClient>>fsyncHandle: bereit; noch nicht in eine "Durable-Write"-API auf Filename-Ebene eingebunden.

Die verbleibenden OpenSSH-Erweiterungen (lsetstat@openssh.com, fstatvfs@openssh.com) werden in der angekündigten Liste erkannt, aber nicht auf Filename-Ebene gekapselt — es gibt dafür noch keinen Filename-seitigen Aufrufer.

Verbindungs-Pooling

Alle SftpFilename-Instanzen, die auf dasselbe Tripel user@host:port zeigen, teilen sich einen SSH::Client samt einem SSH::SftpClient. Der Pool ist klassenseitig und wird von einem einzigen ConnectionPoolMutex bewacht:

  • Lazy-Aufbau — TCP + KEX + userauth + SFTP-INIT laufen erst beim ersten SFTP-Aufruf, nicht in forUrl:.
  • Serialisierung pro Host — SFTP-Anfragen an einen bestimmten Host werden durch einen RecursionLock mit dem Namen SFTP/<user@host:port> serialisiert (sichtbar im SemaphoreMonitor).
  • Idle-Verdrängung — ein Pool-Eintrag, der länger als

idleEvictionSeconds ungenutzt liegt, wird beim nächsten Zugriff proaktiv geschlossen und neu geöffnet.

  • Automatischer Reconnect — ein Fehler auf Transportebene (Broken Pipe, EOF, MNU auf nil-Socket) verdrängt den Pool-Eintrag, öffnet einen frischen Client und wiederholt die Anfrage einmal. Anwendungsfehler aus SFTP-STATUS-Antworten werden sofort durchgereicht.

Ausblick

Geplant, aber noch nicht umgesetzt:

  • Multi-Channel-Parallelität pro Host — aktuell bedeutet eine TCP- plus eine SFTP-Verbindung pro Host, dass N gleichzeitige Anfragen serialisieren. Pipelining über mehrere SshClients im Pool (bevorzugt) oder ein transport-seitiger Reader-Prozess, der eingehende Pakete in Pro-Kanal-Postfächer demultiplext, würde es dem Baum-Panel erlauben, weiter aufzulisten, während das Inhalts-Panel eine große Datei liest.
  • Genaues #isNonEmptyDirectory via OPEN_DIR + READ_DIR (nur erstes Batch) + CLOSE — drei Roundtrips pro Sondierung; lohnt erst, wenn der SftpClient Anfragen pipelinen kann.
  • SFTP-v5/v6-Aushandlung für erweiterte Attribute und FTP-artige Kanonisierung. (Atomares Überschreibungs-rename ist bereits über die OpenSSH-Erweiterung

posix-rename@openssh.com abgedeckt; siehe #OpenSSH-SFTP-Erweiterungen.)

Kommando-Shell

Lokale Kommando-Shell auf dieser expecco-Maschine. Typische Anwendungen: lokale Kommandozeile, lokales Hilfsprogramm, Brücke zwischen entferntem Workflow und lokalem Tool.

Das RemoteAccess-Plugin stellt bereit:

  • CmdShell - Open
  • CmdShell - Close

Keine Zugangsdaten, kein Netzwerk — läuft als der Benutzer des expecco-Prozesses. Ausgaben gehen in das expecco-Log.

Telnet

Warnung Telnet ist ein veraltetes Protokoll ohne Verschlüsselung. Passwörter werden im Klartext über die Leitung übertragen; jeder im Netzpfad kann sie lesen. Telnet NUR einsetzen, wenn die Gegenstelle keine Alternative bietet (typisch: alte Industriesteuerungen, Laborgeräte, eingebettete Messgeräte ohne SSH-Stack). Für alles andere #SSH und SFTP verwenden.

Das expecco-Plugin stellt bereit:

  • Telnet - Open Remote Connection With Login
  • Telnet - Execute Remote Command
  • Example - Remote Device Control via Telnet (interne Demo)

Das Telnet-Protokoll (RFC 854) ist ein bidirektionaler 8-Bit-Byte-Strom über TCP, mit In-Band-Steuersequenzen für Terminal-Optionen. Verbindungsaufbau zum Ziel-Host:Port; nach optionalem In-Band-Login können beide Seiten Daten senden.

Siehe auch


Copyright © 2014-2024 eXept Software AG

Abgerufen von „https://doc.expecco.de/index.php?title=Remote_Access&oldid=31320“