Este processo de deixar um servidor confiar noutro servidor linux na rede é muito usando para não haver complicações em aplicações como syncronismo de informação, copia de arquivos e qualquer coisa que vá trafegar entre um servidor ou outro sem precisar de ficar montando compatilhamentos entre servidores.
E como sempre esse processo será da maior seguranca que um samba por exemplo.

Primeiro devemos efetuar a criação as chaves de acesso entre os servidores:

ssh-keygen -b 1024 -t rsa

Esse comando chama o utilitário 'ssh-keygen' e diz para criar uma chave de 1024 bits e usando o algoritmo rsa. Para a chave ser criada deverá ter no mínimo 512 bits, mas 1024 é o suficiente para ter uma ótima segurança. Caso seu servidor use SSH versão 1 terá que ser usado o algoritmo rsa, mas se for versão 2 poderá ser usado tanto rsa como dsa. Caso use dsa, ficará assim: ssh-keygen -b 1024 -t dsa.

Feito isso aparecerá no seu console:

[oracle[a]localhost oracle] Enter file in which to save the key (/home/oracle/.ssh/id_rsa.pub)

Aqui será especificado o local onde será criada as chaves. O ideal é não alterar. Pressione ENTER.

[oracle[a]localhost oracle] Enter passphrase (empty for no passphrase):

Nesse ponto é que está o segredo!!! Aqui pedirá uma 'passphrase' que é uma 'frase-senha', mas como queremos nos logar sem senha, aperte ENTER, e não coloque nada.

[oracle[a]localhost oracle] Enter same passphrase again:

ENTER de novo.

[oracle[a]localhost oracle] Your public key has been saved in /home/oracle/.ssh/id_rsa.pub
The key fingerprint is:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

Aparecendo isso que dizer que as chaves foram criadas com sucesso. (A 'key fingerprint' é diferente em cada caso). Agora falta pouco para terminarmos... Digitando esse comando:

[oracle[a]localhost oracle] scp /home/oracle/.ssh/id_rsa.pub oracle[a]10.0.0.5:/home/oracle/.ssh/

Será copiado nossa chave pública para o servidor. Não esqueça, tem que ser a chave PÚBLICA. A privada nunca sai de sua máquina. scp é o utilitário que irá copiar nossa chave, id_rsa.pub é a nossa chave (caso você tenha escolhido o algoritmo DSA, o nome será id_dsa.pub), oracle é o usuário, 10.0.0.5 é o servidor e finalmente o caminho para onde vai a chave.

Agora logando-se na máquina você perceberá que o servidor ainda pede a senha. O que temos que fazer é ir no diretório onde está a chave pública e mudarmos o nome para 'authorized_keys':

[oracle[a]localhost oracle] mv id_rsa.pub authorized_keys (caso seja rsa)
[oracle[a]localhost oracle] mv id_rsa.pub authorized_keys2 (Olha o 2 aí)(caso seja dsa)

Dê um logout com 'exit': exit
E logue-se de novo e não pedirá mais a senha.

Ref.: SSH sem senha ; br-linux.org ; dicas-L

Bom uma prática do tempo do Unix 32bits na hora de fazer export ou import utilizar um recurso para des/compactar ou partir os arquivos na hora que eles estao sendo criados. É +/- isso ai mesmo.
No momento que tais fazendo um exp system/senha full=y file=/backup/expfull.dmp este arquivo pode mtas vezes ter centenas de gigas, mas compactados podem ficar com pequenos megas.
Bom muito DBA nos seus scripts de backup no Linux ou Unix fazem esse export e dps passam um gzip expfull.dmp para compactar ai mora outro problema, o gzip compacta mas se o arquivo dmp ficou com 20Gb e o .gz for ficar 4Gb no total vai ter que ter pelo menos de espaco livre uns 24,5Gb para essa maratona toda ai.....
Mas como eu estava dizendo há uma forma mais simplificada nisso tudo ai, como o unix ou linux todos os arquivos sao concatenados, é o termo nao é bem esse mas é algo assim, entao no momento q estou criando um arquivo posso estar pegando a informacao de dentro dele e jogando para outro lugar.
bom para nao enrolar mto vou fazer um exemplo que ficará mais fácil de enteder.

1. Tens que criar um arquivo temporario, é .... aquele que eu disse que vai ser alimentado mas vai ser jogado o seu conteudo para outro
[oracle@localhost oracle] mknod /tmp/exp_pipe p # criando um arquivo para o export
[oracle@localhost oracle] gzip < /tmp/exp_pipe > /backup/expfull.dmp.gz & # gzip recebendo a informacao do exp_pipe e a saida do gzip está sendo para /backup/expfull.dmp.gz já compactado e o & quer dizer em segundo plano
[oracle@localhost oracle] exp system/senha full=y file=/tmp/exp_pipe log=/backup/expfull.log # aqui o export vai jogar as informacoes para o exp_pipe onde o gzip que está em segundo plano esperando estas para compactar.

Não há necessidade de matar o gzip pois ele fica em segundo plano, no momento que termina o export o gzip finaliza o export e ai está o seu export de 20Gb já saiu compactado em 4Gb.
Ok pode perder um pouco de performace pois será dois processos de arquivos no servidor mas nao será tao problemático em questão de espaco.

E em relação a importar esse gzip, nao há necessidade de descompactar e dai fazer o import, vou colocar somente o código e dai com a explicação anterior já irão induzir o que ele está fazendo.

[oracle@localhost oracle] mknod /tmp/imp_pipe p
[oracle@localhost oracle] gzip -d < /backup/expfull.dmp.gz > /tmp/exp_pipe &
[oracle@localhost oracle] imp system/senha full=y file=/tmp/exp_pipe log=/backup/impfull.log fromuser=deUsuario touser=paraUsuario

Obs.: O ideal depois de compactar usando esse recurso se certificar que o arquivo está ok, como foi usado o gzip posso recomendar o seguinte comando:
gunzip -t /backup/expfull.dmp.gz ; RC=$?
if test ${RC} -ne 0
then
# aqui vc fazer um comando mail para enviar um email para o DBA dizendo que o backup falhou
fi

Referencias: OraFAQ,

Oracle export 2 gig file