After changing my system's hostname, I encountered a peculiar SSH behavior where connections would hang indefinitely at the authentication phase. The debug output shows the session freezing right after service acceptance:

debug1: SSH2_MSG_SERVICE_ACCEPT received
[connection hangs here]

The most telling clue was that SSH worked perfectly under root but failed under my regular user account. This immediately points to permission issues in the user's SSH directory structure. Here's what to check:

ls -ld ~/.ssh
ls -l ~/.ssh/*

Proper permissions should be:

drwx------  ~/.ssh
-rw-------  ~/.ssh/authorized_keys
-rw-r--r--  ~/.ssh/known_hosts

Many SSH hangs occur because the client is waiting for GSSAPI authentication to complete. This is particularly common on macOS and some Linux distributions. To verify and disable:

# Add to ~/.ssh/config
Host *
    GSSAPIAuthentication no
    PreferredAuthentications publickey,keyboard-interactive,password

The dtruss output reveals the exact system call where the hang occurs:

read(0x4, \"\\0\", 0x4)         = -1 Err#4

This suggests the SSH client is waiting for data that never arrives. Additional debugging steps include:

# Check for TCP connection issues
ssh -o ConnectTimeout=10 -v user@host

# Alternative authentication methods
ssh -o PreferredAuthentications=password -v user@host

1. Verify and correct all SSH directory permissions
2. Check for stale entries in known_hosts
3. Disable problematic authentication methods in config
4. Test with simplified SSH command options
5. Compare working root environment with user environment

---

When your SSH session freezes after the SSH2_MSG_SERVICE_ACCEPT message without prompting for password, especially when it works fine under root but fails for regular users, we're typically looking at one of these scenarios:

# Typical hang point in debug output:
debug1: SSH2_MSG_SERVICE_ACCEPT received
[connection hangs here]

While browser-based SSH clients might handle these cases differently, terminal-based SSH follows strict authentication protocols. The dtruss output reveals the process gets stuck trying to read from file descriptor 4:

read(0x4, "\\0", 0x4)         = -1 Err#4

The most common culprit is incorrect permissions in your ~/.ssh directory. Try these commands to reset them:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config

Changing your hostname affects several authentication mechanisms. For GSSAPI authentication (common in enterprise environments), run:

kdestroy
kinit

If you're using Kerberos, also verify your /etc/krb5.conf reflects the new hostname.

Sometimes the hang occurs during X11 negotiation. Try disabling X11 forwarding:

ssh -o ForwardX11=no user@host

SSH attempts authentication methods in a specific order. Force password authentication to test:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@host

If this works, focus on your key configuration. Check for these files:

~/.ssh/authorized_keys
~/.ssh/authorized_keys2
/etc/ssh/sshd_config

Reverse DNS lookups can cause hangs. Disable them with:

ssh -o UseDNS=no user@host

Your SSH agent might be holding problematic keys. Try:

ssh-add -D  # Remove all keys
ssh-add ~/.ssh/id_rsa  # Add your key fresh

If problems persist, kill the agent entirely:

eval $(ssh-agent -k)

For deeper investigation, compare working (root) and non-working sessions:

# As regular user:
strace -f -o user_trace.txt ssh user@host

# As root:
strace -f -o root_trace.txt ssh root@host

# Then diff the outputs:
diff -u user_trace.txt root_trace.txt

SSH reads configuration files in this order:

1. ~/.ssh/config
2. /usr/local/etc/ssh_config
3. /etc/ssh/ssh_config

Create a minimal test configuration:

Host *
    GSSAPIAuthentication no
    ForwardX11 no
    UseDNS no
    PreferredAuthentications keyboard-interactive,password

If all else fails, recreate your entire SSH environment:

rm -rf ~/.ssh
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa -b 4096

Then carefully rebuild your configuration, testing after each change.