SSH remote over internet w/ Dynamic DNS to Jetson Nano automatically closes

Hi, I’m trying to remotely access my Jetson Nano via SSH as I do on the local network but thought the internet.

However, when I try to connect over the internet, using a Dynamic DNS I’ve setup on my router (tp-link Acher-60), I get “Connection close: IP ADDESS port 22”

Is there anything that I have to change on the Nano before allowing it to connect/ access remotely?

The default is that a Jetson does not need any special ssh setup. If a Jetson sees an incoming ssh connection attempt, then it should “just work”.

The part which I could see possibly having issues is the use of IPv6. The traditional networking every computer has supported since the time of stone wheels is IPv4. In theory IPv6 is also set up without any need for special intervention, but when it comes to special cases use of IPv6 may need some additional configuration (hard to say for sure). An example might be that a firewall rule allows ssh, but it only looks at IPv4 (this is just a contrived example…firewalls are not enabled by default on a Jetson).

Note that ssh has verbose modes supported to help with debugging. If you were to run ssh -vvv, then you’d get a lot of debug output. It is expected that you would see a lot of fails as ssh goes through various tests on its way to connect, e.g., perhaps it checks for a key but you never enabled key pairs for login, and so this would show as a fail (followed by ssh moving on to the next login method). This might take some work, and it is likely the dynamic DNS setup is what is actually in need of configuration.

If you are logged in to the Jetson at the time of the ssh attempt, then you could monitor logs and watch to see if the Jetson even saw the request. If the Jetson does see a request, then you know it is not the dynamic DNS at fault; if no request is visible, then you know the Jetson is not at fault. This will allow you to monitor login attempts from the Jetson:
sudo tail -f /var/log/auth.log
(I recommend doing this prior to any verbose ssh…it is much more efficient if you know which part of the system is failing prior to logging everything)

1 Like

First thank you for taking the time to reply to my query.

so after running verbose on ssh I get the following:

    OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/USR/.ssh/config
debug1: /Users/USR/.ssh/config line 1: Applying options for *
debug1: /Users/USR/.ssh/config line 5: Applying options for MYURL.tplinkdns.com
debug3: kex names ok: [diffie-hellman-group1-sha1]
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug3: kex names ok: [diffie-hellman-group1-sha1]
debug1: Connecting to MYURL.tplinkdns.com port 22.
debug1: Connection established.
debug1: identity file /Users/USR/.ssh/id_rsa type 0
debug1: identity file /Users/URS/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version YDKzg
debug1: no match: YDKzg
debug3: fd 5 is O_NONBLOCK
debug1: Authenticating to MYURL.tplinkdns.com:22 as 'REMOTE-USER'
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
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,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: ssh-dss,ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: MACs ctos: hmac-md5,hmac-sha1,umac-64@openssh.com
debug2: MACs stoc: hmac-md5,hmac-sha1,umac-64@openssh.com
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: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss
debug2: ciphers ctos: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib
debug2: compression stoc: none,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group1-sha1
debug1: kex: host key algorithm: ssh-dss
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-md5 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-md5 compression: none
debug2: bits set: 510/1024
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-dss SHA256:w0OIRAfe5tisNUlpD+69ECmn4fNx1V1EFQzzUrr6OUk
debug3: hostkeys_foreach: reading file "/Users/USR/.ssh/known_hosts"
debug3: record_hostkey: found key type DSA in file /Users/USR/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys from MYURL.tplinkdns.com
debug3: hostkeys_foreach: reading file "/Users/USR/.ssh/known_hosts"
debug3: record_hostkey: found key type DSA in file /Users/USR/.ssh/known_hosts:6
debug3: load_hostkeys: loaded 1 keys from HOST-IP
debug1: Host 'MYURL.tplinkdns.com' is known and matches the DSA host key.
debug1: Found key in /Users/USR/.ssh/known_hosts:6
debug2: bits set: 549/1024
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /Users/USR/.ssh/id_rsa RSA SHA256:WaInPTFU4u8mWZ+cwZe1wZ6Mcu+ffQaaZO7Xf1iTKGo explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
Connection closed by HOST-IP port 22

Edit: ignore this verbose, we’re back to the same output I posted before. Host closes the connection for some reason.

I’ve made some progress (I hope, the verbose has gone shorter)

A friend suggest to modify PermitRootLogin to yes on the sshd_config

after restarting the ssh server I get the following verbose:

OpenSSH_8.1p1, LibreSSL 2.7.3

debug1: Reading configuration data /Users/USR/.ssh/config

debug1: /Users/USR/.ssh/config line 1: Applying options for *

debug1: /Users/USR/.ssh/config line 5: Applying options for onering.tplinkdns.com

debug3: kex names ok: [diffie-hellman-group1-sha1]

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 47: Applying options for *

debug3: kex names ok: [diffie-hellman-group1-sha1]

debug1: Connecting to HOST-IP.

debug1: Connection established.

debug1: identity file /Users/USR/.ssh/id_rsa type 0

debug1: identity file /Users/USR/.ssh/id_rsa-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_8.1

kex_exchange_identification: read: Operation timed out

If you monitor “sudo tail -f /var/log/auth.log” during an ssh login attempt, what shows up?