Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)PO
Posts
43
Comments
438
Joined
10 mo. ago

  • DO NOT follow my lead, my backup solution is scuffed at best.

    3:

    I have:

    • RAID1 array w/ 2 drives
    • Photos on the device that took them
    • Photos on a random old hard drive pulled from an ancient apple mac.

    2:

    I've got a hard drive and flash memory?

    1:

    Don't have this at all, the closest is that my phone is off-site half of the day.

  • yes, the host is 192.168.86.73 and it has that dnat rule.

    And from the guest

    Assuming you meant from the host, I am sshing directly to 192.168.101.4 instead of to 192.168.86.73:2222.

    The third paragraph doesn't make sense to me. I am using port 22 on my host(192.168.86.73) for it's own ssh.

    tcpdump returns this when I ssh to port 2222:

     
        
    20:32:29.957942 IP (tos 0x10, ttl 64, id 28091, offset 0, flags [DF], proto TCP (6), length 60)
        192.168.86.23.53434 > 192.168.86.73.2222: Flags [S], cksum 0x5d75 (correct), seq 1900319834, win 64240, options [mss 1460,sackOK,TS val 3627223725 ecr 0,nop,wscale 7], length 0
    
      
  • 192.168.101.4 is the alma guest. It's got port 22 open and I can ssh into it from the host computer.

    iptables -nvL on Alma returns:

     
        
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    
      

    I believe this means it automatically accepts connections.

    IMO this makes it unlikely that the guest is the issue.

  • ssh -v returns:

     
        
    OpenSSH_9.2p1 Debian-2+deb12u4, OpenSSL 3.0.15 3 Sep 2024
    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 *
    debug1: Connecting to 192.168.86.73 [192.168.86.73] port 2222.
    debug1: connect to address 192.168.86.73 port 2222: Connection refused
    ssh: connect to host 192.168.86.73 port 2222: Connection refused
    
    
      
  • From the iptables manpage:

     
        
    --to offset
        Set the offset from which it starts looking for any matching. If not passed, default is the packet size. 
    
    ...
    
    --to-destination ipaddr-ipaddr
        Address range to round-robin over. 
    
    
      

    This seems to do something, but the port still appears as closed.

    iptables -nvL returns:

     
        
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    Chain FORWARD (policy ACCEPT 369 packets, 54387 bytes)
     pkts bytes target     prot opt in     out     source               destination         
        5   300 ACCEPT     6    --  *      virbr1  0.0.0.0/0            192.168.101.4        tcp dpt:22
       84  6689 ACCEPT     0    --  *      br-392a16e9359d  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
        7   418 DOCKER     0    --  *      br-392a16e9359d  0.0.0.0/0            0.0.0.0/0           
      146  9410 ACCEPT     0    --  br-392a16e9359d !br-392a16e9359d  0.0.0.0/0            0.0.0.0/0           
        0     0 ACCEPT     0    --  br-392a16e9359d br-392a16e9359d  0.0.0.0/0            0.0.0.0/0           
    
    Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination                    
    
    
      

    I've omitted some listings that were labelled as docker.

    iptables -t nat -nvL returns:

     
        
    Chain PREROUTING (policy ACCEPT 626 packets, 90758 bytes)
     pkts bytes target     prot opt in     out     source               destination         
        5   300 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2222 to:192.168.101.4:22
    
    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination         
    
    Chain OUTPUT (policy ACCEPT 154 packets, 12278 bytes)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 DOCKER     0    --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL
    
    Chain POSTROUTING (policy ACCEPT 290 packets, 22404 bytes)
     pkts bytes target     prot opt in     out     source               destination         
        0     0 MASQUERADE  0    --  *      !br-392a16e9359d  172.18.0.0/16        0.0.0.0/0           
    
      

    I've also omitted some listings that were labelled as docker.

    After running the ssh command, the bytes seem to increase. After 1 ssh attempt:

     
        
        7   420 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2222 to:192.168.101.4:22
    
    
      

    After another ssh attempt:

     
        
        8   480 DNAT       6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:2222 to:192.168.101.4:22