Welche SSH-Implementierung verwendet Ihr?

[Annika Hansen]

Mich würde mal Eure Einschätzung zum Thema SSH-Implementierung interessieren. Was spricht für bzw. gegen die Verwendung der
- OpenSSH-Implementierung von optware bzw.
- der mitgelieferten von Synology?
Welche verwendet Ihr und warum?

Der Aufwand vom Konfigurieren ist bei der OpenSSH-Variante geringfügig umfangreicher aber ansonsten sollte sich die beiden doch nichts nehmen, oder?

Freue mich auf eine rege Diskussion mit Euch.

 

[jahlives]

Ist eigentlich egal solange du nur SSH-2 verwendest und nicht noch SSH-1

 

[Annika Hansen]

Na ja, mal ehrlich: wo findest Du denn heute noch eine SSH 1.x-Version, die zum Einsatz kommt? Es sollte eigentlich klar sein, dass ich die aktuellen SSH 2.x Implementierungen meine, zumal es von optware nur letzte gibt.

 

[ubuntulinux]

Der Vorteil vom IPKG-SSH ist, dass auch SCP möglich ist. Geht zwar beim integrierten auch, aber nur mit etwas gebastel Ich selber aber verwende den standard-SSH-Server.

 

[goetz]

Hallo,
ipkg openssh bricht die Gleichheit von admin und root Passwort auf.

Gruß Götz

 

[Annika Hansen]

Der Vorteil vom IPKG-SSH ist, dass auch SCP möglich ist. Geht zwar beim integrierten auch, aber nur mit etwas gebastel

Ja, ich habe hier im Forum und im Wiki die Beiträge/Anleitungen bzgl. SCP und WinSCP gelesen. Bisher habe ich es nicht benötigt, da WinSCP ja auch SFTP unterstützt und das ohne große Aufwände mit dem internen SFTP-Server gelöst werden kann.

ipkg openssh bricht die Gleichheit von admin und root Passwort auf.

Oh, das war mir bisher nicht bewußt. :-O
Danke für den Hinweis, Götz.

 

[itari]

mit dem internen SFTP-Server gelöst werden kann

Gibt es den wirklich? Dachte, es gibt nur den FTPES ... mach kaum etwas mit FTP, deswegen frag ich

Itari

 

[Trolli]

Ja, da ist alles beim alten. SFTP geht standardmäsig nicht, nur FTPES.

 

[Annika Hansen]

Hmm, der SFTP-Server ist standardmäßig nicht aktiviert. Aber das lässt sich mit einem einfachen Handgriff schnell machen. Siehe dazu den Auszug aus dem englischsprachigen Wiki:

With latest versions of DS3.1 you can enable the buildin-sftp server by changing the sftp section in the config file /etc/ssh/sshd_config to that shown below. After the config change you must disable/reenable the ssh deamon or reboot your DS, so the config change is loaded by sshd!

# override default of no subsystems
#Subsystem      sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp

Quelle: How to setup an sftp-server (Method 3).

Das klingt für mich nicht nach FTP over explicit SSL/TLS sondern eindeutig nach SFTP.

 

[Trolli]

Danke! Den kannte ich noch nicht. Das werd ich gleich mal in unser deutsches Wiki einfügen!

 

[itari]

Dann hat sich meine Nachfrage doch gelohnt

Itari

 

[Annika Hansen]

Hey, das freut mich, dass ich den alten Hasen noch was Neues zeigen konnte.

 

[Claus67]

Bei der Installation von Rsnapshot via IPKG wurde bei mir aufgrund der Abhängigkeiten u. A. das Paket OpenSSH (unfreiwillig) mitinstalliert.
Dannach habe ich eher zufällig festgestellt, dass OpenSSH die "Automatische Blockierung" des DSM 2.3.0.1157 ausgehebelt hatte, d.h. unbemerkt eine Sicherheitslücke geöffnet wurde, sodass Brute Foce angriffe auf den SSH-Port nicht mehr automatisch blockiert wurden.
Das war für mich der NoGo für OpenSSH. Mit dem "eingebauten" SSH lebe ich seitdem bestens...
Ob das Problem mit der aktuellen DSM-Version noch besteht kann ich nicht sagen.
Gruß
Claus

 

[itari]

Dannach habe ich eher zufällig festgestellt, dass OpenSSH die "Automatische Blockierung" des DSM 2.3.0.1157 ausgehebelt hatte

Da ist der Zungenschlag ein wenig irrführend. OpenSSH hebelt eigentlich nichts aus, sondern hat halt nicht die Blockierungs-Modifikation, die Synology in seinen sshd eingebaut hat

Itari

 

[frank-fgr]

Interessant ist übrigens auch, dass die "Automatische Blockierung" nicht greift, wenn man auf Public-Key umgestellt hat und die Anmeldung per User/Password verboten hat.

Gruß
Frank

 

[scythe42]

Da ist der Zungenschlag ein wenig irrführend. OpenSSH hebelt eigentlich nichts aus, sondern hat halt nicht die Blockierungs-Modifikation, die Synology in seinen sshd eingebaut hat

Jetzt hast du mich neugierig gemacht. Wollte eh mal durch die GPL Sources gucken, weil ich gerade busybox erneuern wollte.

Das sind die Patches:

diff openssh-5.8p1/sshd.c source/openssh-5.8p1/sshd.c
122a123,124
> #include "synodef.h"
> 
1898a1901,1911
> 
> #ifdef MY_ABC_HERE
>     char szCmd[256];
> 
>     snprintf(szCmd, sizeof(szCmd), "/usr/syno/bin/synoautoblock --deny \"%s\"", remote_ip);
>     if (1 == WEXITSTATUS(system(szCmd))) {
>         syslog(LOG_WARNING, "%s:%s:%d [%s] host is denied to login.", __FILE__, __func__, __LINE__, remote_ip);
>         debug("Connection refused by synoautoblock");
>         fatal("synoautoblock refuse returns");
>     }
> #endif /* MY_ABC_HERE */

diff openssh-5.8p1/auth-passwd.c  source/openssh-5.8p1/auth-passwd.c 
55a56,60
> #include "synodef.h"
> 
> #ifdef MY_ABC_HERE
> #include <synosdk/ldap.h>
> #endif
115c120,124
<     if (options.use_pam)
---
>     if (options.use_pam
> #ifdef MY_ABC_HERE
>         && (strchr(authctxt->user, '\\') || strchr(authctxt->user, SZ_LDAP_DOMAIN_SEPARATOR)) //ONLY do PAM-authenticate check on domain/LDAP user.
> #endif
>     )
125a135,152
> 
> #ifdef MY_ABC_HERE
>     char szCmd[256];
>     char *szRemoteIP = get_remote_ipaddr();
> 
>     if (result && ok) {
>         snprintf(szCmd, sizeof(szCmd), "/usr/syno/bin/synoautoblock --reset \"%s\"", szRemoteIP);
>         system(szCmd);
>     } else {
>         snprintf(szCmd, sizeof(szCmd), "/usr/syno/bin/synoautoblock --attempt \"%s\"", szRemoteIP);
>         if (1 == WEXITSTATUS(system(szCmd))) {
>             syslog(LOG_WARNING, "%s:%s:%d [%s] host is denied to login.", __FILE__, __func__, __LINE__, szRemoteIP);
>             debug("Connection refused by synoautoblock");
>             fatal("synoautoblock refuse returns");
>         }
>     }
> #endif /* MY_ABC_HERE */
>

Ganz simple in neuere SSH Versionen einzubauen bzw. in beliebige Tools! Und Sachen wie hosts.deny kann man ja leicht mit einem Wrapper um synoautoblock erledigen...

Gepatcht bzgl. synoautoblock sind nur:

• busybox-1.16.1/loginutils/login.c
• busybox-1.16.1/networking/telnetd.c
• openssh-5.8p1/sshd.c
• openssh-5.8p1/auth-passwd.c
• php-5.3.x/ext/standard/exec.c
• rsync-3.0.4/authenticate.c
• rsync-3.0.4/clientserver.c

MY_ABC_HERE ist wohl bei Synology üblich für eigene Patches. Also einfach in den GPL Sources zu finden. Wieder was neues gelernt...

 

[scythe42]

Interessant ist übrigens auch, dass die "Automatische Blockierung" nicht greift, wenn man auf Public-Key umgestellt hat und die Anmeldung per User/Password verboten hat.

Macht ja auch wenig Sinn. Angriff mit zufälligen SSH Keys? Wenn User/Password verboten ist, kann einem ein Dictionary bzw. Common Password Angriff eigentlich egal sein

 

[frank-fgr]

Das stimmt, dennoch wäre es besser, wenn sollche Versuche (bei mir waren es etwa 30 Stück von eine IP hintereinander) geblocked würden.
Dann bliebe das Syslog auch sauberer.

 

[scythe42]

Das stimmt, dennoch wäre es besser, wenn sollche Versuche (bei mir waren es etwa 30 Stück von eine IP hintereinander) geblocked würden. Dann bliebe das Syslog auch sauberer.

Tatsächlich regelmässige Login Versuche mit SSH Keys? Ist mir noch nicht untergekommen. Wieder was gelernt. Schau aber eigentlich auch nie ins Syslog.

Vielleicht haben einige Provider den gleichen Key in ihren Rootservern als Default (oder einige Linux Installationen oder embedded Systems) und die werden dann ausprobiert? Oder ein Sammlung von geklauten Admin Keys? Gibt wohl nichts, was es nicht gibt im Netz...

Wie dem auch sein, es gäbe folgende Lösungsansätze für dein Anliegen

• den auth-passwd.c Patch auch für Key Logins übernehmen und ssh von Synology gegen ein Neues ersetzen
• Zum Optware SSH zusätzlich SSH Guard (http://www.sshguard.net/) verwenden.

Da ich mir nach meiner Recherche von gestern die Tage eine aktuelle OpenSSL/OpenSSH Kombo mit den Syno Patches bauen wollte (um das Mitgelieferte transparent zu ersetzen), kann ich synoautoblock auch an passender Stelle für SSH Keys einbinden und den Patch samt Anweisungen was ich gemacht habe hier posten.

Beste da Interesse von deiner Seite dran?

 

[frank-fgr]

Klingt schon interessant.
Werde mich dieser Thematik mal an den längeren Winterabenden annehmen.

Zur Klarstellung: Die SSH-Versuche kamen meiner Meinung nach alle ohne Zertifikate an. Es wurden diverse Usernamen versucht: root, admin, user1, user2 und dergleichen.
Aber es kommt ja erst nach der Eingabe des Usernamen zur Fehlermeldung, dass das PublicKey-Verfahren eingeschaltet ist (auch wenn User/Password ausgeschaltet ist).
Wenn der Eindringling also ein 0815-script verwendet, dann achtet er wahrscheinlich nicht auf den Hinweis im Return.
Und müllt mir das log voll.