search

majuss / easybox904

This is a step by step guide to open your easybox 904 xDSL for the usage with every provider, without MIC.
56 stars 18 forks source link

Ssh Connection refused #44

Closed frodo3210 closed 4 years ago

frodo3210 commented 4 years ago

Hey,

ich habe absolut keinen Plan von dem was hier so passiert, versuche es nur genauso wie beschrieben auszuführen. Ich habe die Firmware wie beschrieben geupdatet, den Stick mit der Datei angeschlossen und neu gestartet. Wenn ich über den in 4. beschriebenen Code in CMD versuche zuzugreifen, kommt sofort: ssh: connect to host easy.box port 22: connection refused. Leider komme ich da nicht weiter und auch bei den anderen Problemlösungen finde ich nichts für mich. Ich hoffe du kannst mir helfen.

VG

majuss commented 4 years ago

Wie hast du die Datei sesame.txt erstellt? Es liegt mit hoher Wahrscheinlichkeit an dem Stick und/oder der Datei.

frodo3210 commented 4 years ago

hab den Stick als fat32 formatiert und die Datei über die Anleitung runtergeladen, als das nicht ging, hab ich sie über notepad++ erstellt, wie in der Anleitung beschrieben.

ropasch commented 4 years ago

Hi, ich hatte auch probleme SSH zum laufen zu bringen (vermutlich der Stick) Hab nach "3.Create..." (top guide, danke!) ein img erstellt und in etc/init.d/dropbear in start() ssh auf AlwaysOn gestellt. 

start()
{
    ccfg_cli set AlwaysOn@ssh=on
    ccfg_cli commitcfg
    /usr/sbin/arc_dropbear start
    test $? -ne 0 && return
    config_load "${NAME}"
    config_foreach dropbear_start dropbear
}

Ist vermutlich keine besonders schöne Lösung, aber SSH ist direkt beim ersten boot nach dem flashen verfügbar ohne sesame Stick. Hier das modifizierte fullimage_sshAlwaysOn.img

Viele Grüße

majuss commented 4 years ago

Danke dir, wenn noch jemand anderes die Funktionalität bestätigen kann, werde ich es dauerhaft aufnehmen.

dirk234 commented 4 years ago

Hallo, tolle Anleitung, danke dafür! Mir ist es trotz fehlender Programmierkenntnisse gelungen, die Easybox für DSL mit einem neuen Telekom-Anschluss zum Laufen zu bringen. Telefon funktioniert aber leider noch nicht :-( Evtl. liegt es daran, dass ich ein analoges / DECT-Telefon nutze? Sind hierfür weitere Einstellungen nötig? Könntest Du hier nochmal helfen, majuss? Das wäre super.

Das o.a. Problem mit der nicht herstellbaren SSH-Verbindung hatte ich übrigens auch. Bei mir hat es geholfen, das DSL-Kabel aus der Easybox zu ziehen u. den USB-Stick (nochmal) einzustecken.

Viele Grüße

majuss commented 4 years ago

Alle Einstellungen beim VOIP Abteil sollten eingetragen werden. Welcher Fehlercode erscheint denn?

dirk234 commented 4 years ago

Hm. Es erscheint kein richtiger Fehlercode. In der graphischen Übersicht der angeschlossenen Geräte wird zwar ein Telefon aufgeführt, aber die Anzeige zeigt an "keine Geräte verbunden". Als Fehlercode erscheint 819 "Es liegt eine netzinterne Störung vor, welche die Funktion Ihres Anschlusses aber nicht beeinträchtigen dürfte".

majuss commented 4 years ago

819 ist ja auch interessant... Sicher das alles richtig verkabelt ist? Wie hast du die Tel-Nr eingegeben?

dirk234 commented 4 years ago

Ich habe den Telefonstecker in der linken und in der mittleren Buchse probiert. Die Tel-Nr ist doch in dem Coding enthalten?! Die Vorwahl habe ich unter [AreaCode] erfasst, die Tel-Nr unter [PhoneNumber]. Wenn ich die Nummer von extern anrufe kommt eine Telekom-Mailbox mit der Ansage der Nummer.

majuss commented 4 years ago

Also Vorwahl hast du 030 für zB. Berlin genommen? Nicht +49 ;)

dirk234 commented 4 years ago

ja genau. Die Städtevorwahl sozusagen.

majuss commented 4 years ago

Du kannst dir mal die geschlossenen Issues angucken ob du dort Hinweise findest die dir helfen... mir fällt grad auch nichts konkrete ein. Vlt. haut auch einer der Server nicht mehr hin etc.

https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients?samChecked=true

Vlt. fehlt auch der Stunserver... kein Plan ob der wichtig ist.

dirk234 commented 4 years ago

ok. Danke Dir. Ich gucke das mal durch.

dirk234 commented 4 years ago

ich hatte gehofft, dass ich das falsche Telefon habe ;-)

dirk234 commented 4 years ago

wenn das nicht klappt muss ich wohl doch noch eine Fritzbox kaufen.

majuss commented 4 years ago

Ich hab gar kein Festnetz mehr angeschlossen :) Hat ja heutzutage auch keinen Mehrwert mehr, wenn eigentlich eh so ziemlich jeder eine Flatrate hat.

maxgit33 commented 4 years ago

english version below

Hallo Zusammen,

ropasch

Hi, ich hatte auch probleme SSH zum laufen zu bringen (vermutlich der Stick) Hab nach "3.Create..." (top guide, danke!) ein img erstellt und in etc/init.d/dropbear in start() ssh auf AlwaysOn gestellt.

start()
{
  ccfg_cli set AlwaysOn@ssh=on
  ccfg_cli commitcfg
  /usr/sbin/arc_dropbear start
  test $? -ne 0 && return
  config_load "${NAME}"
  config_foreach dropbear_start dropbear
}

Ist vermutlich keine besonders schöne Lösung, aber SSH ist direkt beim ersten boot nach dem flashen verfügbar ohne sesame Stick. Hier das modifizierte fullimage_sshAlwaysOn.img

Viele Grüße

majuss Danke dir, wenn noch jemand anderes die Funktionalität bestätigen kann, werde ich es dauerhaft aufnehmen.

Die Funktionalität kann ich bestätigen, allerdings ist dieses Feature meiner Meinung nach ein unnötiges Sicherheitsrisiko. Damit könnte dann jeder Client im LAN administrativ auf den Router zugreifen, wenn er das Passwort "123456" errät.

Ich war anfangs zu ungeduldig mit dem sesame-Stick. Es braucht tatsächlich mehrere Minuten, bis der Router den ssh port freigibt. Nachdem der dhcp-server mir eine IP zugewiesen hatte, hatte ich sofort versucht per ssh zuzugreifen, leider erfolglos. Wenn ich lange genug warte, klappt es aber.

Da @ropasch in seinem Fork leider die Issues deaktiviert hat, hier noch eine Anmerkung:

Das hier verlinkte fullimage_sshAlwaysOn.img weißt schwere Sicherheitslücken auf. Ein Portscan auf WAN-Seite (DSL, öffentliches Internet) ergibt:

Nmap scan report for 10.67.15.2
Host is up (0.0067s latency).
Not shown: 65533 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
53/tcp  open  domain
515/tcp open  printer

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 26.33 seconds
           Raw packets sent: 66172 (2.912MB) | Rcvd: 65537 (2.621MB)
Nmap scan report for 10.67.15.2
Host is up (0.00080s latency).
Not shown: 778 open|filtered ports, 221 closed ports
PORT    STATE SERVICE
161/udp open  snmp

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 215.83 seconds
           Raw packets sent: 2595 (75.129KB) | Rcvd: 223 (12.652KB)

Der sshd ist somit von öffentlicher Seite verfügbar, mit root:123456 hat jedermann Zugriff auf den Router. Der snmp Service gibt viele Informationen preis und kann für Dritte für einen DDoS-Reflection-Angriff verwendet werden.

Mal abgesehen von SIP und VPN sollte meines Erachtens gar kein Port auf dieser Seite offen sein.

Ein diff zwischen den Systemen fullimage_AT904X-04.13.img sha256: 4561b3fab4c5508eed25369769ce021bee882e65747b6e32c6008afa1a73f72f und fullimage_sshAlwaysOn.img sha256: a80b7c6786209d33ef888d18aecd78d0fb957389c3e0f21e89e240a160c54c5d nach unsquash zeigt:

$diff -n -r --no-dereference majuss ropasch
diff -n -r --no-dereference majuss/etc/init.d/dropbear ropasch/etc/init.d/dropbear
a70 2
        ccfg_cli set AlwaysOn@ssh=on
        ccfg_cli commitcfg
a140 1

Nur in majuss/lib/modules/2.6.32.32: ipt_ecn.ko.
Binärdateien majuss/lib/modules/2.6.32.32/ipt_ECN.ko und ropasch/lib/modules/2.6.32.32/ipt_ECN.ko sind verschieden.
Nur in majuss/lib/modules/2.6.32.32: xt_hl.ko.
Binärdateien majuss/lib/modules/2.6.32.32/xt_HL.ko und ropasch/lib/modules/2.6.32.32/xt_HL.ko sind verschieden.
Nur in majuss/usr/lib/iptables: libip6t_hl.so.
Binärdateien majuss/usr/lib/iptables/libip6t_HL.so und ropasch/usr/lib/iptables/libip6t_HL.so sind verschieden.
Nur in majuss/usr/lib/iptables: libipt_ecn.so.
Binärdateien majuss/usr/lib/iptables/libipt_ECN.so und ropasch/usr/lib/iptables/libipt_ECN.so sind verschieden.
Nur in majuss/usr/lib/iptables: libxt_connmark.so.
Binärdateien majuss/usr/lib/iptables/libxt_CONNMARK.so und ropasch/usr/lib/iptables/libxt_CONNMARK.so sind verschieden.
Nur in majuss/usr/lib/iptables: libxt_dscp.so.
Binärdateien majuss/usr/lib/iptables/libxt_DSCP.so und ropasch/usr/lib/iptables/libxt_DSCP.so sind verschieden.
Nur in majuss/usr/lib/iptables: libxt_mark.so.
Binärdateien majuss/usr/lib/iptables/libxt_MARK.so und ropasch/usr/lib/iptables/libxt_MARK.so sind verschieden.
Nur in majuss/usr/lib/iptables: libxt_tcpmss.so.
Binärdateien majuss/usr/lib/iptables/libxt_TCPMSS.so und ropasch/usr/lib/iptables/libxt_TCPMSS.so sind verschieden.
Nur in majuss/usr/lib/iptables: libxt_tos.so.
Binärdateien majuss/usr/lib/iptables/libxt_TOS.so und ropasch/usr/lib/iptables/libxt_TOS.so sind verschieden.

english version

Hello everyone,

ropasch

Hi, ich hatte auch probleme SSH zum laufen zu bringen (vermutlich der Stick) Hab nach "3.Create..." (top guide, danke!) ein img erstellt und in etc/init.d/dropbear in start() ssh auf AlwaysOn gestellt.

start()
{
  ccfg_cli set AlwaysOn@ssh=on
  ccfg_cli commitcfg
  /usr/sbin/arc_dropbear start
  test $? -ne 0 && return
  config_load "${NAME}"
  config_foreach dropbear_start dropbear
}

Ist vermutlich keine besonders schöne Lösung, aber SSH ist direkt beim ersten boot nach dem flashen verfügbar ohne sesame Stick. Hier das modifizierte fullimage_sshAlwaysOn.img

Viele Grüße

majuss Danke dir, wenn noch jemand anderes die Funktionalität bestätigen kann, werde ich es dauerhaft aufnehmen.

I can confirm the functionality, but in my opinion this is an unnecessary security risk. Every client inside the LAN would have adminitrative access guessing the password "123456"

It takes several minutes until the router gives access to the ssh port with the sesame.txt on flashdrive. I was too impatient. I tried to access right after the dhcp gave me an ip, but it is too early.

@ropasch has disabled issues on his fork, so here an annotation:

The img linked in this thread, fullimage_sshAlwaysOn.img has severe security issues. A portscan on WAN-side (DSL, public Internet) shows:

Nmap scan report for 10.67.15.2
Host is up (0.0067s latency).
Not shown: 65533 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
53/tcp  open  domain
515/tcp open  printer

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 26.33 seconds
           Raw packets sent: 66172 (2.912MB) | Rcvd: 65537 (2.621MB)
Nmap scan report for 10.67.15.2
Host is up (0.00080s latency).
Not shown: 778 open|filtered ports, 221 closed ports
PORT    STATE SERVICE
161/udp open  snmp

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 215.83 seconds
           Raw packets sent: 2595 (75.129KB) | Rcvd: 223 (12.652KB)

The sshd is available from public, giving everybody access to the router with root:123456 . The snmp service reveals much information and can be used by others for a DDos reflection attack.

Disregarding SIP and VPN there shouldn't be open any ports on WAN.

diff between fullimage_AT904X-04.13.img sha256: 4561b3fab4c5508eed25369769ce021bee882e65747b6e32c6008afa1a73f72f and fullimage_sshAlwaysOn.img sha256: a80b7c6786209d33ef888d18aecd78d0fb957389c3e0f21e89e240a160c54c5d reveals:

$LANG=en diff -n -r --no-dereference majuss ropasch
diff -n -r --no-dereference majuss/etc/init.d/dropbear ropasch/etc/init.d/dropbear
a70 2
        ccfg_cli set AlwaysOn@ssh=on
        ccfg_cli commitcfg
a140 1

Binary files majuss/lib/modules/2.6.32.32/ipt_ECN.ko and ropasch/lib/modules/2.6.32.32/ipt_ECN.ko differ
Only in majuss/lib/modules/2.6.32.32: ipt_ecn.ko
Binary files majuss/lib/modules/2.6.32.32/xt_HL.ko and ropasch/lib/modules/2.6.32.32/xt_HL.ko differ
Only in majuss/lib/modules/2.6.32.32: xt_hl.ko
Binary files majuss/usr/lib/iptables/libip6t_HL.so and ropasch/usr/lib/iptables/libip6t_HL.so differ
Only in majuss/usr/lib/iptables: libip6t_hl.so
Binary files majuss/usr/lib/iptables/libipt_ECN.so and ropasch/usr/lib/iptables/libipt_ECN.so differ
Only in majuss/usr/lib/iptables: libipt_ecn.so
Binary files majuss/usr/lib/iptables/libxt_CONNMARK.so and ropasch/usr/lib/iptables/libxt_CONNMARK.so differ
Binary files majuss/usr/lib/iptables/libxt_DSCP.so and ropasch/usr/lib/iptables/libxt_DSCP.so differ
Binary files majuss/usr/lib/iptables/libxt_MARK.so and ropasch/usr/lib/iptables/libxt_MARK.so differ
Binary files majuss/usr/lib/iptables/libxt_TCPMSS.so and ropasch/usr/lib/iptables/libxt_TCPMSS.so differ
Binary files majuss/usr/lib/iptables/libxt_TOS.so and ropasch/usr/lib/iptables/libxt_TOS.so differ
Only in majuss/usr/lib/iptables: libxt_connmark.so
Only in majuss/usr/lib/iptables: libxt_dscp.so
Only in majuss/usr/lib/iptables: libxt_mark.so
Only in majuss/usr/lib/iptables: libxt_tcpmss.so
Only in majuss/usr/lib/iptables: libxt_tos.so
fpopic commented 1 year ago

I had 04.16 open from vodafone and after I reverted back to AT904X-04.13 but now when trying ssh always getting

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1  root@192.168.2.1 
Unable to negotiate with 192.168.2.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Does this mean that usb drive and sesame.txt is not working? (I tried with 2 different FAT32 usb drives).

majuss commented 1 year ago

Hm sesame seems to be working. Try bare ssh without specific keyalgorithm.

fpopic commented 1 year ago

@majuss 

Current Firmware Version:AT904X-04.13 (Linux 2.6.32.32 #1 Fri Mar 9 15:00:35 CST 2018)
$ ssh  root@192.168.2.1 -vv
OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/fpopic/.ssh/config
debug1: /home/fpopic/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.2.1 is address
debug1: Connecting to 192.168.2.1 [192.168.2.1] port 22.
debug1: Connection established.
debug1: identity file /home/fpopic/.ssh/id_rsa type -1
debug1: identity file /home/fpopic/.ssh/id_rsa-cert type -1
debug1: identity file /home/fpopic/.ssh/id_ecdsa type -1
debug1: identity file /home/fpopic/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/fpopic/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/fpopic/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/fpopic/.ssh/id_ed25519 type -1
debug1: identity file /home/fpopic/.ssh/id_ed25519-cert type -1
debug1: identity file /home/fpopic/.ssh/id_ed25519_sk type -1
debug1: identity file /home/fpopic/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/fpopic/.ssh/id_xmss type -1
debug1: identity file /home/fpopic/.ssh/id_xmss-cert type -1
debug1: identity file /home/fpopic/.ssh/id_dsa type -1
debug1: identity file /home/fpopic/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
debug1: Remote protocol version 2.0, remote software version dropbear_2014.63
debug1: compat_banner: no match: dropbear_2014.63
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.2.1:22 as 'root'
debug1: load_hostkeys: fopen /home/fpopic/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,kexguess2@matt.ucc.asn.au
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
debug2: ciphers stoc: aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
debug2: MACs ctos: hmac-sha1,hmac-md5
debug2: MACs stoc: hmac-sha1,hmac-md5
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: (no match)
Unable to negotiate with 192.168.2.1 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss
majuss commented 1 year ago

Try something like this: ssh -oHostKeyAlgorithms=+ssh-dss root@192.168.2.1

fpopic commented 1 year ago

Thank you, seems my known hosts files were old

ssh -oHostKeyAlgorithms=+ssh-dss root@192.168.2.1  
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the DSA key sent by the remote host is
SHA256:fKG+Ht5EFEe4PswvEr895G5htVJGKsrCEqCyEAUdaxQ.
Please contact your system administrator.
Add correct host key in /home/fpopic/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/fpopic/.ssh/known_hosts:13
  remove with:
  ssh-keygen -f "/home/fpopic/.ssh/known_hosts" -R "192.168.2.1"
Host key for 192.168.2.1 has changed and you have requested strict checking.
Host key verification failed.

  ssh-keygen -f "/home/fpopic/.ssh/known_hosts" -R "192.168.2.1"

solved the issue.