There are basically two ways of archiving this
Changing rsync’s rsh parameter
You can simply feed ssh with a different port parameter as remote shell to ssh:
$ rsync -a --inplace --rsh='ssh -p12345' file user@remotehost:dir/
Create a per host config for ssh
Add a Host entry to ~/.ssh/config
[...]
Host foobar
Port 12345
User user
Hostname host.example
and invoke rsync with that alias
$ rsync -a --inplace file foobar:dir/
The kioslave fish:/ enables you to access remote files through ssh, even if sftp is not installed on the remote host. It’s much more convenient than its cousin sftp:/, e.g. because dolphin remembers file associations etc.
Unfortunately, fish:/ requires perl. It copies a perl script to the remote host and execute it there. So if you run into an error like
Could not enter folder fish://root@HOST/root
when you try to point konqueror or dolphin to fish://root@HOST, the culprit could simply be a missing perl package on the remote host. Installing perl-URI should suffice:
# yum install perl-URI
For further debugging of the fish:/ kioslave, have a look at http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves/Debugging_kio_fish
If you need a programmatic ssh login, i.e. in a shell script, the best way to make ssh non-interactive usually is a public-key authentication. This requires the public key to be stored on the host machine, which (admitted, in very rare cases) can be hard or impossible. One of those rare cases might be a chrooted environment on a webserver without write access to the ssh config file or the per-user ssh directory.
Unfortunately, most ssh clients don’t allow piping a clear text password from a file or varibale. One solution is to use the SSH_ASKPASS environment variable and a wrapper script but most recommendations suggest the use of expect.
Expect is basically a scripting language to make interactive applications non-interactive. It is often used to automate reactions to certain outputs from programs like ftp, ssh, scp and others.
A simple expect script to rsync a backup from one host to another could look like this
#!/usr/bin/expect
set timeout 600
spawn rsync -avhS user@host:/backups/ /backups/
expect {
"password" {send "secret\n";}
}
expect {
eof {exit 0;}
}
Note that expect eof is used here, because the alternative interact command is not compatible with cron scripts.
For a list of commands have a look at the expect man page or expect’s sourceforge page.
Unfortunately, there is no way to pipe data directly to scp simply because scp can’t read from stdin. But you can abuse ssh to achieve the same result
tar cz a/dir | ssh user@remotehost.com "cat >outfile.tar.gz"
You can even do some funny things like
tar c /data/ | lzma -c -z |\
gpg --batch --force-mdc -ac -o - --passphrase-fd 3 -c 3< /etc/gpgpassphrase |\
ssh user@remotehost.com "cat >/data/backup.tar.lzma.gpg"
If you encounter the problem of being unable to start an X application through an ssh-tunnel and run into an error message similar to
Can't open display
or
RuntimeError: could not open display
you should check
- that you used ssh -X[...] to enable X11 forwarding when connecting to the server
- that the xauth-package is installed correctly on your server
xauth is used to edit and display the authorization information used in connecting to an X server.
For example, after installing a minimalistic CentOS the xorg-x11-xauth package is not necessarily installed as well.
The solution is quite simple:
yum install xorg-x11-xauth
does the trick! You may have to reconnect to give xauth the opportunity to create a new authority file for you user (~/.Xauthority)
Just because I always forget:
Step 1: Create public and private keys using ssh-keygen
[user@Host ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
0d:d2:94:07:93:a9:48:b9:33:73:fb:f1:6e:33:ce:d7 user@Host
The key's randomart image is:
+--[ RSA 2048]----+
| . += |
| o o+.. |
| . o..o. |
| * o. o |
| = .S . |
| . . |
| . o . |
| ..= . E |
| +++ |
+-----------------+
Step 2: Copy the public key to remote-host using ssh-copy-id
Now here comes the awesome part: You don’t have to scp the public key to your remote host and cat it into ~/.ssh/authorized_keys. Instead, you can use ssh-copy-id
[user@Host ~]$ ssh-copy-id -i .ssh/id_rsa.pub user@remote-host
user@remote-host's password:
Now try logging into the machine, with "ssh 'user@remote-host'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.