ssh - CPU-Auslastung

[frankw]

Hi,

ist es möglich, dem ssh-daemon zu sagen, dass er mehr als 1 CPU nutzen darf? das Problem ist,, dass gerade bei Dateitransfer (scp/sftp) schnell die (eine) CPU auf 100% hoch geht, während die anderen cores "herum-idlen" und der Datendurchsatz eher gering ist (zumindest auf ARM-Struktur).

evtl. gibt es da ja eine Möglichkeit dem SSH-Dienst, bzw. den Verschlüselungsteil (imho openssl) Multithreading beizubringen

Gruß Frank

[DeletedUserReAsG]

Verschlüsselung und Multithreading wird schwer. Allerdings kann man bei OpenSSH verschiedene Algorithmen nutzen, einige davon sind weniger rechenintensiv. Möglicherweise gibt’s auch einen, der von deinem SoC, dessen Bezeichnung du leider geheim hälst, hardwareseitig unterstützt wird. Das wäre dann die beste Option.

Vor Kurzem wurde ein Algo von Google in den Kernel aufgenommen, der speziell für Geräte mit geringer Rechenleistung konzipiert wurde – möglicherweise ist der nutzbar.

[MSfree]

Grundsätzlich darf jeder Prozeß so viele Threads starten, wie er will. OK, die Zahl ist zwar im Kernel limitiert, das genaue Limit weiß ich nicht, es liegt aber sehr viel höher als die Anzahl der CPU-Kerne.

SSH überträgt Daten verschlüsselt. Da bei der Ver- und Entschlüsselung der Zustand des Verschlüsselungsmechanismuses vom vorher gesendeten/empfangenen Byte abhängt, kann man das prinzipbedingt nicht parallelisieren. Die einzige Methode, die Datenübertragung zu parallelisieren, ist, mehrere SSH-Prozesse zu verwenden und die Datenübertragung auf mehrere SSH/SCP-Prozesse aufzueilen.

Da erwähnst ARM. Sollte es sich dabei um einen Raspberry handeln, wirst du aber sehr schnell den nächsten Flaschenhals erreichen, den via USB angebundenen Netzwerkanschluß, der ohnehin kaum mahe als 300MBit/s beim Raspi 3 B+ schafft.

[frankw]

hatte nicht vor, es geheim zu halten, dachte nur, es gibt eine global-galaktische Einstellung

meine Hardware ist der Bananapi-R2 (SOC: mt7623), Kernel kann bis 5.0-rc1 alles sein nebenbei versuche ich (aktuell nur auf 4.14) die HW-Beschleunigung in openssl reinzubekommen (via cryptodev), das scheitert aber meinerseits an Wissen

so grob ist das mein Ansatz: https://github.com/frank-w/BPI-R2-4.14/ ... openssl.sh, für cryptodev: https://github.com/frank-w/BPI-R2-4.14/ ... v/build.sh

nach dem Compiliervorgang von openssl liegt alles vertreut im source-ordner, deswegen konnte ich es noch nicht auf das Host-system bekommen...gibt sicher eine Möglichkeit via fakeroot o.ä. dass in einen Ordner zu installieren, um das auf das Zielsystem zu bekommen

aktuell bewegt es sich bei ca. 35-40MB/s...über iperf habe ich ~900Mbit/s

evtl. paar infos zum cryptodev auf dem R2: http://forum.banana-pi.org/t/is-it-poss ... ng/4034/37 ich habs jedoch noch nicht zum laufen bekommen...

[MSfree]

nach dem Compiliervorgang von openssl...

SSH ist zumindest auf meinem Debian nicht von openssl abhängig.

aktuell bewegt es sich bei ca. 35-40MB/s...über iperf habe ich ~900Mbit/s

35-40MByte/s wären rund 300MBit/s. Meinem Gefühl nach ist das eine Datenrate, die der ARM nur mit Crypto-Beschleunigung erreichen kann. Rein in Software wäre es meinem Gefühl nach deutlich weniger.

Ich schlage vor, du sortierst erstmal aus, ob du mit SSH oder mit OpenSSL arbeiten willst, das sind nämlich 2 Paar Schuhe. Dann solltest du versuchen zu klären, ob SSH auf dem Banana-Pi nicht ohnehin schon mit Beschleunigung arbeitet.

[DeletedUserReAsG]

Bezüglich OpenSSH vs. OpenSSL: war mein Fehler, hatte es oben falsch hingeschrieben. Ist mittlerweile korrigiert.

[frankw]

prinzipiell sollte sowohl openssl als auch openssh so schnell wie möglich laufen

ich teste nochmal die aktuelle Geschwindigkeit über ssh...habe grade gesehen, dass mein Beipiel (aus anderem Forum) das encoding/decoding nicht auf dem R2 gemacht hat, sondern nur durchgeschickt hat...somit ist die Geschwindigkeit definitiv falsch

ich hatte ~12-13MB/s lt. scp-Anzeige

kann ich prüfen, ob openssh openssl verwendet oder seine verschlüsselung selbst handled?

[MSfree]

kann ich prüfen, ob openssh openssl verwendet oder seine verschlüsselung selbst handled?

Ja, mit:

Code: Alles auswählen

ldd /usr/bin/ssh

[mat6937]

prinzipiell sollte sowohl openssl als auch openssh so schnell wie möglich laufen

Ich denke openssh wurde als "secure shell" (ein tool für remote login) entwickelt, mit dem Focus auf Sicherheit und nicht so sehr auf Performance bzgl. Übertragung von großen Datenmengen.

[MSfree]

Ich denke openssh wurde als "secure shell" (ein tool für remote login) entwickelt, mit dem Focus auf Sicherheit und nicht so sehr auf Performance bzgl. Übertragung von großen Datenmengen.

Verschlüsselung kostet nunmal CPU-Zyklen. Daß man bei SSH die Performance zu Gunsten der Sicherheit aber vernachlässigt hätte, kann man so nicht stehen lassen. Inzwischen unterstützt auch SSH die AES-Einheiten der aktuellen x64-CPUs, was die CPU deutlich entlastet. Jedenfalls kann man zwischen zwei halbwegs aktuellen x64-Rechnern Daten mit GBit-Geschwindigkeit übertragen.

Ich habe mich mit der ARM-Architektur zugegebenermassen noch nicht so detailiert auseinandergesetzt, daß ich sagen könnte, welche Hardwarebeschleunigungen da drin stecken. So etwas wie die AES-Einheiten bei x64 gibt es aber auch bei den ARMs und die werden meines Wissen auch genutzt.

[hikaru]

Ich überblicke das nicht vollständig, aber lässt sich aus [1] etwas hilfreiches ableiten?

[1] http://forum.banana-pi.org/t/is-it-poss ... rking/4034

[mat6937]

Daß man bei SSH die Performance zu Gunsten der Sicherheit aber vernachlässigt hätte, kann man so nicht stehen lassen.

Ich habe nicht "vernachlässigen" geschrieben, sondern "Focus" und ich meinte damit den Schwerpunkt (oder synonym).

[frankw]

Ich überblicke das nicht vollständig, aber lässt sich aus [1] etwas hilfreiches ableiten?

[1] http://forum.banana-pi.org/t/is-it-poss ... rking/4034

Den link habe ich oben schon gepostet...ich weis nur noch nicht, wie ich cryptodev für ssh nutzen kann...alle doku (und das ist nicht viel verwertbares) bezieht sich nur auf openssl....wenn openssh das selbst implementiert, steh ich aif dem schlauch.

Openssl habe ich mittlerweile soweit kompiliert...muss nur schauen,wie ich das teste

[Rosendoktor]

Zum Thema cryptodev:

Was für ein System hast Du den auf dem BananaPI eigentlich drauf? Ein Standard Debian für ARM oder ein für den BananaPI bereits angepasstes?

Damit cryptodev funktioniert muss der Kernel es unterstützen. Der Debian x86 Kernel macht das nicht, man muss sich einen eigenen Kernel compilieren mit eigener Konfiguration. Wenn der Kernel es unterstützt dann ist ein Gerät /dev/crypto vorhanden, fehlt dieses, wird cryptodev nicht unterstützt.

Um openssh zu compilieren holst Du Dir am besten das Quellpaket:

cd /usr/src && apt-get source openssh

Dann in der Datei debian/rules die entsprechende confflags Zeile anpassen:

confflags += --with-ssl-engine=cryptodev

Am besten dann in debian/changelog ganz oben einen eigenen Eintrag anlegen und die Version ergänzen, z.B. durch "+mypatch1", das schützt das Paket später vor überschreiben.

Das Paket compilieren:

dpkg-buildpackage -us -uc

Dann die im /usr/src Verzeichnis gebauten *.deb Pakete mit dpkg -i installieren.

Dann sollte ssh auch die Hardware Kryptographie unterstützen. Welche Ciphers von Deiner Hardware unterstützt werden musst Du herausfinden und in der /etc/ssh/sshd_conf entsprechend konfigurieren.

[frankw]

auf dem Bananapi habe ich via debootstrap ein normales stretch gebaut (https://www.fw-web.de/dokuwiki/doku.php ... -r2:debian). Kernel habe ich einen eigenen (https://github.com/frank-w/BPI-R2-4.14 auf dem Wirksystem den 4.14, auf dem Test teilweise auch 4.19+). Bei 4.19 bin ich gerade dabei, das in den Kernel einzubauen

4.14 sieht schonmal so aus:

Code: Alles auswählen

[17:17] root@bpi-r2-e:/etc/ppp (551)# modprobe cryptodev
[17:21] root@bpi-r2-e:/etc/ppp (552)# ls /dev/crypto
/dev/crypto

habe aktuell nur die warning in dmesg:

Code: Alles auswählen

[Mo Jan 21 17:21:33 2019] cryptodev: loading out-of-tree module taints kernel.
[Mo Jan 21 17:21:33 2019] cryptodev: driver 1.9 loaded.

habe das cryptodev-modul hat im ordner extras...habe irgendwo gelesen, das sollte dahin und nicht "irgendwo" zu den anderen modulen...

Code: Alles auswählen

[19:14] root@bpi-r2-e:/etc/ppp (556)# find /lib/modules/$(uname -r) -name cryptodev.ko
/lib/modules/4.14.78-bpi-r2-main/kernel/extras/cryptodev.ko

da ich den Kernel aber auf einem x86-host baue (ubuntu) wollte ich die originalen Quellen (nicht via apt source)...ähnlich wie bei openssl (gibt es da ein git-repo o.ä, was man via script sich holen kann?)

https://github.com/openssh/openssh-portable

scheint die offizielle Quelle zu sein, kannst du mir mal die Datei mit den optionen schicken, damit ich es bauen kann mit den debian-optionen+cryptodev?

ansonsten ist aber der Parameter schonmal hilfreich zu wissen und wenns nur zum gezielteren Suchen ist

Edit: achso:

Code: Alles auswählen

[17:21] root@bpi-r2-e:/etc/ppp (553)# ldd /usr/bin/ssh
	linux-vdso.so.1 (0xbecde000)
	libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6e8d000)
	libcrypto.so.1.0.2 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2 (0xb6d55000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6d42000)
	libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6d20000)
	libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb6d00000)
	libgssapi_krb5.so.2 => /usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 (0xb6cc6000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6bd8000)
	/lib/ld-linux-armhf.so.3 (0xb6f56000)
	libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb6b79000)
	libkrb5.so.3 => /usr/lib/arm-linux-gnueabihf/libkrb5.so.3 (0xb6ae1000)
	libk5crypto.so.3 => /usr/lib/arm-linux-gnueabihf/libk5crypto.so.3 (0xb6aab000)
	libcom_err.so.2 => /lib/arm-linux-gnueabihf/libcom_err.so.2 (0xb6a98000)
	libkrb5support.so.0 => /usr/lib/arm-linux-gnueabihf/libkrb5support.so.0 (0xb6a81000)
	libkeyutils.so.1 => /lib/arm-linux-gnueabihf/libkeyutils.so.1 (0xb6a6e000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6a4a000)
[17:25] root@bpi-r2-e:/etc/ppp (554)# ldd /usr/sbin/sshd 
	linux-vdso.so.1 (0xbefab000)
	libwrap.so.0 => /lib/arm-linux-gnueabihf/libwrap.so.0 (0xb6eb7000)
	libaudit.so.1 => /lib/arm-linux-gnueabihf/libaudit.so.1 (0xb6e83000)
	libpam.so.0 => /lib/arm-linux-gnueabihf/libpam.so.0 (0xb6e69000)
	libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0xb6e3f000)
	libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0xb6de6000)
	libcrypto.so.1.0.2 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2 (0xb6cae000)
	libutil.so.1 => /lib/arm-linux-gnueabihf/libutil.so.1 (0xb6c9b000)
	libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6c79000)
	libcrypt.so.1 => /lib/arm-linux-gnueabihf/libcrypt.so.1 (0xb6c3a000)
	libgssapi_krb5.so.2 => /usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 (0xb6c00000)
	libkrb5.so.3 => /usr/lib/arm-linux-gnueabihf/libkrb5.so.3 (0xb6b68000)
	libcom_err.so.2 => /lib/arm-linux-gnueabihf/libcom_err.so.2 (0xb6b55000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6a67000)
	/lib/ld-linux-armhf.so.3 (0xb6f78000)
	libnsl.so.1 => /lib/arm-linux-gnueabihf/libnsl.so.1 (0xb6a47000)
	libcap-ng.so.0 => /lib/arm-linux-gnueabihf/libcap-ng.so.0 (0xb6a33000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6a20000)
	libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0xb69c1000)
	librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb69ab000)
	liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0xb6981000)
	liblz4.so.1 => /usr/lib/arm-linux-gnueabihf/liblz4.so.1 (0xb6965000)
	libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0xb68ba000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6891000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb686d000)
	libk5crypto.so.3 => /usr/lib/arm-linux-gnueabihf/libk5crypto.so.3 (0xb6837000)
	libkrb5support.so.0 => /usr/lib/arm-linux-gnueabihf/libkrb5support.so.0 (0xb6820000)
	libkeyutils.so.1 => /lib/arm-linux-gnueabihf/libkeyutils.so.1 (0xb680d000)
	libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb67ed000)
	libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0xb67d0000)