Environment
Privileged Account Manager 3.2
Privileged Account Manager 3.2.0.5
Privileged Account Manager 3.5
Situation
After upgrading to PAM 3.2.0.5 which introduces an upgraded OpenSSH (7.5p1) some ssh clients encounter a problem with connecting to the ssh-relay.
Something like, or similar to this will be seen, when using "ssh -vv ...":
debug1: rekey after 4294967296 blocks
debug2: key: /opt/CBKpwvc/.ssh/id_rsa (0)
debug2: key: /opt/CBKpwvc/.ssh/id_dsa (0)
debug2: key: /opt/CBKpwvc/.ssh/id_ecdsa (0)
debug2: key: /opt/CBKpwvc/.ssh/id_ed25519 (0)
debug3: send packet: type 5
Corrupted MAC on input.
Authentication failed.
Resolution
On the ssh-relay server add the following to /opt/netiq/npum/service/local/sshrelay/etc/sshd_config:
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com
This will make the sshd (ssh-relay) server tell the client that it would like to use the hmac-sha2-256 (preferably) and there after hmac-sha2-512, and so on. As the problem mac looks to be the "umac-xxx@openssh.com" the client should find a working mac before reaching these.
A quick solution could be to use the following:
# ssh -t -m hmac-sha1 -p 2222 <user>@<ssh-relay server>
This will make connection to the ssh-relay server using the hmac-sha1 MAC.
Cause
It is not fully clear why this happens, a search reveals that this is not only seen in combination with PAM, also it is not see with all clients.