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 suports various secure authentication schemes for users as well as role accounts.
However, some security considerations have to be taken into account, these. These are our principals:
jump.ibr.cs.tu-bs.de)gitlab.ibr.cs.tu-bs.de)fail2ban, currently 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.From outside the IBR network, you can access target hosts only via our specially protected jump host, e.g.:
ssh -J <username>@jump.ibr.cs.tu-bs.de <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.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.
Once this is done, you should be able to reach our SSH endpoints described above from your client host without any interactive authentication.
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.
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. 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, the instance at our university, that feels responsible for IT security throughout our entire complex networks, seems to not fully understand the importance of SSH in the way most experienced Internet users regard this protocol. As a consequence, they seem to regard all connection attempts to TU service endpoints on the default SSH port 22 as potential attacks in some way. To our knowledge, although demanded already back in February 2024, this is neither documented nor reasonable – just rediculous. As of March 2026 there seems to be a mechanism in the TU network that cause quite some trouble. It blocks outside client IPv4 addresses for some time, once a sequence of (even beatifully legitimate and successfully authenticated) SSH port 22 connections have been created. Just annoying, but important to know about for many SSH and GitLab+SSH users. Maybe, you have the chance to avoid problems by using an VPN connection or you make use of our workarounds.
We made proposals to
It seems, none of them have even been considered until early April 2026.
Personal (not TU public) update from CISO office: "Das ist ein mehrstufiges System. Die erste Eskalation erkennt das potenzielle Brute Force wenn 8 SSH-Verbindungen von einer IP innerhalb von 30 Sekunden erkannt werden. Diese Situation wird erstmal nur festgestellt. Tritt die Situation ein zweites Mal innerhalb von 10 Minuten auf, wird die IP für eine Stunde auf die Blacklist gesetzt. Wiederholt sich dieses ein weiteres Mal innerhalb von 4 Stunden, wird die IP für einen Tag auf die Blacklist gesetzt."
🤦♂️