Linux Troubleshooting Bible [Electronic resources] نسخه متنی

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.