Connecting
The way to connect is with ssh, and you can read much more about that here. You can then also transfer files with scp, sftp, or use tools like WinSCP or Webdrive; and you can run X11 applications with x2go, using ssh as the connection engine.
An overview of the available shared computing resources can be found here.
Note: Since autumn 2023, all external login will use 2FA, and possibly a jumphost. See below.
An Inside Job
The "UiO network" usually means being on the cabled network at campus. However, some services will also be available on the eduroam wifi (on campus) or with VPN.
From the UiO network, you can log in to e.g. mimi from a Mac or Linux machine quite simply:
$ ssh username@mimi.uio.no
Possibly, you won't even need to specify the username@ or .uio.no parts.
Modern Windows machines comes with ssh too, or you can use PuTTY.
login.uio.no
The central server login.uio.no is available from all over the world, for all UiO users. Some services may also go through this machine, so you should make sure you can log in here.
- If you have a private Linux or Mac machine, you might want to add the following (long) lines to your ~/.ssh/known_hosts , to cover the many aliases for login. Also, remove old keys for this machine. You can use any text editor you prefer:
gothmog.uio.no,gothmog,129.240.114.52,login-2fa-azure.uio.no,login-2fa-azure,129.240.114.36,morgoth.uio.no,morgoth,2001:700:100:8070::36,login1.uio.no,login1,2001:700:100:8071::52,linux.uio.no,linux,login.uio.no,login,logon.uio.no,logon,ssh.uio.no,ssh,login2.uio.no,login2 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP4WaWcxR4QfUOu/tCHgjJv+dcMR5LAGo1coq9IMrMq0 morgoth.uio.no,morgoth,129.240.114.36,login-2fa-azure.uio.no,login-2fa-azure,129.240.114.52,gothmog.uio.no,gothmog,2001:700:100:8071::52,login2.uio.no,login2,2001:700:100:8070::36,linux.uio.no,linux,login.uio.no,login,logon.uio.no,logon,ssh.uio.no,ssh,login1.uio.no,login1 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP4WaWcxR4QfUOu/tCHgjJv+dcMR5LAGo1coq9IMrMq0
- You will need to complete two-factor authentication (2FA). See here for how to set this up on your phone, and see also examples further down in this guide.
Note that login.uio.no does not have geo-specific software, can't access Geo storage, and has limited computational capacity. For non-trivial tasks, you should consider using a Geo server.
Geo servers
The servers mimi.uio.no and pingo.uio.no are also available from everywhere (with 2FA), and can also be used as a jumphost (see below) to reach other servers or desktop machines.
From the other side
If you just want to log in to a Linux system, you can try Geofag login VDI. This will give you a desktop session, and you can connect to other servers from here.
The rest of this section outlines alternatives, also useful for e.g. sshfs.
As stated above, a few servers are available for login from everywhere.
If you use a Windows laptop with UiO setup, it should behave as being on the UiO network (because of built-in VPN). You can use e.g. Putty and WinSCP as if you were inside the network.
Else, if you are outside the UiO network, you can consider downloading and installing VPN. If you connect with VPN first, chances are you won't have to bother about 2FA or SSH proxy.
Note that VPN has some issues. After disconnecting VPN, you might need to restart your network:
$ sudo systemctl restart NetworkManager
The rest of this section assumes you can't or won't use VPN.
TL;DR: If you use a Linux or Mac laptop, make sure your file ~/.ssh/config looks something like this, substitute your username where indicated:
Host *.uio.no !login.uio.no User username ProxyJump username@login.uio.no ControlMaster auto ControlPath /tmp/%r@%h:%p ControlPersist 10m
This will set up the correct ProxyJump, and make sure you won't need to use 2FA more than necessary. This can also be useful for servers outside the UiO network, e.g. HPC servers.
For using ProxyJump with PuTTY (Windows), USIT has a suggestion (in Norwegian). PuTTY can also handle 2FA.
For more details, keep reading!
From outside the UiO network, you can only log in to login.uio.no, and a few other select servers. Be prepared to use two-factor authentication. If you have set 2FA up on your phone, it could look like this:
In the above example, I am prompted to type in the One-Time Password (OTP) from Google Authenthicator (here: 964037). If you use MS Authenthicator, you will need to confirm the login on your phone.
A few things to note:
- The remote machine in this example is ssh.uio.no, which is one of the aliases for login.uio.no.
- The OTP is echoed directly after the prompt text, no space or ">" or ":" sign.
- I use keys to log in. If you don't use keys, you will be prompted for your password as well.
- The prompt and "motd" text reveal I am actually logged in to gothmog.uio.no, one of the servers behind login.uio.no.
- 2FA is not cached. If you want to log in again, you'll have to use 2FA again. To get around this, you can use a control master, as shown above. This should also enable you to use ssh-based applications that can't (successfully) prompt for a OTP.
Going deeper
In the following, we'll assume the 2FA and password bits are handled.
To log in to elefant, you can log in to login.uio.no first, and then log in to elefant:
$ ssh username@login.uio.no (2fa and password here) gothmog$ ssh elefant
This is a bit cumbersome, and it won't work with sshfs or x2go. Then you must use login.uio.no as a ProxyJump.
ProxyJump
The ProxyJump mechanism is build in to ssh, you can use it like this (Mac/Linux):
$ ssh -J username@login.uio.no username@elefant.uio.no
You can automate this with the ProxyJump statement in your ssh config file, as shown above.
If you haven't set yourself up with keys, you'll need to type your password twice. You will also be asked to complete 2FA.
Can't 2FA or ProxyJump?
Not all ssh-based applications know how to prompt for 2FA, or will enable you to use a ProxyJump (x2go or sshfs might be relevant examples here).
In some of these cases, you can use the ControlMaster mechanism, as outlined above. You will need to log in interactively first, and subsequent logins (to the same host) will then use the data channel set up by ssh. If your ssh-based application can parse the ssh config file correctly, that is.
The ssh tips and tricks page has a lot of other information that might be useful, including some examples.
Traveling abroad?
If you want to go abroad, you should also make sure you comply with these security measures.
Getting around local firewalls
If the default port for ssh (22) is blocked on your local net, you can try connecting to pingo with port 443 (usually used for https, and thus usually open):
$ ssh -p 443 pingo.uio.no
Apart from pingo, also login.uio.no will work with port 443.
With putty, you can set the port in the startup window, next to the host name:
For other ssh clients, consult your documentation for how to use a specific port.
Blocked?
This section is deprecated as all servers use ProxyJump and/or 2FA, as explained above. It is kept for now.
If you cannot connect with ssh (you get no login prompt) it could be that ssh traffic is blocked.
fail2ban blocking
Every day, literally thousands of automated attempts are made to log in to our servers from machines (IP addresses) all over the world. To reduce the chances of these attempts succeeding, we have an automated system (fail2ban) that blocks ssh connections for a given IP address if the address has three failed logins in ten minutes. The block will be lifted after six hours.
It could look like this when I attempt (and fail) to log in from my home network:
$ ssh serac.uio.no hpverne@serac.uio.no's password: Permission denied, please try again. hpverne@serac.uio.no's password: Permission denied, please try again. hpverne@serac.uio.no's password: Permission denied (publickey,password). $ ssh serac.uio.no ssh: connect to host serac.uio.no port 22: Connection refused
All ssh-related connections are now blocked, eg. scp, sftp and sshfs.
Of course, this will also block legitimate logins if you fumble with your password.
If this happens to you, you have the following options (in no particular order):
- Log in to a different machine (see list above), and log in to your destination from there.
- See if you can change your (public) IP address.
- Wait six hours.
- Drop us a line. We can lift the ban, but keep reading.
To unblock you, we will need to know the IP address you are connecting from. You can visit whatismyipaddress.com or just google "what's my ip". On Mac/Linux, you can try
$ curl ifconfig.co
84.215.46.78
Here are some tips to avoid getting blocked:
- Use ssh keys, that way you won't (mis-)type your password at all.
- If you notice you typed your password wrong the first time, take care.
- Try to type it in a text window to see if your keyboard is set up as expected.
- Try to log in to eg. password.uio.no to see if your account is OK.
- Let us know in advance if you are going someplace abroad and need to log in. (We'll still need to know the address you will be connecting from, though).
Note that UiO addresses (129.240.*) are never blocked.
Administration
The rest of this article is for your admins. We need help and guidelines, too!
Installation
To setup fail2ban on a new RedHat or Fedora machine, install fail2ban with the following script:
# /uio/lagringshotell/geofag/admin/it/Lib/fail2ban/fail2ban-geosetup.sh
This will install the RPM and the local configuration, start the server, and install a new /etc/hosts.allow to enable ssh logins. Inspect the script for details. The script doesn't work for Ubuntu, but you can replicate the steps manually (apt install ..., etc.)
Configuration
The local configuration for fail2ban is the following files:
/etc/fail2ban/jail.d/customisation.local /etc/fail2ban/jail.d/exceptions.local
The upstream version of these files are (currently) in /uio/lagringshotell/geofag/admin/it/Lib/fail2ban/ . Note that the upstream files are currently not re-distributed automatically, so copy it as needed if you make changes here.
Exceptions
Exceptions can be made for a single IP address, or whole networks in CIDR format.
Ad hoc exceptions can be made locally to the exceptions file. The syntax should be fairly self-explanatory. If the exception should be global and permanent, put it in the upstream file, too. In any case, make a comment documenting why you make this exception.
When exceptions are added to the appropriate file, reload the server. Eg:
serac# fail2ban-client reload sshd
Unblock
Creating an exception may not be enough to unblock addresses already blocked ("in jail"). Or perhaps you don't need to make exceptions, you just need to unblock a hapless user.
Check the blocked addresses, see if the user's address really is there. Eg:
serac# fail2ban-client status sshd | grep 84.215.46.78 `- Banned IP list: 153.193.110.198 (....) 84.215.46.78 (....)
Right. So remove it from the banned list:
serac# fail2ban-client set sshd unbanip 84.215.46.78 84.215.46.78
Check again to verify the address is unblocked.
As it is difficult for us to test ssh login from the same address or network as the user, ask the user to verify that the problem has been resolved.
More information
- Fail2ban homepage
- As usual, google....