Some hints for using Ubuntu 16.04 machines that can't be rebooted to work around this bug:
1) You can keep your SSH logins a secret from systemd-logind by adding `UsePAM no` to /etc/ssh/sshd_config; this will avoid the ~25 second delay.
2) `UsePAM no` requires unlocked accounts (passwd -u) with a password set, even if you are only using publickey authentication.
3) You can use `AuthenticationMethods publickey` to prevent login with the passwords set for those accounts.
4) `su` also uses PAM and therefore informs systemd-logind and hangs for ~25 seconds, but in some cases `ssh user@localhost` can work as a replacement for `su`. There doesn't seem to be a way to configure `su` to not use PAM.
5) If you were relying on PAM to set a ulimit -n (nofile) using /etc/security/limits.conf, you can add something like `LimitNOFILE=131072` to the [Service] section in /etc/systemd/system/sshd.service, then `systemctl daemon-reload && systemctl restart sshd`
Some hints for using Ubuntu 16.04 machines that can't be rebooted to work around this bug:
1) You can keep your SSH logins a secret from systemd-logind by adding `UsePAM no` to /etc/ssh/ sshd_config; this will avoid the ~25 second delay.
2) `UsePAM no` requires unlocked accounts (passwd -u) with a password set, even if you are only using publickey authentication.
3) You can use `Authentication Methods publickey` to prevent login with the passwords set for those accounts.
4) `su` also uses PAM and therefore informs systemd-logind and hangs for ~25 seconds, but in some cases `ssh user@localhost` can work as a replacement for `su`. There doesn't seem to be a way to configure `su` to not use PAM.
5) If you were relying on PAM to set a ulimit -n (nofile) using /etc/security/ limits. conf, you can add something like `LimitNOFILE= 131072` to the [Service] section in /etc/systemd/ system/ sshd.service, then `systemctl daemon-reload && systemctl restart sshd`