mjhjmtu

As far as my understanding, machine(A) ssh-keygen generates a key, and ssh-copy-id gives this key to another machine (B), is it?

But when this is done, to test whether this is done or not is using the ssh like:
root@A: ssh root@B
if login on B without password, then this works.

I am confused about this. A gives a key to B, why can A login on B without password? It should go like this, login on B, B ssh A without password.

Is my understanding wrong?

An ssh key has two parts, a private part and a public part. That's why it's often called a 'key pair', a pair of keys that work together.

ssh-copy-id copies the PUBLIC portion of the private/public key-pair into ~/.ssh/authorized_keys on the remote host.

Anyone who has the private key (and knows the passphrase) can login to that remote host without a password.

To avoid having to retype the pass-phrase all the time, you can use a program like ssh-agent to hold the private keys for you (in simple terms, it caches the private key after you've unlocked it with the passphrase). It will keep the private key until you tell it not to, or you kill the agent, or logout. see man ssh-agent.

The PUBLIC portion of the key pair is not particularly sensitive, security wise. It can be distributed and disclosed without risk. Without the matching private key (and the private key's passphrase), it's pretty much useless.

The PRIVATE portion of the key-pair, of course, should be kept secret.

What you're missing is that ssh-copy-id doesn't just copy the public key to B: it adds the public key to the list of keys that allow access to the account (~/.ssh/authorized_keys). After running ssh-copy-id, the key is not just stored on B somewhere, it's registered on B as an authorized login method.

The private key is on A, and needs to be passed to the SSH client (this can be done by letting it search ~/.ssh/id_*, by passing a -i command line option, by using IdentityFile in ~/.ssh/config, or via ssh-agent). The public key is in ~/.ssh/authorized_keys on B. When you log into B from A, the SSH client sends a proof of possession of the private key to B; B links this proof of possession with a public key found in ~/.ssh/authorized_keys so it authorizes the login attempt.

A gives a key to B, why can A login on B without password?

You're right.

When SSH receives an incoming connection, it can authenticate the user in multiple ways. This is configurable. A typical way is to check whether the user has a public key in an ~/.ssh/authorized_keys* file, and to accept a matching private key (assuming that all details are accepted, such as a file having acceptable permissions). If no key is set up, or if the SSH client fails to provide details that acceptably prove that the SSH client has a matching private key, then the SSH server will prompt for a "password" (or "passphrase).

ssh-copy-id is basically a command that does a task which is not very difficult to do manually. It uses SSH to connect to the remote system, and gets the public key into the ~/.ssh/authorized_keys* file.

After I learned how to use ssh-copy-id, I quickly forgot, because the program just wasn't very useful for me, since I already learned how to manually do the equivalent tasks. Using ssh-copy-id was, admittedly, slightly easier/faster. However, it was very non-essential. I believe that whether the extra convenience is worth the effort to learn yet another command, is questionable.

ssh-copy-id may require that the user enters a password, just like what the user would need to do (using any other SSH client) if the user was doing this manually. It doesn't circumvent normal authentication requirements.

(Of course, after ssh-copy-id does its thing, then the SSH key is installed and can be used easily.)

It should go like this, login on B, B ssh A without password.

You can log onto B (using a password), and then use SSH (as a shell, or a protocol that uses SSH, like SCP/SFTP) to grab a key from A. Yes, that works as well. Whether you need a password, or not, would depend on A's setup. If A has a public key, and B has a corresponding private key, then B may not need to type a password.

cas's answer mentions ssh-agent (which was not specified in the question). That is basically another approach. The ssh-agent stores private keys. They may be encrypted, so you need to type a passphrase to gain access to the decrypted private keys. When you SSH, the SSH server will do something which the ssh-agent recognizes, and then the ssh-agent can provide the required details to the SSH server. The idea is that once ssh-agent is set up, after you type your passphrase once (to decrypt access to the keys), then you can make different connections all day long and don't need to keep re-typing your passphrase as long as ssh-agent is running. This is primarily about the experience of the end user who uses the SSH client, so there isn't a lot of work you need to do on the SSH server (other than setting up a public key, just like any of the other methods that have already been discussed).