You can explicitly indicate the private key with -i. By default, scp does the same as ssh -- from man ssh:
-i identity_file
Selects a file from which the identity (private key) for public key authentication is read. The default
is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 and
~/.ssh/id_rsa for protocol version 2. Identity files may also be specified on a per-host basis in the
configuration file. It is possible to have multiple -i options (and multiple identities specified in
configuration files).
I believe those are the default names used by ssh-keygen depending on the value of the -t option.
In short, you can either add -i explicitly, or make sure the key paths are as indicated above.
There is a further caveat: It may not work unless the keys are set mode 600 (i.e., read-write by owner, no access to anyone else). This is how they are when created, but you may want to double check with stat.
Note that there are other methods to accomplish the goal here besides what you are doing -- although I admit to doing something vaguely similar: I have little UDP services that run and respond to broadcast requests with an arbitrary hostname; the corresponding clients add the hostname and IP to their local /etc/hosts file. That's a sort of simplified version of zeroconf, but it's a bit silly in that there's already a proper zeroconf implementation that runs by default on Raspbian, avahi. You can find documentation around for it, and it is possible to use an arbitrary hostname (as in, one that is different from the one in /etc/hostname or comes from the hostname command) with that too, and all common operating systems including those on smartphones have simple clients that will pick it up (although with, e.g. Android, this means literally a port scanner as described below, but those will probably deploy zeroconf as well and list the hostname sent back).
Simply add:
[server]
host-name=foo
domain-name=bar
To /etc/avahi/avahi-daemon.conf, then systemctl restart avahi-daemon and you will have a system that can be found via a zeroconf client with the hostname foo.bar.
You can also use a port scanner to find a Pi if you are using the ethernet jack or Pi 3's built in wifi, because it will pick up on the OUI used by the Raspberry Pi Foundation. For example:
nmap -sT -p22 192.168.0.0/24
Will scan a LAN with that subnet mask for nodes and show whether port 22 (the SSH port) is active. Even if you aren't using one of the built in NIC's that would be a big clue unless you have a lot of computers on the network running an sshd server.
