I am trying to gain remote access to my TX2 to use the visual profiler on the host PC, but I am denied access when using ssh.
I have tried:
ssh -X nvidia@tegra-ubuntu
ssh nvidia@tegra-ubuntu
and I am prompted with a password each time. When I type in the correct password I am denied access.
Both the host PC and TX2 are connected to a university network with an ethernet connection. They are plugged into two different ethernet ports to the network, does this cause any problems? I feel like it shouldn’t because they are on the same network. If there is anything you’d like me to try let me know, thanks.
The “-X” and “-Y” options to ssh are for X11 forwarding…a connection would not be denied if those fail, but there would be a DISPLAY error. If you are logged in locally to the Jetson, can you run “sudo ls”? If sudo fails, then there was likely an issue with setup before flash. Was the Jetson flashed?
ssh does have a “verbose” option to provide more information on failures. You can use “-v”, “-vv” for more info, and “-vvv” for maximum debug info. Much of this would be things like checking which methods are used, and so you would get some failures which are expected (one example being if you are using password it may first test key login, note failure, then move on to password…and then go through a series of protocols and fail several before picking one).
If you google “SSH Ubuntu” I think you’ll find instructions. May be worth checking.
-X or -Y is definitely needed if you want to run nvvp on the local machine but host the x-display on your remote machine (which works pretty well for me).
alexmagsam@zheng-lab:~$ ssh nvidia@tegra-ubuntu -v
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to tegra-ubuntu [137.99.26.115] port 22.
debug1: Connection established.
debug1: identity file /home/alexmagsam/.ssh/id_rsa type 1
debug1: identity file /home/alexmagsam/.ssh/id_rsa-cert type -1
debug1: identity file /home/alexmagsam/.ssh/id_dsa type -1
debug1: identity file /home/alexmagsam/.ssh/id_dsa-cert type -1
debug1: identity file /home/alexmagsam/.ssh/id_ecdsa type -1
debug1: identity file /home/alexmagsam/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/alexmagsam/.ssh/id_ed25519 type -1
debug1: identity file /home/alexmagsam/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze8
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze8 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA d4:d3:12:cf:6e:d6:c8:93:5d:0b:d8:80:0e:9b:b7:63
debug1: Host ‘tegra-ubuntu’ is known and matches the RSA host key.
debug1: Found key in /home/alexmagsam/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alexmagsam/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /home/alexmagsam/.ssh/id_dsa
debug1: Trying private key: /home/alexmagsam/.ssh/id_ecdsa
debug1: Trying private key: /home/alexmagsam/.ssh/id_ed25519
debug1: Next authentication method: password
nvidia@tegra-ubuntu’s password:
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
nvidia@tegra-ubuntu’s password:
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
Permission denied, please try again.
nvidia@tegra-ubuntu’s password:
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
All is normal in the logs up until you try to use password. @txbob mentioned ssh might be disabled…check “/etc/ssh/sshd_config”, for “UsePAM yes”.
Next see what output you get during the ssh attempt while watching “sudo tail -f /var/log/auth.log”.
If multiple Jetsons are on a network, and if each is trying to use “tegra-ubuntu”, then this will be a problem. Often in “ifconfig” you will see a “collisions” count go to a non-zero value when two devices respond to the same request. Routers are supposed to use a MAC address for actual routing, and allow the “tegra-ubuntu” name only if it is possible to bind the name to the MAC without conflict. If your host hard wires “tegra-ubuntu” to a network address, then the router itself is ignored, and you would indeed have a problem. You are almost always better off using ssh with an IP address…named addresses and their aliases are usually just a convenience (not always true with web server traffic, but for ssh it may as well be true). I did see a case of a university user having a password failure when tegra-ubuntu happened to be someone else’s Jetson.
If you want your PC to override the router’s idea of which address to bind to “tegra-ubuntu” you can put this in your PC’s “/etc/hosts” file…I’m pretending the dotted-decimal IP is “192.168.1.3”…and I’m setting both “tegra-ubuntu” and “tx2” as aliases to that address:
192.168.1.3 tegra-ubuntu tx2
After that you could do this:
ping tx2
ping tegra-ubuntu
Do beware that if your Jetson is assigned an address over DHCP the dotted-decimal address could change on reboot or lease renewal timer.
Thanks for your help linuxdev, this was very helpful. I just posted a new question in the TX2 forum about using outputs from the TX2 for programs on the host PC in case you were interested.