Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Turns out the request is coming from localhost because it's being forwarded over SSH. Their HTTP proxy causes a new SSH connection to be made to the VM:

    Connection from 10.42.0.1 port 37456 on 10.42.1.75 port 22 rdomain ""              
    debug1: Local version string SSH-2.0-OpenSSH_9.9                                   
    debug1: Remote protocol version 2.0, remote software version Go                    
    debug1: compat_banner: no match: Go
Which then requests a local TCP connection, in this case to port 8000:

    debug1: Entering interactive session for SSH2.                                    
    debug1: server_init_dispatch                                                       
    debug3: receive packet: type 90                                                    
    debug1: server_input_channel_open: ctype direct-tcpip rchan 0 win 2097152 max 32768
    debug1: server_request_direct_tcpip: originator 0.0.0.0 port 0, target 127.0.0.1 port 8000
    debug1: connect_next: start for host 127.0.0.1 ([127.0.0.1]:8000)                  
    debug2: fd 7 setting O_NONBLOCK                                                    
    debug2: fd 7 setting TCP_NODELAY                                                   
    debug1: connect_next: connect host 127.0.0.1 ([127.0.0.1]:8000) in progress, fd=7
    debug3: fd 7 is O_NONBLOCK                                                           
    debug3: fd 7 is O_NONBLOCK                                                          
    debug1: channel 0: new direct-tcpip [direct-tcpip] (inactive timeout: 0)           
    debug1: server_input_channel_open: confirm direct-tcpip                         
    debug3: channel 0: waiting for connection
This is in contrast to a normal SSH shell session:

    debug1: Entering interactive session for SSH2.                                     
    debug1: server_init_dispatch                                                       
    debug3: receive packet: type 90                                                     
    debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
    debug1: input_session_request                                                      
    debug1: channel 0: new session [server-session] (inactive timeout: 0)
    debug2: session_new: allocate (allocated 0 max 10)                                 
    debug3: session_unused: session id 0 unused                                          
    debug1: session_new: session 0                                                      
    debug1: session_open: channel 0                                                    
    debug1: session_open: session 0: link with channel 0                               
    debug1: server_input_channel_open: confirm session                                 
    debug3: send packet: type 91                                                        
    debug3: receive packet: type 98                                                    
    debug1: server_input_channel_req: channel 0 request pty-req reply 1
    debug1: session_by_channel: session 0 channel 0                                    
    debug1: session_input_channel_req: session 0 req pty-req                           
    debug1: Allocating pty.


Also there's a funny little Easter egg within the SSH connection to exe.dev, if you look closely. I don't want to spoil it for anyone, but it was nice to see.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: