SSH is the most essential protocol for highly secured communication with a broad range of use cases, e.g. interactive shell sessions, scripted remote execution, automated configuration, remote administration and encrypted data transfers. It supports various secure authentication schemes for users as well as role accounts.
However, some security considerations have to be taken into account. These are our principals:
jump.ibr.cs.tu-bs.de)gitlab.ibr.cs.tu-bs.de)fail2ban, banning for 2 hours after 5 failed attempts within 5 minutes from a single client IP address).PasswordAuthentication on these endpoints, so that users have to use PubkeyAuthentication or GSSAPIAuthentication. (Note that this has implications for new users, when they try to access their account from outside the local network.)x1.ibr.cs.tu-bs.de aka linux.ibr.cs.tu-bs.de. (This was our jump host until early April, which is now a separate host.)From outside the IBR network, you can access target hosts only via our jump host, e.g.:
ssh -J <username>@jump.ibr.cs.tu-bs.de[:port] <username>crunch1.ibr.cs.tu-bs.de
Note, that since 2026-03-31 we have e new dedicated jump host jump.ibr.cs.tu-bs.de. It is no longer just an alias for x1.ibr.cs.tu-bs.de. This means:
x1.ibr.cs.tu-bs.de aka linux.ibr.cs.tu-bs.de is no longer directly reachable from outside the IBR network. You have to use the jump host as documented here.SSH allows tricky configurations to make things easier. See our workarounds to get an idea.
When you start using this approach, it is important to understand the nature asymmetric cryptography. Please look out for your favorite online tutorial on SSH in general and on pubkey usage. Basically, what you have to do is this:
On your (private) client device, if not done already, create a key pair:
$ ssh-keygen
This should create a pair of files in you $HOME/.ssh/ directory: the private key id_ed25519 and the public key id_ed25519.pub. It is important to keep the private key undisclosed and not even copied to any IBR server, usually. Only the public key should get added as an additional line to your IBR's account $HOME/.ssh/authorized_keys. This can be acchieved by
$ ssh-copy-id <username>@linux.ibr.cs.tu-bs.de
Note that for this initial setup, your client has to be inside the IBR network. See the section below for an email-based workaround.
Once this is done, you should be able to reach our SSH endpoints described above from your client host without any interactive authentication.
TU Braunschweig users and IBR users located externally may add public keys to their list of authorized_keys through an email robot. You can send an email...
ssh-pubkey@ibr.cs.tu-bs.deaddid_ed25519.pub, in the first line of the mail body.If the mail is received, validated, your sending mail address matches your account unambigously and reliably, then the public key will get added to your authorized_keys. In any case, you should received an automatic response within a few minutes.
You may use Kerberos client tools to fetch a Kerberos token from IBR, that subsequentally allows to authenticate to various IBR services in a single-sign-on manner including the IBR SSH servers.
You have to have the according tools kinit, klist, kdestroy installed. On Linux systems they might be provided by the krb5-user package. Please make sure, you get this software from a reliable repository. Then you may request a ticket:
$ kinit <username>@IBR.CS.TU-BS.DE
This is the only moment, where you have to authenticate with your password. The Kerberos communication to the IBR ticket granting server is done in a secure way. You may check your cached ticket(s):
$ klist
Credentials cache: API:2EB80344-A226-4FE6-BE7F-31768D9935AD
Principal: <username>@IBR.CS.TU-BS.DE
Issued Expires Principal
Apr 10 12:04:54 2026 Apr 17 12:04:54 2026 krbtgt/IBR.CS.TU-BS.DE@IBR.CS.TU-BS.DE
From now on (until the ticket expires or you drop it), you should be able to access various IBR services without further authentication, including our SSH endpoints described above. Once, you leave your working session, please release your token to improve security: kdestroy.
Unfortunately, there is a rediculous mechanism out of our control, that may cause severe trouble when you use SSH more than once in a while. Please read the details.