Scenario: You have two Debian boxes on the same network (or at least, reachable/pingable from one to the other), and you would like to ssh from one box (the "client") to the other (the "server"). Both computers have a fresh, clean install of Debian 12.
On the "server" box, run:
$ ip addr
Somewhere in that text will be the IP Address of the computer. Here's what my computer's text looks like:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 14:b3:1f:0f:e4:95 brd ff:ff:ff:ff:ff:ff
inet 10.32.4.15/21 brd 10.32.7.255 scope global dynamic noprefixroute enp0s31f6
valid_lft 40598sec preferred_lft 40598sec
inet6 fe80::16b3:1fff:fe0f:e495/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$
You can cut out a lot of that noise with a "grep":
$ ip addr | grep inet
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host noprefixroute
inet 10.32.4.15/21 brd 10.32.7.255 scope global dynamic noprefixroute enp0s31f6
inet6 fe80::16b3:1fff:fe0f:e495/64 scope link noprefixroute
$
Perhaps even better, and simpler, is this command:
$ hostname -I 10.32.4.15 $
You could also use a web-browser to visit a site that tells you your public-facing IP address, such as https://whatismyip.com or https://whatsmyip.com or https://icanhazip.com althought that might not be the IP you need on your internal network, or you could use your GUI-fied Desktop Environment's tools.
From the client computer, try pinging the address of the server. In the example below, the IP address I am using is 10.32.4.15. Of course, you'll need to substitute the IP address of your server.
$ ping 10.32.4.15 -c 4 PING 10.32.4.15 (10.32.4.15) 56(84) bytes of data. 64 bytes from 10.32.4.15: icmp_seq=1 ttl=63 time=0.416 ms 64 bytes from 10.32.4.15: icmp_seq=2 ttl=63 time=0.366 ms 64 bytes from 10.32.4.15: icmp_seq=3 ttl=63 time=0.370 ms 64 bytes from 10.32.4.15: icmp_seq=4 ttl=63 time=0.349 ms --- 10.32.4.15 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3058ms rtt min/avg/max/mdev = 0.349/0.375/0.416/0.024 ms
The above indicates a successful connection. The below indicates a failure:
$ ping 10.32.4.15 -c 4 PING 10.32.4.15 (10.32.4.15) 56(84) bytes of data. --- 10.32.4.15 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3070ms
If you have a failure, you'll need to fix the networking problem before going further.
A default install of Debian 12 automatically installs the client-side piece of ssh. This allows you to ssh from a client computer to a server computer. But the default install does not install the server-side of ssh. So we'll need to do that on the "server" computer. So, on the computer to which you want to connect, run:
$ sudo apt install ssh
This will make sure that both the client-side and the server-side pieces of ssh are installed.
There are basically two ways you can connect to and login to a server using ssh: You can connect using a username and password, or you can connect using a key. We'll look at both methods.
When you installed Debian 12, you were asked to create a normal user. This user will be the user account we'll use. For the purposes of this tutorial, we'll assume the user account is named "bob".
Again, remember to use the IP address of your server, not the example IP address I'm using below.
$ ssh bob@10.32.4.15 bob@10.32.4.15's password: Linux jenni 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Aug 22 08:26:45 2023 from 10.34.0.113 bob@jenni:~$
Remember to log out of the server ("$ exit") before continuing to the next step.
If your username on the client computer is the same as your valid user on the server, you do not need to provide the "bob@" portion on the command; you can just do:
$ ssh 10.32.4.15 bob@10.32.4.15's password:
and the ssh command will assume you want to connect with your current user's name.
Remember to log out of the server ("$ exit") before continuing to the next step.
Connecting with a key is a bit more secure than connecting with a username and password (as long as you remember to kill the key if and when a user is deleted from the server system), and is more convenient for the client user, but takes a little more initial setup.
SSH Key pairs come in .. wait for it, pairs. There's a public key, and there's a private key. Think of the public key as a lock. You can duplicate this lock as many times as you want, and hand them out to as many people as you want ("You get a lock. And you get a lock. And you..."). Those people have possession of the "public key", and they can then use that lock (public key) to lock some random door. You're the only person who can unlock that door, because you're the only one (hopefully!) who has possession of the "private key". If you come across a door that is locked with someone else's public key, you won't be able to open that door, because you don't have the private key that unlocks that lock. If someone gives you their public key, you can then lock some door, and then no one will have access except the person who has the private key that matches that public key lock.
An SSH key is not a physical key, of course; it's just a computer code that is very hard to break. There are several ways to generate a key-pair, but the ssh package we installed earlier has a key-generation tool within it, that we can use.
We can use this tool ("ssh-keygen") on the server, and then copy down the private key to the client, or we can use the tool on the client, and then copy up the public key to the server. However, you don't want to do the former, because then you'd have to manage a private key for every server to which you connect. That can get messy, fast.
So, instead, we'll do the latter, which is the "standard" way of doing things. We'll create the key-pair on the client, and then upload the public key to the server.
First, to make sure you don't already have a key-pair, look for, and in, a directory named ~/.ssh on your client computer. If this is a new, fresh install of Debian, that directory probably does not exist. If it does exist, it probably does not have the files "id_rsa" and "id_rsa.pub", which are the default file names for the private (the "key") and public (the "lock") keys, respectively. If you don't have this directory, or if the directory does not have these files, then you're ready to generate a key-pair. Run the command below, and just accept all the defaults. Leave the passphrase blank, for now, until you've been successful once with the process. You can always redo this process later to add a passphrase, which increases security even further. If you already have private and public keys in your client's .ssh directory, you can just skip this step and move on to the next step.
$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/bob/.ssh/id_rsa): Created directory '/home/bob/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/bob/.ssh/id_rsa Your public key has been saved in /home/bob/.ssh/id_rsa.pub The key fingerprint is: SHA256:J+q6NSnnTt/7BBvTGJ5PlnXosDC82s0O3o/ZHwgpB7s bob@jenni The key's randomart image is: +---[RSA 3072]----+ | | | . . . | | p = + +| | . . = .B *=| | oS+.=*.o.=| | ..o-ooBo. | | .. E; +o+. | | .o q ..= +.| | o+.l ..*.=| +----[SHA256]-----+ $ ls .ssh/ id_rsa id_rsa.pub $
Now you need to upload the public key (the "lock") to the server, so that bob's account can be locked with bob's lock. Then no one who does not have bob's private key can get into the account.
$ ssh-copy-id -i ~/ssh/id_rsa.pub bob@10.32.4.15 /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/bob/.ssh/id_rsa.pub" /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys bob@10.32.4.15's password: Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'bob@10.32.4.15'" and check to make sure that only the key(s) you wanted were added. $
$ ssh 10.32.4.15 Linux jenni 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Tue Aug 22 10:43:49 2023 from 10.34.0.113 bob@jenni:~$
Since I was logged into my client computer as "bob", I did not need to specify "ssh bob@10.32.4.15".