UServ is a name referring to a conglomeration of directory and file services as well as shell/compute access to Unix servers.
Your UServ home directory is available to you upon logging in on all lab computers within the department.
All UServ users can log in to the machine at
userv.fbi.h-da.de using SSH.
This may be used for accessing your UServ home directory remotely.
SSH host key fingerprints for userv.fbi.h-da.de
3072 SHA256:i9y9IfvTfydgLq4fcLs7a9+wUJOk9UO0sHTtQWwVXlQ (RSA)
256 SHA256:XFam+16T3kbxscur9nYm5ez6Jma5UYPDhtWwuRJ5AYw (ECDSA)
256 SHA256:fJaHp1hrI6Z6AP9Qa0o7v7Kwmkg5xbq2ygAkN8ppWK4 (ED25519)
Password-less login using SSH public key authentication
Access to your home directory is provided using kerberized NFS. Your files can
only be read with a valid Kerberos ticket (which is established for you upon
login). This has the side-effect of also preventing the SSH daemon from reading
SSH public keys you may have stored at
To still allow for password-less login using SSH keys, public keys may be stored within the LDAP directory. SSH is configured to read them from there.
A helper program for this is provided at
(also in PATH).
To set up public key login for the current user, using the keys from an
$ userv-set-authorized-keys ~/.ssh/authorized_keys
Please remember that you have to create a valid keberos ticket (with "kinit") to access your home directory.
The directory hierarchies at
/share/LabDisk/pub are available on all lab computers as well as served
…/LabDisk/pubis available at https://userv.fbi.h-da.de/pub and is accesible by the public at large
…/LabDiskis available at https://userv.fbi.h-da.de/LabDisk and requires authentication (any university account is ok)
These can be used for distributing files to students.
Authenticating users within your own applications
Within the department network you can outsource user authentication to the UServ LDAP servers.
- host name: id.fbi.h-da.de
- port: 389 (when using STARTTLS) or 636 (with SSL/TLS from the start)
- base DN:
- bind DN: leave empty for anonymous bind
- bind password: leave empty, too
- user name attribute: uid
The general process for authenticating a user against an LDAP service is as follows, starting from a username/password pair entered into your application:
- perform anonymous bind against the LDAP server
- do an LDAP search request to retrieve the DN corresponding to user name (using a filter expression like
(&(objectClass=posixAccount)(uid=$USERNAME))) Take care to properly encode/escape the $USERNAME part for use in an LDAP filter expression.
- if the search yields exactly one result, proceed, otherwise deny access
- using the retrieved DN and the user-provided password, try to re-bind against the LDAP server
- if the re-bind succeeded, the user provided the correct password, otherwise deny access
- enforce application-specific policy
- switch back to the anonymous user by re-binding using empty credentials
NOTE: prefer using a battle-tested authentication library that performs this song-and-dance for you.
As an alternative, consider using GitLab as an OAuth2 authentication provider.