Проще говоря, вы не можете использовать .netrc с sftp, scp или ssh. Эти продукты являются частью стандарта OpenSSH, в названии которого есть ключевое слово «безопасный». Автоматизировать вход в систему, как это делает .netrc, небезопасно, и стандарт запрещает этот вид автоматизации (хранение паролей). Определенно есть альтернатива, на самом деле три.
Авторизация
Для любой из первых двух альтернатив вы захотите настроить ключи и обменяться ими. На компьютере, к которому вы подключаетесь из прогона ssh-keygen, для ваших целей будет намного проще, если вы не дадите ключевой фразе ключ, хотя это рискованно. Теперь у вас есть два файла в .ssh/, id_rsa и id_rsa.pub. Из них id_rsa должен храниться в секрете или быть защищенным (отсюда и пароль). Файл pub на самом деле представляет собой одну строку текста. Эту строку можно добавить в файл ~/.ssh/authorized_keys на стороне принимающего хоста. Вы можете добавить ключ к файлу вручную ; но есть также команда быстрого вызова ssh-copy-id, которая делает это, также заботясь о правах доступа к файлам. Авторизовав ключ, вы сможете подключиться с машины с закрытым ключом к машине, на которой есть авторизованный открытый ключ, при подключении в качестве соответствующего пользователя. Проверьте это с ssh -v. Если вы ввели парольную фразу, вам будет предложено ввести ее; если вы этого не сделали, то теперь вы готовы к автоматизации. Вы можете использовать ssh-agent, чтобы сохранить личный ключ активным между сеансами, вводя пароль только один раз. Если вы делаете несколько прыжков ssh, опция переадресации агентов позволит сообщать закрытый ключ из ssh-agent исходного ящика при каждом прыжке. Лично я нахожу это перегруженным и поэтому предлагаю не использовать парольную фразу.
Теперь, когда вы можете устанавливать соединения ssh, sftp и scp без ввода пароля или фразы, вы готовы автоматизировать все остальное.
Альтернатива 1,
является предпочтительной альтернативой, если вы конвертируете свой макрос .netrc в сценарий оболочки или другой сценарий, вызывающий несколько команд scp. Это похоже на автоматизацию всех ваших соединений ftp с curl или wget. E.G.:
scp -qr $USER@$REMOTE_HOST:$PATH_FILE_OR_DIR $LOCAL_PATH_FILE_OR_DIR #download
scp -qr $LOCAL_PATH_FILE_OR_DIR $USER@$REMOTE_HOST:$PATH_FILE_OR_DIR #upload
scp -pqr $USER@$REMOTE_HOST:$PATH_FILE_OR_DIR $USER@$REMOTE_HOST2:$PATH_FILE_OR_DIR #mirror between separate hosts.
ssh $USER@$REMOTE_HOST chmod 644 $PATH_FILE #set permissions
Альтернатива 2,
используя sftp, как вы упомянули, вы можете написать его с помощью команды expects, с помощью пакетного файла , используя параметр -b, или передавая команды в sftp. Это немного больше похоже на макрос .netrc, но не имеет преимущества перед альтернативой 1. Я покажу пример последнего:
#!/bin/sh
echo "OK, starting now..."
sftp -b /dev/fd/0 remotehost <<EOF
cd pub
ascii
get filename.txt
bye
EOF
Альтернатива 3,
используйте программу sftp, которая нарушает стандарт SSH, позволяя вам хранить параметры подключения, такие как пароль. Например, используя cyberduck и AppleScript, или FileZilla и очередь.
Дополнительные примечания:
Существует ~/.ssh/config файл , который можно использовать , чтобы присвоить именам хостов более короткие имена, установить параметры пересылки, каталоги по умолчанию, имена пользователей по умолчанию и конкретные идентификаторы для каждого хоста. Мне также нравится опция -l, равная scp, которая ограничивает мою скорость передачи чем-то более разумным.
P.S. Можно подумать, что есть инструмент для преобразования макросов .netrc в (альтернативный стиль 1) сценарии оболочки. Но я ничего не нашел. Это крошечная нишевая возможность для бизнеса?