Unmöglich?

  • Thread starter Thread starter Deleted member 14254
  • Start date Start date
D

Deleted member 14254

Guest
Hallo liebes Forum,

Habe bei meinem heutigen Check etwas komisches bemerkt:

Zunächst checke ich bei meinen Kontrollen logs wie:

Code:
/var/log/auth.log
/var/log/syslog
/var/log/messages

Ich schaue nach, was mir iptables sagt. Ob Sperregeln aufgestellt wurden.

Alles negativ. Nirgendwo etwas verdächtiges.

Da Website usw noch nicht fertig sind, läuft lediglich ssh. Damit ich halt reinkomme in den Server.

Schutzmechanismen:

PubKey-Auth 16kbit-Schlüssel. Passphrase >32Zeichen...
Umgebogener Port
fail2ban

Auffälligkeiten NICHTS! (Beim Checken meine ich)

Schaute dann noch mit:

Code:
netstat --tcp
netstat --udp
netstat -nelpt

nach und entdecke dies:

Code:
~ # netstat --tcp
Aktive Internetverbindungen (ohne Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp   730512      0 servername.domain.tld:56085 static.83.2.47.78.c:ssh VERBUNDEN  
tcp        0    208 servername.domain.tld:umgebogener Port pXXXXXXXX.dip0.t-:47223 VERBUNDEN

Letzteres - das bin ICH... AAAAber... wer ist der andere???!!! Vor allem, wie kommt er an Status verbunden? Er kann nicht verbunden sein, da müsste er schon den private-Key meiner PubKey-Auth besitzen. Und das schließe ich mit großer Sicherheit aus. Ausserdem müsste er noch die Passphrase dafür haben... Auch schwer für ihn daran zu kommen, (weil ich diese selbstverständlich nirgends gespeichert habe)...

Zufall, das jemand versucht hat auf den Server zu kommen, aber dies nicht funktioniert hat? Nur warum steht dann in den Logs nichts? Und... warum Status "VERBUNDEN"??? Soll ich mir jetzt richtig fett Sorgen machen oder Schuss ins Blaue?

Edit: Auf die IP 83.2.47.78 hab ich mal eine Whois gestartet:

Results for 83.2.47.78 :

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '83.2.47.0 - 83.2.47.255'

inetnum: 83.2.47.0 - 83.2.47.255
netname: PPUH-OLKO
descr: P.P.U.H OLKO sp. z.o.o
descr: ul.Kosciuszki 12-14
descr: 98-330 Pajeczno
country: PL
admin-c: TK2547-RIPE
tech-c: PK3309-RIPE
status: ASSIGNED PA
mnt-by: TPNET
source: RIPE # Filtered

person: Przemyslaw Kudyba
address: P.P.U.H "OLKO" sp. z.o.o.
address: ul. Zagrodowa 24
address: 98-355 Trebaczew
address: POLAND
phone: +48 606 502469
nic-hdl: PK3309-RIPE
mnt-by: TPNET
source: RIPE # Filtered

person: Tomasz Koperski
address: P.P.U.H "OLKO" sp. z.o.o
address: ul. Mickiewicza 106a
address: 98-330 Pajeczno
address: POLAND
phone: +48 34 3112749
phone: +48 502 553645
nic-hdl: TK2547-RIPE
mnt-by: TPNET
source: RIPE # Filtered

% Information related to '83.0.0.0/13AS5617'

route: 83.0.0.0/13
descr: TPNET
descr: for abuse: abuse@tpnet.pl
origin: AS5617
mnt-by: AS5617-MNT
source: RIPE # Filtered
 
Last edited by a moderator:
Das ist eine ausgehende Verbindung. Der Server hat also irgendwo hin eine SSH Verbindung aufgebaut. Poste doch bitte mal ein "ps faux".
 
Hallo Firewire2002,

vielen Dank, das Du Dich so schnell meines Problems angenommen hast!!!

Hier die Ausgabe von "ps faux":

Code:
# ps faux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0      0     0 ?        S    14:35   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/u:0]
root         6  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/0]
root         7  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/1]
root         8  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/1:0]
root         9  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/1]
root        10  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/0:1]
root        11  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/2]
root        12  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/2:0]
root        13  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/2]
root        14  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/3]
root        15  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/3:0]
root        16  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/3]
root        17  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/4]
root        18  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/4:0]
root        19  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/4]
root        20  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/5]
root        21  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/5:0]
root        22  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/5]
root        23  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/6]
root        24  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/6:0]
root        25  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/6]
root        26  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/7]
root        27  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/7:0]
root        28  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/7]
root        29  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/8]
root        30  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/8:0]
root        31  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/8]
root        32  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/9]
root        33  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/9:0]
root        34  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/9]
root        35  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/10]
root        36  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/10:0]
root        37  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/10]
root        38  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [migration/11]
root        39  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/11:0]
root        40  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [ksoftirqd/11]
root        41  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [cpuset]
root        42  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [khelper]
root        43  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [netns]
root       344  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [sync_supers]
root       346  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [bdi-default]
root       348  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [kblockd]
root       496  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [ata_sff]
root       507  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [khubd]
root       514  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [md]
root       565  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [cfg80211]
root       666  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [rpciod]
root       667  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/2:1]
root       721  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kswapd0]
root       722  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [fsnotify_mark]
root       723  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [nfsiod]
root       725  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [crypto]
root       915  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [scsi_eh_0]
root       918  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [scsi_eh_1]
root       921  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [scsi_eh_2]
root       924  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [scsi_eh_3]
root       927  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [scsi_eh_4]
root       930  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [scsi_eh_5]
root       936  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/u:6]
root      1009  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/0:2]
root      1016  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [kpsmoused]
root      1074  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [deferwq]
root      2674  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [md0_raid1]
root      2695  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [md1_raid1]
root      2712  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [md2_raid1]
root      2731  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [md3_raid1]
root      2738  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [jbd2/md2-8]
root      2739  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [ext4-dio-unwrit]
root      2764  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/3:1]
root      2766  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/7:1]
root      2770  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/4:1]
root      2775  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/11:1]
root      2776  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/8:1]
root      2779  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/5:1]
root      2781  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/1:1]
root      2792  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/9:1]
root      2832  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/6:1]
root      3095  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [kworker/10:2]
root      3281  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [jbd2/md1-8]
root      3282  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [ext4-dio-unwrit]
root      3283  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [jbd2/md3-8]
root      3284  0.0  0.0      0     0 ?        S<   14:35   0:00  \_ [ext4-dio-unwrit]
root      3878  0.0  0.0      0     0 ?        S    14:35   0:00  \_ [flush-9:2]
root         1  0.0  0.0  22104   704 ?        Ss   14:35   0:00 init [3]   
root      2870  0.0  0.0  74260  1368 ?        Ss   14:35   0:00 /sbin/udevd --daemon
root      3357  0.0  0.0  74320   992 ?        S    14:35   0:00  \_ /sbin/udevd --daemon
root      3358  0.0  0.0  74056   728 ?        S    14:35   0:00  \_ /sbin/udevd --daemon
root      3534  0.0  0.0   9104   540 ?        Ss   14:35   0:00 mdadm --monitor --scan --daemonise --pid-file /var/run/mdadm.pid --s
root      3733  0.0  0.0  44076   192 ?        S    14:35   0:00 supervising syslog-ng
root      3734  0.0  0.0  73940  3136 ?        Ss   14:35   0:00  \_ /usr/sbin/syslog-ng
root      3749  0.0  0.0 837616  7220 ?        Sl   14:35   0:01 /usr/bin/python2.7 /usr/bin/fail2ban-server -b -s /var/run/fail2ban/
ntp       3815  0.0  0.0  82728  2104 ?        Ss   14:35   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u ntp:ntp
root      3830  0.0  0.0  84256   964 ?        Ss   14:35   0:00 /usr/sbin/sshd
root      3881  0.0  0.0  60200  3084 ?        Ss   14:37   0:00  \_ sshd: root@pts/0 
root      3883  0.0  0.0  43216  2380 pts/0    Ss   14:38   0:00      \_ -bash
root      3954  0.0  0.0  63220  1252 pts/0    R+   15:12   0:00          \_ ps faux
root      3859  0.0  0.0  28376   804 ?        Ss   14:35   0:00 /usr/sbin/cron
root      3872  0.0  0.0  61936  1012 tty1     Ss+  14:35   0:00 /sbin/agetty 38400 tty1 linux
root      3873  0.0  0.0  49720  1012 tty2     Ss+  14:35   0:00 /sbin/agetty 38400 tty2 linux
root      3874  0.0  0.0  29692  1008 tty3     Ss+  14:35   0:00 /sbin/agetty 38400 tty3 linux
root      3875  0.0  0.0  38900  1012 tty4     Ss+  14:35   0:00 /sbin/agetty 38400 tty4 linux
root      3876  0.0  0.0  39000  1012 tty5     Ss+  14:35   0:00 /sbin/agetty 38400 tty5 linux
root      3877  0.0  0.0  57220  1012 tty6     Ss+  14:35   0:00 /sbin/agetty 38400 tty6 linux

Bin blöd gewesen, habe vorhin einen Neustart gemacht weil ich sehen wollte ob sich dort wieder was verbindet... Evtl wichtiges für uns zum Herausfinden, zerstört dabei...
 
Last edited by a moderator:
Sieht ganz so aus. Bitte ein "netstat -antpu" noch.
Aber würde sagen, durch deinen Reboot hast du erfolgreich viele Spuren vernichtet.
 
Um in netstat den Status "Verbunden" zu bekommen muss lediglich die TCP-Verbindung etabliert worden sein - also SYN+SYN-ACK.
Das erhältst du bereits, wenn du noch nichtmal mit dem SSH-Dienst richtig kommunziert hast (geschweige denn der Schlüsselaustausch vorgenommen wurde).
 
@Firewire2002,

Ja, Sorry, ich habe nur einen riesigen Schrecken bekommen. Auch deshalb, weil ich das Teil so abgeschottet habe. Es lief ausser ssh ja auch kein Dienst. Die schalte ich nur dann ein, wenn ich arbeite, zudem sind die Seiten hinter einer .htaccess. Also das mir da jemand irgendwelche php-Schädlinge aufgrund unfertiger Seite installiert haben könnten, kann ich ausschliessen. Port 80/443 waren geschlossen. Die Mailserver-Ports ebenfalls (25/110/465 usw).

Hier die Ausgabe von "netstat -antpu"

Code:
netstat -antpu
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:umgebogener_Port           0.0.0.0:*               LISTEN      3834/sshd           
tcp        0    256 server-ip:Port:umgebogener_Port       meine-ip-zugreifender-rechner:48067       VERBUNDEN   3897/0              
tcp6       0      0 :::umgebogener_Port                :::*                    LISTEN      3834/sshd           
udp        0      0 server-ip:123          0.0.0.0:*                           3819/ntpd           
udp        0      0 127.0.0.1:123           0.0.0.0:*                           3819/ntpd           
udp        0      0 0.0.0.0:123             0.0.0.0:*                           3819/ntpd           
udp6       0      0 :::123                  :::*                                3819/ntpd

@LordGurke,

Auch Dir vielen Dank für Deine Hilfe!
Deinen Worten nach könnte dies bedeuten, das jemand versucht hat, mit dem ssh-Dienst Kontakt aufzunehmen, dies aber nicht geklappt hat, weshalb auch keine entspr. Dinge im auth.log zu finden waren. Es kam kein Login zustande. Der Server könnte dorthin "Verbunden" haben, weil jemand per ssh seine ip anforderte. Meinst Du das so?
 
Last edited by a moderator:
Dein Server wurde in dem Fall nicht "angegriffen". Eher andersherum. Du warst der Ursprung der Verbindung, nicht das Ziel!
Also entweder hast du selbst eine SSH Session im Screen oder Background vergessen oder jemand anderes hat dein System bereits kompromitiert.
 
Also das jemand das System vor dem Beobachten der seltsamen ausgehenden Verbindung kompromittiert hätte, kann ich fast ausschliessen. Der Server läuft ausschliesslich per PubKey-Auth, die Dienste Apache MySQL Mail-relevantes laufen nur wenn ich an ihm arbeite... Ansonsten wirklich nur ssh...

Letzte Woche hatte ich mal während meiner Arbeit im apache_access ein der hier Euch auch bekannten "w00tw00t---Anfrage" Doch im error_log fand ich dann, das der "Client" aufgrund meiner Server-Configuration abgewiesen wurde (.htaccess) - Komische Sache.

Nur das ich Ursprung der Verbindung gewesen sein könnte ist mir rätselhaft. Laut meines "Whois" auf die IP kam heraus, das diese aus Polen stammt. Eine statische IP aus Polen. Die kann ich ja schlecht selbst haben, damit etwas verursacht haben...

Die Update-Mirrors für mein System liegen auch bei meinem Serverhoster selbst. (Er hat eigene gentoo-mirrors) Ebenso die ntpd-Server. Das habe ich gemacht, damit er für die Services lediglich mit dem Serverhoster Kontakt aufnehmen kann...

Ich checke täglich grundsätzlich alle relevanten logs auf Spuren. Ich hatte niemals eine zweite Verbindung von einer anderen IP als meiner. Manchmal passierte es, das ich 2mal vorhanden war, weil ich zulange angemeldet war, doch niemals von jemand anderem als mir selbst... (Ich sehe das an der hostmaske, da ich hier auch eine feste ip habe)
 
Last edited by a moderator:
Es gibt ja auch noch SSH-Tunnel - die abgehende Verbindung könnte also durchaus auch von einem rsync-Prozess oder SFTP stammen oder irgendwas anderem was durch SSH getunnelt werden könnte.

Zudem ist mir aufgefallen, dass die IP die du im WHOIS nachgeschlagen hast, nicht die sein wird die in netstat angezeigt wurde.
Wenn deren Name nämlich so weitergeht wie ich glaube lautet er nämlich "static.83.2.47.78.clients.your-server.info" - das sind die Standard-PTRs von Hetzner. Und die schrieben die IP-Adressen wie in der in-addr.arpa-Zone in umgekehrter Reihenfolge ;)

Sollte ich damit richtig liegen wäre die richtige IP die 78.47.2.83 nach der du fahnden müsstest - und das ist dann in der Tat eine IP-Adresse von Hetzner, genauer gesagt ein Backup-Server von denen.
Er meldet sich zumindest im FTP-Banner als "220 ProFTPD 1.3.4b Server (Hetzner Backup) [::ffff:78.47.2.83]" ;)

Damit wäre ich dann wieder am Ausgangspunkt - verwendest du rsync für Backups? :D
 
Last edited by a moderator:
Hallo Joe User,

PAM ist deaktiviert.

Code:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

Mit der ntp-Sache bin ich mir unsicher. Ich hatte ntp damals laufen. Den ntp-client. Da dies aber mit dovecot Probleme gibt, habe ich die Configuration auf ntpd geändert, damit mir dovecot nicht gekilled wird.

Ich bin nach dieser How-To vorgegangen: http://en.gentoo-wiki.com/wiki/NTP

Dort habe ich aber niemals die Restrictionen kommentiert.

Habe mal nachgesehen:

Code:
# Warning: Using default NTP settings will leave your NTP
# server accessible to all hosts on the Internet.

# If you want to deny all machines (including your own)
# from accessing the NTP server, uncomment:
#restrict default ignore

Hau mich, Joe, ist das, weil ich falsch verstanden habe, was dort genau gemeint ist...

Also "Wenn Sie allen Maschinen (incl. Ihrer eigenen) den Zugriff auf den ntp-Server verbieten wollen kommentieren sie die folgende Zeile aus..."

- Verstanden.

Nur habe ich es wahrscheinlich so verstanden, das WENN AUSKOMMENTIERT ist, ist von aussen erreichbar. Somit liess ich sie...kommentiert :o:o

Edit: Meinst Du das so? Weil ich habe sie nun auskommentiert und das Resultat bei "netstat -antpu" ist das Gleiche...
 
Last edited by a moderator:
Es gibt ja auch noch SSH-Tunnel - die abgehende Verbindung könnte also durchaus auch von einem rsync-Prozess oder SFTP stammen oder irgendwas anderem was durch SSH getunnelt werden könnte.

Zudem ist mir aufgefallen, dass die IP die du im WHOIS nachgeschlagen hast, nicht die sein wird die in netstat angezeigt wurde.
Wenn deren Name nämlich so weitergeht wie ich glaube lautet er nämlich "static.83.2.47.78.clients.your-server.info" - das sind die Standard-PTRs von Hetzner. Und die schrieben die IP-Adressen wie in der in-addr.arpa-Zone in umgekehrter Reihenfolge ;)

Sollte ich damit richtig liegen wäre die richtige IP die 78.47.2.83 nach der du fahnden müsstest - und das ist dann in der Tat eine IP-Adresse von Hetzner, genauer gesagt ein Backup-Server von denen.
Er meldet sich zumindest im FTP-Banner als "220 ProFTPD 1.3.4b Server (Hetzner Backup) [::ffff:78.47.2.83]" ;)

Damit wäre ich dann wieder am Ausgangspunkt - verwendest du rsync für Backups? :D

Ich sichere Serverimages bei hetzner, ja. Auf dem sftp bei denen, ja. Omann, evtl liegt es daran... Mir fällt da folgendes ein: Ich erstelle jedesmal 2 Images, ein gpg-verschlüsseltes, eines ohne Verschlüsselung. Die Images lade ich hinterher auf meinen Server runter, dann auf meinen PC hier. (Auf dem SFTP - also Backup-Space werden die unverschlüsselten aber jedesmal (von mir) wieder gelöscht, weil ich keine unverschl. Images auf Fremden Servern haben möchte. Da es beim Updateserver bei Hetzner ab und wann Probleme gibt, könnte ich per ssh auch von hier aus ein Image (unverschlüsseltes) per ssh (wobei der Weg ja wieder verschlüsselt ist) über das Rescue auf den Server entpacken.
So, solch ein Problem gab es am Freitag, also vorgestern. Ich brach den Vorgang mit "STRG + C" ab, da es zu einem Timeout beim Herunterladen der Images von SFTP -> mein Server kam. Evtl bliebt dies im Hintergrund hängen... Mann bin ich d**f :(((

Jetzt, wo Du es sagst... fällt mir die umgekehrte Adresse auch auf...
 
Last edited by a moderator:
Hallo liebes Forum :)

Ich gebe mal Entwarnung! Es war so, wie LordGurke schon richtig vermutet hatte!

Habe heute nochmal Backups erstellt und mit einem 2ten Terminal beobachtet, wohin verbunden wird währenddessen:

Code:
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0    208 servername.domain.tld:Port xxxxxxxx.dip0.t-:44630 VERBUNDEN <- ICH per SSH verbunden
tcp        0      0 servername.domain.tld:56849 static.83.2.47.78.c:ssh TIME_WAIT <- Upload-Progress zum FTP-Server von Hetzner

:o:p Trotzdem, graue Haare hab ich wieder paar mehr auf dem Kopf nun ;)
 
Back
Top