File Transfer Troubleshooting

File transfer is a fairly straightforward process. If you run into trouble, the causes are easy to figure out, and the solutions are simple to implement. Here are some of the most common file transfer issues and a few hints to solve the problems:

SSH key-based authentication is not working-There are two likely causes for key-based authentication failure. First, edit the sshd_config file on the target system (the one you are SSHing into), not on the local system. The target system's sshd_config needs these lines:
```
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
```
Restart the target sshd service with the command service sshd restart or /etc/ init.d/sshd restart. Next, be sure that the target user's ~/.ssh/authorized_keys file contains the public key of the client who is attempting to log into that user account, taken from ~/.ssh/id_dsa.pub. The file permissions of the target user's .ssh directory and authorized_keys file must be set appropriately:
```
#ls -lad /home/bob/.ssh/ /home/bob/.ssh/authorized_keys
drwx------ 2 bob bob 4096 Jan 10 19:35 /home/bob/.ssh/
-rwx------ 1 bob bob  602 Jan 10 19:35
/home/bob/.ssh/authorized_keys
```
Cannot log into running sshd daemon-If the sshd service is running, but you can't log in, there are several possible causes. The first is quite simple to solve: verify (from the console) that sshd on the target server is actually running:
```
#/etc/init.d/sshd status
sshd (pid 4714) is running...
```
If you don't get the appropriate response, start the daemon. The solution to a more complex problem (if, for example, your firewall configuration is overly secure) is described earlier, under the SSH and Firewalls section. However a quick check on the target server may be to shut off the iptables service on the local and target systems altogether:
```
#/etc/init.d/iptables stop
Resetting built-in chains to the default ACCEPT policy: [ OK ]
```
"Permission denied" errors-Unless you tell ssh, scp, or sftp differently, it will always attempt to log you into the remote system under the same username you are using locally. The solution is to log in with an explicit statement of the account you want to reach:
```
[amy@localhost amy]$ ssh mikey@192.168.128.3
```
Users should not be able to login as root-For maximum security, administrators should login as themselves, then su - to the root account. With this method, you can track who's logging in and what they're doing. Edit /etc/sshd/sshd-config to deny root login:
```
PermitRootLogin no
```
Then restart the ssh service.
WebDAV doesn't work-Try to get WebDAV running without SSL first. Lock down WebDAV so that it answers only specific IP addresses, using the Allow from line in the Directory directive block of httpd.conf. If you continue to get WebDAV error messages, consult the logs for a message like this:
```
   # tail -f /var/log/httpd/error_log
   .
   .
   .
   [Sun Jan 11 21:26:41 2004] [notice] Apache/2.0.47 (Fedora)
   configured -- resuming normal operations
   [Sun Jan 11 21:26:55 2004] [error] [client 10.1.1.2] client
   denied by server configuration: /home/bob/web/html/.htaccess
```
Such a message indicates that your Allow from line is probably misconfigured. Double-check the IP address block you entered.