What is the "user name, and password " means in the jetpack l4t doc?

http://docs.nvidia.com/jetpack-l4t/2_1/content/developertools/mobile/jetpack/jetpack_l4t/2.0/jetpack_l4t_install.htm

If you de-selected Flash OS in the Component Manager, you will need to enter the IP address, user name, and password to set up an ssh connection to the target device.

After you enter the required information and click Next, JetPack will begin installing components on the target device.

I met the question following:
"
Return Code 1:
Error : Cannot connect to device with given information

"
OR like :
"
Error: Cannot connect to device with given information. Please check your input and try again.

Detailed info:
Connection closed by .168.18.

"
the .168.18. is IP of TX1.
Is there any paces I missed?

I met the question following:
"
Return Code 1:
Error : Cannot connect to device with given information

"
OR like :
"
Error: Cannot connect to device with given information. Please check your input and try again.

Detailed info:
Connection closed by .168.18.

"
the .168.18. is IP of TX1.
Is there any paces I missed?

If you are installing packages to a Jetson via JetPack you need to tell it what address the Jetson is at, and what user name and password (e.g., usually “ubuntu/ubuntu”). The reason being that if JetPack flashes it will know some information about finding what it just flashed, but if you install packages only to an existing Jetson you have to tell it that information.

So if you were to log in via ssh to your Jetson, what address would you use? What name and password?

Thanks for your reply !
But what puzzles me is that I cannot login in my Jetson via ssh at all,while the pc and TX1 could ping both side successfully.(yean ,I am a rookie in ssh command/doge)
The commond is :
"
ssh -v ubuntu(Jetson usrname)@*****(Jetson IP)

"
and return error of debug info like :
"
lxy@ubuntu:~$ ssh -v ubuntu@Jetson IP
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 Jetson IP [Jetson IP] port 22.
debug1: Connection established.
debug1: identity file /home/lxy/.ssh/id_rsa type -1
debug1: identity file /home/lxy/.ssh/id_rsa-cert type -1
debug1: identity file /home/lxy/.ssh/id_dsa type -1
debug1: identity file /home/lxy/.ssh/id_dsa-cert type -1
debug1: identity file /home/lxy/.ssh/id_ecdsa type -1
debug1: identity file /home/lxy/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/lxy/.ssh/id_ed25519 type -1
debug1: identity file /home/lxy/.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.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
Connection closed by Jetson IP

"
Which folder contains the usful info(or log) in system?
The ssh_config is defualt (/etc/ssh/sshd_config),MTU both is 1500
What I should do next for locating the details of this error and resolve it?
Looking forward to your reply@linuxdev

The part which catches people off guard is that the first time ssh connects to a particular account the keys are memorized. If you flash, then the keys change, and ssh refuses future connections because keys have unexpectedly changed. I think there may also be some cases (and I’m not sure if this applies here) where one machine will use an older protocol and the other was set to not allow older/weaker protocols.

Files in “/etc/ssh/” more or less won’t matter for your case unless there is a protocol being rejected and you want to allow easier-to-break protocols.

The keys which usually matter are in the individual user’s directories: “~/.ssh/known_hosts”. If you try to log in to a host with this file having marked a different key from a previous login then the current login is refused. If you look at known_hosts from your local login (not ssh since ssh is failing) you will see one or more very long lines. There is one line per host. There is actually a proper way to delete those lines which works in cases of encrypted versions of this file, but you won’t see that by default…you can eliminate the line naming the address of the host which is failing to be allowed and you may then be once more allowed.