Because you don't really say anything, I'm going to assume that you have a relatively stock Ubuntu installation in that VM.
It muddies the water slightly when you say that you are using the "public" IP address of the VM, because this could mean a few different things.
However, one thing is worth noting: Your original error ("Network error: Connection refused" when you try connecting to port 22) tells you that you were able to reach the system running inside the VM, and that system said that nothing is listening on the particular IP address and port combination that you reached it on.
I'm pretty sure that the workstation Ubuntu installations do not ship a running SSH server by default. The server variants, however, might very well do so.
Use the VM console to log in, and check whether a SSH server is running. I don't have an Ubuntu system handy at the moment, but in a terminal, this should be similar to
$ service sshd status
It might be referred to as something like ssh, ssh-server, openssh-server or something along those lines instead of sshd, but tab completion on ssh (type sshtab) should get you close. You may need to sudo this, so e.g. sudo service sshd status, but I think regular user access should be sufficient to get a service status (running/stopped) report.
If no SSH server is running, or even installed, then that explains why you got a "Connection refused" error. Install a SSH server using something like:
$ sudo apt-get -u install openssh-server
Verify that the list of packages to be installed looks sane, and confirm. The SSH server will be started at the end of the installation process.
Now, look at /etc/ssh/sshd_config. It will have zero or more Port and ListenAddress directives giving IP addresses or port numbers (the port number defaults to 22 if not specified, and the server will listen on all IP addresses if you don't explicitly tell it otherwise). That's the IP address and port you need to connect to.
If no IP address(es) are specified, ip addr show will show you the network interfaces within the VM and their respective IP addresses. Those are the ones the SSH server will be listening on.
Armed with this information, perform whatever magic incantations are required to get PuTTY to connect to this combination of IP address and port. (This may involve punching a hole or configuring port forwarding in a NAT or firewall, for example.)
Once that is done, you should be able to connect using PuTTY and get a terminal session as an unprivileged user on the Ubuntu VM. From there, use sudo to elevate your privileges on an as-needed basis, just as if you were sitting in front of a physical system.
I recommend setting up public key authentication, and I very much recommend against allowing root to log in directly. However, if you absolutely must allow root to log in directly, then edit /etc/ssh/sshd_config and specify PermitRootLogin yes, then sudo passwd root and give root a good password, and restart the SSH daemon. Again, I do not recommend this.
With that out of the way, what was the issue with your connecting to ports 80 and 443? Port 80 is the default port for HTTP, and port 443 is the default port for HTTPS. If a web server is running, it is likely that it is listening on both of those ports, and when you connect, it will be expecting HTTP requests; in the case of port 443, after SSL negotiation. It is certainly possible to manually issue HTTP requests, but it isn't a terminal login session and a shell. In general, connecting to random ports (even well-known ports) is unlikely to get you the result you are after.
1Normally you would only log on as root from the console, not remotely, and it's likely that the default setting is to disallow remote connections from user root. When connecting remotely, you should log in as a normal user and use sudo to perform any actions as root. – Herb Wolfe – 2017-04-21T00:19:13.417
Ubuntu has no root user password by default. – Journeyman Geek – 2017-04-23T12:04:46.277
@JourneymanGeek It does have a root user, it's just disabled by not having any valid password. Every Linux system has a root user, as discussed e.g. in Does the root account always have UID/GID 0?. There may or may not be a mapping to a username, but the user exists either way.
– a CVn – 2017-04-23T12:05:38.150I'm thinking that something is responding to port 80, but it isn't properly communicating with the SSH protocol. If you tell PuTTY that you want to connect with the Telnet protocol, instead of SSH, you'll likely get different and more usable results. (Even then, your results probably won't be very useful if you're not familiar with the commands of the HTTP protocol.) – TOOGAM – 2017-04-23T13:07:20.727