Does file user ownership change when transferring files between computers?

Yes.

This all depends on who creates the file on the destination. Try this:

$ touch some_file
$ ls -l some_file
-rw-r--r-- 1 userA userA 0 Apr 9 17:44 some_file
$ ls -ln some_file
-rw-r--r-- 1 501 501 0 Apr 9 17:44 some_file

So in my example, userA's numeric uid is 501.

Now transfer it, logging into the remote system as userB:

$ scp some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:50 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:50 some_file

As you see here, userB created the file, and userB has numeric uid 1743. See also how the timestamp changed?

This is the default behavior of scp. You can preserve attributes though by using scp's "-p" option. This only preserves timestamp and permissions -- and importantly, not ownership. This might be exactly what you're looking for:

$ scp -p some_file userB@computerB:
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 userB users 0 Apr 9 17:44 some_file
$ ssh userB@computerB ls -l some_file
-rw-r--r-- 1 1743 20 0 Apr 9 17:44 some_file

Note that besides scp, there are many different ways of creating files on remote machines -- NFS, FTP, WebDAV... these will behave in different, but similarly predictable ways. Let's not get carried away though -- you asked about scp.

(OT note, you actually created the file with 754 permissions! rwx=111=7, r-x=101=5, r--=100=4 – you see, r, w and x are bits in an octal word where r=4, w=2, x=1. That's why you'll see references to octal in relation to permissions. Thanks ernie for the correction!)

The general form for scp when you're copying locally to remote is:

scp localfile username@remotehost:/some/remote/directory

In this case, you're telling scp you want to login as username on the remote system, and that's the username the write will ocurr with. Most likely in your example, you used userB when you were scp'ing the file to computer B.

If you were copying a remote file to a localhost, e.g.:

scp username@remotehost:/some/remote/file /some/local/directory

In this case, you login as username to the remote system, and then write it locally as the user you're running the scp command as. This example will copy the file from the remotehost to the system you're running on, as the user you're currently logged in as (since the write will be performed by the currently logged in user). This will not affect anything on the remotehost, as you're only reading the file from there, and copying it to the localhost. Since you're able to read the remote file, the local file has to have write permissions for you, as you're writing the file locally.

Put another way - the owner of the file will generally match the writer of the file. So, if you're logged in as userA, and write a file, the owner will be userA. A simpler example might be something like this:

user@server:~$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 6615 Apr  9 17:09 /var/log/syslog  

Note that this file is owned by syslog but that it's readable by anyone in the adm group, which user happens to belong to. Then if we copy the file to user's home directory (~/):

user@server:~$ cp /var/log/syslog ~/
user@server:~$ ls -l ./syslog
-rw-r----- 1 user user 6615 Apr  9 17:10 ./syslog

Note that the copied version of the file is now owned by user. scp is doing the same thing, except the source or destination may involve logging in as a different user to a different system.

Note that permissions are tracked with the user id, a numeric represenation of the user. You can see your current UID with the id command. In general, for individual systems, UIDs will not be the same system to system as the accounts are not shared (unless you're using LDAP or similar). I believe that traditionally, 0 is root, UIDs less than 1000 are reserved for system accounts (e.g. mail, news, bin, daemon, etc), and that regular users start at 1000. As far as I know, regular user UIDs are assigned sequentially, so if you created three accounts, they would likely be 1000, 1001, and 1002.

Back to your original question of how to send a read-only file, you have to ensure that the reader on the remote system does not have the same UID as the owner of the file. i.e. if you (userA) were preparing a file for userB, you could do something like:

scp localfile userA@remotehost:/some/remote/directory

In this case, the owner of the file will end up being userA, (and we know userA exists on the remote system as that's who we're logged in as), and userB would not have write permissions (assuming the file was originally 755). Edit: you may need a -p to preserve the permissions?

Of course, if userB has root or sudo permissions, they'll be able to make the file writeable no matter what you do.