When attempting secure copy operations between two servers configured for password authentication only, I encountered asymmetric behavior:

# Working direction (A → B):
scp -P 222 file_from_A user@serverB:/path/

# Failing direction (B → A):
scp -P 222 file_from_B user@serverA:/path/
# Returns: Permission denied (password)

The -vvv flag reveals critical authentication workflow details:

debug1: Authentications that can continue: password
debug3: preferred publickey,keyboard-interactive
debug1: No more authentication methods to try.

This indicates the client is prematurely abandoning password authentication despite server support.

After investigating ~/.ssh/config on server B, I found:

Host serverA
    PreferredAuthentications publickey
    PubkeyAuthentication yes

This explains why the client wasn't attempting password auth - it was explicitly configured to prefer keys.

Three viable solutions:

1. Command-line override

scp -o PreferredAuthentications=password -o PubkeyAuthentication=no -P 222 file user@serverA:/path/

2. Temporary config modification

Host serverA
    PreferredAuthentications password
    PubkeyAuthentication no

3. Environment variable approach

SSH_AUTH_SOCK="" scp -P 222 file user@serverA:/path/

Confirm the authentication methods with:

ssh -v -o PreferredAuthentications=password serverA

Should now properly prompt for credentials.

---

When attempting to transfer files between two Linux servers using SCP with password authentication, you might encounter a frustrating scenario where:

• SCP fails with "Permission denied (password)"
• No password prompt appears despite PasswordAuthentication being enabled
• Works in one direction (A→B) but fails in reverse (B→A)

Let's examine the verbose output from the failing command:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: password
debug3: start over, passed a different list password
debug3: preferred publickey,keyboard-interactive
debug1: No more authentication methods to try.
user@serverA: Permission denied (password).

Key observations from the debug output:

1. The server acknowledges password authentication is available
2. The client prefers publickey and keyboard-interactive methods
3. The client gives up without falling back to password auth

First, verify your sshd_config on both servers contains these critical settings:

Port 222
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes

Then restart the SSH service:

sudo systemctl restart sshd

Since you can't use key authentication, try these client-side solutions:

Method 1: Force Password Authentication

Explicitly tell SCP to use password auth:

scp -o PreferredAuthentications=password -o PubkeyAuthentication=no -P 222 file user@serverA:/path/

Method 2: Use sshpass for Non-Interactive Auth

If you need to automate the process:

sshpass -p "your_password" scp -P 222 file user@serverA:/path/

Note: Install sshpass first if needed:

sudo apt-get install sshpass  # Debian/Ubuntu
sudo yum install sshpass     # RHEL/CentOS

Sometimes the issue lies in PAM configuration. Check these files:

/etc/pam.d/sshd
/etc/security/access.conf

Look for any deny rules that might be blocking authentication attempts from specific hosts or users.

Before troubleshooting SCP, verify basic SSH works in both directions:

ssh -vvv -p 222 user@serverA

Compare the debug output between working and non-working directions to spot differences.

If SCP continues to fail, consider these alternatives:

Using rsync with SSH

rsync -avz -e 'ssh -p 222' file user@serverA:/path/

Using sftp

sftp -P 222 user@serverA
put file /remote/path/

• Verify identical sshd_config on both servers
• Check for firewall rules blocking port 222
• Confirm user permissions on both systems
• Test with different users to isolate permission issues
• Review system logs (/var/log/auth.log or /var/log/secure)