forked from Controls/gitea-pages
64 lines
3.2 KiB
Markdown
64 lines
3.2 KiB
Markdown
# Login and Remote Access
|
|
|
|
When a user cannot log in on a system, it is usually caused by one of these:
|
|
|
|
1. The password is wrong.
|
|
2. Access hasn't been granted through Hiera (`aaa::admins` and `aaa::users`)
|
|
or `/etc/security/ssh.allow.*`. The latter also has to be enabled in Hiera.
|
|
3. Log in as root is attempted from a system that is not a bastion host (eg
|
|
`wmgt0*.psi.ch` or `*-gw.psi.ch`).
|
|
4. In the case of Gnome logins, the problem might be caused by the home
|
|
directory being inaccessible (eg because AFS doesn't work properly).
|
|
5. [`sssd(8)`](https://linux.die.net/man/8/sssd) may have problems.
|
|
|
|
Regarding #3 note that on some systems the configured bastion host is
|
|
`wmgt*.psi.ch` even though it is not actually possible to log in from there,
|
|
because the PSI firewall only allows connections from a certain gateway, eg
|
|
`foobar-gw.psi.ch`.
|
|
|
|
## Known Errors
|
|
|
|
### Problematic `.bashrc`/`.bash_profile`
|
|
Some people load a pmodule or a conda environment when bash is started. This can easily break the Gnome Startup as this can bring in incompatible tools and libraries. Suspicous is also setting the `LD_LIBRARY_PATH` environment variable. Once even `PATH` was the culprit because an incompatible `kinit` was used after.
|
|
|
|
|
|
### pam_sss Errors
|
|
```
|
|
pam_sss(sshd:account): Access denied for user xxxxxx_y: 4 (System error)
|
|
```
|
|
Here the AD join might be broken. The machine can be rejoined by deleting/moving away `/etc/krb5.keytab` and then running Puppet (`puppet agent -t`).
|
|
|
|
```
|
|
pam_sss(xrdp-sesman:auth): received for user xxxxxx_y: 10 (User not known to the underlying authentication module)
|
|
```
|
|
can be caused by corrupt `sssd` cache files (see [SSD Troubleshooting](sssdi))
|
|
|
|
|
|
### KioskWithKeyboard Error
|
|
```
|
|
gnome-session[31143]: gnome-session-binary[31143]: dconf-WARNING: unable to open named profile (redhatkiosk): using the null configuration.
|
|
gnome-session-binary[31143]: dconf-WARNING: unable to open named profile (redhatkiosk): using the null configuration.
|
|
gnome-session[31143]: gnome-session-binary[31143]: WARNING: Unable to find required component 'com.redhat.KioskWithKeyboard.WindowManager'
|
|
gnome-session-binary[31143]: WARNING: Unable to find required component 'com.redhat.KioskWithKeyboard.WindowManager'
|
|
gnome-session[31143]: gnome-session-binary[31143]: WARNING: Unable to find required component 'com.redhat.Kiosk.Script'
|
|
gnome-session-binary[31143]: WARNING: Unable to find required component 'com.redhat.Kiosk.Script'
|
|
gnome-session-binary[31143]: Entering running state
|
|
gnome-session[31214]: Unable to init server: Could not connect: Connection refused
|
|
gnome-session-f[31214]: Cannot open display:
|
|
```
|
|
For some reason the user got the first instead of the default desktop session. This can be fixed with
|
|
|
|
```
|
|
USER_WITH_BROKEN_LOGIN=...
|
|
systemctl stop accounts-daemon.service
|
|
rm /var/lib/AccountsService/users/$USER_WITH_BROKEN_LOGIN
|
|
systemctl start accounts-daemon.service
|
|
```
|
|
|
|
## Notes
|
|
|
|
For normal users there will be a [`pam_access(8)`](https://linux.die.net/man/8/pam_access) error even for
|
|
successful logins. The reason is that we use pam_access twice. First for admins
|
|
and then - depending on the system's configuration - for normal users. Obviously
|
|
the first one will fail unless the user in question is recognized as an admin.
|