SSH Errors - Details about some of the "Secure SHell" errors

Permission denied (publickey). when trying to login with keys on a locked / disabled password account

Situation :

Many factors can cause a Permission denied (publickey). error. If you are not in the context of a locked / disabled password account, this article might be useless.
  1. I'm trying to setup a user account on a remote machine (sshServer) so that I can use it via SSH
  2. I plan to use SSH keys only, so bob's account password should be "disabled" so that I don't have to worry about it and can safely forget it.
  3. sshd has been setup + hardened
  4. But when I execute :
    ssh bob@sshServer
    I get :
    bob@sshServer: Permission denied (publickey).

Details :

This is mainly caused by a misunderstanding of a tricky point related to locked accounts / accounts with a disabled password.

Solution :

To properly setup a user account with SSH keys and no password :

  1. create a user account
  2. setup SSH keys
  3. check the sshd configuration + hardening, especially these settings :
    grep -E '^(PasswordAuthentication|UsePAM|ChallengeResponseAuthentication)' /etc/ssh/sshd_config
    PasswordAuthentication no
    UsePAM no
    ChallengeResponseAuthentication no
  4. check Bob's password settings :
    grep bob /etc/shadow
    bob:*:18312:0:99999:7:::
  5. ssh bob@sshServer
    should work (asterisk in /etc/shadow)

Further experiments :

  1. If I lock Bob's account
    passwd -l bob && grep bob /etc/shadow
    passwd: password expiry information changed.
    bob:!*:18312:0:99999:7:::
    I get :
    ssh bob@sshServer
    bob@sshServer: Permission denied (publickey).
  2. To get it working again :
    • method 1 :
      passwd -u bob && grep bob /etc/shadow
      passwd: password expiry information changed.
      bob:*:18312:0:99999:7:::
    • method 2 :
      usermod -p '*' bob && grep bob /etc/shadow
      bob:*:18312:0:99999:7:::

packet_write_wait: Connection to 10.27.25.35 port 22: Broken pipe

Situation :

An SSH session dies regularly saying :
packet_write_wait: Connection to 10.27.25.35 port 22: Broken pipe

Solution :

Enable sending keepalive packets by adding to the SSH client configuration :
Host *
	ServerAliveInterval 120

debug2: we did not send a packet, disable method

It's most probably because the server cannot access the authorized_keys file (check permissions), or because the corresponding public key can not be found in that file.

tcsetattr: Input/output error Connection to mySshServer closed.

Full error message :
tcsetattr: Input/output error
Connection to mySshServer closed.
Have a look at this.

Many sshd[n]: Bad protocol version identification '\026\003\001' from 123.45.67.89 in /var/log/auth.log

Situation :

/var/log/auth.log contains many lines such as
sshd[n]: Bad protocol version identification '\026\003\001' from 123.45.67.89

Details :

This happens while sshd is listening on port 443.

Solution :

sshd expects the first thing that the client sends to be a version string. But since it's running on the HTTPS port, it's getting connections from clients that are sending encrypted SSL traffic. This is just meaningless, binary garbage, to sshd, hence the log entry.
Regarding the "protocol version identification" string (source) :
This is octal representation (base 8). During the initial steps of an SSH connection, the client and the server send each other the version(s) of the protocol they implement, as strings. These strings must follow a specific format.
Here, the server received from the client a "protocol version" string that does not make sense. Probably, the client was not trying to do some SSH at all, but instead some other protocol.

Server refused our key error, or prompts for password

sshd will return this error if some file permissions are not restrictive enough. sshd requires : Also check these :