На данный момент вы, похоже, запустили ssh-keygen как oracle на локальном сервере, но добавили содержимое локально сгенерированного файла /home/oracle/.ssh/id_rsa.pub в свой собственный authorized_keys файл - т.е. /home/myUsername/.ssh/authorized_keys - на удаленном сервере.
Из контекста, я подозреваю вас и других пользователей, войдите в свои локальные и удаленные ящики под своими учетными записями, а затем su в учетную запись oracle. Благодаря тому, как вы настроили ключи, любой локальный пользователь, который может получить доступ к учетной записи oracle на локальном сервере, теперь имеет доступ к вашей личной учетной записи на удаленном сервере - это не то, что вы хотели.
И хотя ваша первая команда, задающая имя удаленного пользователя, работает, файлы на удаленном конце будут принадлежать вам, а не oracle; Это означает, что целевой каталог /home/oracle/receivefiles/ должен быть по крайней мере доступен для групповой записи и, возможно, для записи во всем мире. В этом может не быть необходимости, и, как правило, это не очень хорошая идея - мнения различаются, но домашние каталоги, как правило, запираются настолько плотно, насколько это возможно, особенно для таких чувствительных учетных записей, как этот. (Вы не хотите, чтобы кто-то, кто получает доступ к серверу с низким уровнем привилегий, мог сделать что-то неприятное, скажем, отредактировав Oracle .profile или создав новый файл точек, который, например, удаляет все файлы данных БД далее раз кто-то входит в эту учетную запись ...)
Содержимое id_rsa.pub необходимо добавить в /home/oracle/.ssh/authorized_keys на удаленном сервере (и удалить из /home/myUsername/.ssh/authorized_keys!). После того, как вы это сделаете, вы и все, кто имеет su 'до oracle на локальном сервере, смогут выполнить:
scp -p /home/oracle/sendfiles/* remoteServer:/home/oracle/receivefiles/
без запроса пароля, а файлы на удаленном конце будут принадлежать oracle вместо вас. (Флаг -p означает, что права доступа и временные метки также будут сохранены.)