You are trying to use an old tutorial for an obsolete OS.
You appear to have installed an (unspecified) Raspbian using an unusual tool, which appears to be designed to create bootable drives from an ISO image.
I suggest you install a current Raspbian using one of the recommended tools.
You can enable ssh headlessly as described in How to set up networking/...
Based on your description, you have installed a fresh copy of Raspbian. Openssh-server is not enabled by default, so you will not be able to ssh to it until you do.
Also, you need to do "ssh firstname.lastname@example.org", unless you are logging in from a "pi" account from your linux box.
Now, what do you see on your monitor right after you attach power to the Pi? ...
Assuming you have correctly written your image on your SD card, here is schematic about how zeroconf work (as specified by @tpack) if you want contact your raspberry with raspberry.local name. Maybe this can help you better understand. Normally if the OS is correctly written and started RPi must obtain an ip addr on her ethernet interface when you plug your ...
Based on your answer that there wasn't a boot partition, your report that the display doesn't work, and an experiment that I've just conducted, I suspect that UNetbootin doesn't do a proper job of installing Raspbian.
Since you're just getting started, please try this: Get a copy of balenaEtcher and use it to re-flash your microSD card. Try the boot ...
The tutorial you reference only enables ssh it does not enable the avahi-daemon (zeroconf) which is what you need if you want to connect via a hostname instead of an IP address. So you'll need the IP address in order to ssh to the pi.
Since you are on Linux Mint, try installing nmap and then scanning your network to find the pi. Substitute the appropriate ...
You receive the message below, trying to enter in your Raspberry with ssh:
Permission denied (publickey)
because in your Raspberry the configuration file
contains the option:
and there is a mismatch between your new private key in the Mac (generated with ssh-keygen) and the corresponding old public key ...
macOS caches public keys keys in .ssh/known_hosts and normally warns if there is a conflict.
If this is your problem (and you haven't adequately explained what you did or what error you see) it can be fixed by deleting the offending key (or the whole file). There are many ssh settings on the Mac which determine how ssh connects.
For those who prefer a solution involving only scripts dropped into the FAT32 boot partition, here is how to do that. [Edit: The files are now available in a project pi-boot-script.]
As mentioned in other answers, it involves the command-line arguments with which the Linux kernel is started. Those arguments are in /boot/cmdline.txt.
I have tested this on ...