Dfyjkt

The other answers seem to have overlooked one thing in your question:

Once that happens, I'm no longer able to connect remotely even using the new IP address

DDNS will help you find out the new IP address, but that doesn't seem to be the problem here.

Unfortunately, the server getting a new IP should not be a problem in the standard setup where the ISP provides a router, the server has an internal address behind the router, and the router does the port forwarding. You might need to provide more information about the network topology to get a good answer.

What I could imagine is the server not being behind a router and doing its own PPPoE connection, and a) the ssh server binding to the specific interface address at the point of server restart, b) a firewall on the machine that permits incoming ssh to just the server's IP with the firewall not updating when the IP changes.

To check the first case, do a netstat -nta | grep -w 22 | grep LISTEN. If it says 0.0.0.0:22, that's ok; if it lists a specific IP, then check the sshd config file (/etc/sshd.conf) for ListenAddress.

To check the second case, do iptables -L -n and check if one of the rules in the INCOMING chain matches your server's IP and port 22.

If one of these has the current server address, you'll need to either change it to 0.0.0.0 (make sure you know about the security implications), or update the rule/configuration whenever the IP changes.

Edit

As the server is behind a router, the above ideas probably don't apply(*). In this setup, the router has an external IP (which changes daily), and your internal devices should have some 10.x.y.z or 192.168.x.y addresses which shouldn't change. You connect to the external address, and the router should a port-forwarding rule to the internal address.

This port forwarding shouldn't break when the external IP changes (existing ssh connections will be dropped however), but maybe it's a rule that wasn't setup by you, but by some UPNP magic, with the router dropping UPNP forwards when it gets a new address, and sshd only invoking the rule when it restarts. Did you set up a port forwarder within the router yourself.

Or, it's the internal IP of the server that changes - in that case, something is severely broken with your DHCP. Give your server a fixed internal address.

Or, are you using IPV6? There are some configurations where a device keeps changing its IP to make it less easy to track. See, for example, https://www.internetsociety.org/blog/2014/12/ipv6-privacy-addresses-provide-protection-against-surveillance-and-tracking/ - but in that case, shame on you for not mentioning it in your original post. This might mean your router not doing NAT at all, and my original ideas still being valid even behind a router.

Dynamic DNS is one option, another is having the server mail or otherwise send you it’s IP. A simple HTTP call would do (to an endpoint you control and log requests on).

Solving the whole public networking the the other way around is possible as well; you could have the server setup a reverse tunnel, or a VPN connection, which will not be affected by the IP change.

Regarding services not responding on the new address: this completely depends on your network setup. For example: WAN IP on an internal interface via DHCP and an SSH server set to only listen to the IP on your interface known at startup would mean sshd has to be restarted on interface changes.

You should really look into ddns services.
As far as remotely being able to connect to a certain machine with dynamic ip address; ddns is the most commonly used solution.

head over to https://noip.com and signup for an account (it's, errr... supposedly..coff..cof .. Free for 1-3 machines running on the same network(if im not mistaken, dont quote me here: its been a while since ive trusted any of these 'free' services... ).
There are also other alternatives such as Afraid DNS (https://freedns.afraid.org/
And even, Cisco's, Open DNS : could also be utilized (provided that this is not you're only client, i'd suggest you sign up for an umbrella account trial, take it for a spin and later sign-up for the real deal >>> they even got one of them GUI-like downloadable extensions which would automatically renew the the ddns hostname
whenever your clients ip change. It really is, the easiest, non-tech savvy way that i'm aware of[just in case you gotta call up one of your clients and ask'm to download the GUI rather .... ])

I'm able to setup SSH, and it works both locally and remotely... until
the IP address changes. Once that happens, I'm no longer able to
connect remotely even using the new IP address.

Sometimes, it takes a while for DHCP changes to take effect. Try to recycle the DHCP client on the target machine

$> sudo dhclient -r
$> sudo dhclient

Do I need to restart the service every time the IP address changes?
If so, why?

No. You only need to recycle your ssh service when the configuration changes (/etc/ssh/sshd_conf).

Is there any other action I need to take when the IP address changes in order to allow SSH access?

No.

I have a solution that assumes you have sendmail set up on your target machine.

This script sends an email that shows the IP address that the world thinks we have (Thanks ipify.org). Email will always have the most current IP address.

1. Create dhcp-notify bash script (without the .sh extension)


2. 
   

   Put the script in /etc/dhcp/dhclient-exit-hooks.d

   
   
   

   #!/bin/sh
   case "$reason" in (BOUND|RENEW|REBIND|REBOOT)
   (
    echo To: me@my.email
    echo From: me@my.email
    echo "Content-Type: text/html; "
    echo Subject: DHCP reason: $reason
    echo
    echo Your IP address is: `curl -s https://api.ipify.org`
   ) | sendmail -t
   ;;
   esac
   

   
   

If this doesn't work, you could always set up a cron to send you the current IP address (lose the case statement).

#!/bin/sh
(
 echo To: me@my.email
 echo From: me@my.email
 echo "Content-Type: text/html; "
 echo Subject: IP address change
 echo
 echo Your IP address is: `curl -s https://api.ipify.org`
) | sendmail -t

Thinking outside the box - could you arrange a fixed IPv6 address? It's usually only IPv4 addresses that need to change, due to their scarcity.

What I've been doing for almost a year.
I ran into your problem in January this year while giving a speech at my local university.

This script has been running on my machine ever since then:
//Pretty much self-explanatory//

import smtplib
from requests import get
import time

user = 'exampleemail@gmail.com'
psd = 'examplepassword'
msg = 'Hey, your ip has changed! Use this one from now on: '
currip = '0.0.0.0' # It'll send an email the first time you execute this aswell
while True:
 newip = get('https://api.ipify.org').text
 if currip == newip:
 print("nonewip")
 #You can just comment the line above this one if you want to
 else:
 tmpmsg = "n"+msg + newip +" The old one used to be: "+currip
 currip = newip
 server = smtplib.SMTP('smtp.gmail.com', 587)
 server.connect('smtp.gmail.com')
 server.ehlo()
 server.starttls()
 server.ehlo()
 server.login(user,psd)
 #You can change the second parameter, use ('from','to','message')
 server.sendmail(user, user, tmpmsg)

 server.quit()
 with open('/home/pi/DEV/iphistory.txt', 'a') as f:
 f.write('newip: '+currip+'n')
 f.close()
 print('New IP Found: '+tmpmsg)
 time.sleep(7200)

Python 3.x should work flawlessly
Maybe not the best solution out there, but it works.

You'll get an email in your Inbox each time the machine's public IP changes.

Now, regarding your questions:

Do I need to restart the service every time the IP address changes?
If by restarting the service you mean re-establishing the ssh connection, yes.

If so, why?
Because if the address you're trying to communicate with no longer provides the service you're looking for. It's not your machine anymore.

Is there any other action I need to take when the IP address changes in order to allow SSH access?
Just SSH to the new address.

Cheers!
JSR

It is worth viewing this from a different side: usually, it's much simpler to create an outward connection from the machine that requires your attention (DNS, NAT and other firewall settings do not matter at all or are much simpler).

You could use this to establish a bullet-proof and simple solution to get into a remote machine R. The only requirement is that you can provide public ssh access to one of your own local machines (let's call it S). Then proceed as follows:

1. 
   

   Create outward ssh connection from R to S, establishing a reverse tunnel back into R:

   
   
   

   ssh -L 22:<address-of-S>:22000

   
   


2. 
   

   On S, use the reverse tunnel to ssh into the remote machine R:

   
   
   

   ssh -p 22000 127.0.0.1

   
   

Step 1 could be triggered manually and on-demand by the remote side whenever your assistance is needed. Alternatively, you could create a service on R that will continously maintain such a reverse tunnel to S.

I used such a setup to log into remote (mobile) systems that were behind firewalls/NAT and which had no DNS entries at all.

If you just need remote login, use mosh. Apart from being able to cope excellently with IP changes (with almost no latency during the switch) it has also other advantages over plain ssh, like local predictive echo, low latency, way faster recovery from broken links.

If you specifically need ssh (say, you need X11 forwarding or something), I suggest setting up VPN (e.g. OpenVPN), preferably over UDP, with a short keepalive. TCP connections (i.e. your ssh) over VPN will heal and remain connected after IP change, it will just take longer (up to a minute or so), but you can play with /proc/sys/net/ipv4/tcp_* entries to make it more acceptable.

Edit:

• mosh needs ssh for authentication, but once authenticated, the connection stays until you log out (or reboot), and you can investigate the failure of ssh at your leisure (e.g. strace -f -p pid_of_sshd)


• it is possible to use mosh without ssh, answer adapted from here:

On the server run:

mosh-server new -p $randomport -- $shellprogram

you get an result like QzdRHbAWzL7eRobi75DCrz

On the client run:

MOSH_KEY=QzdRHbAWzL7eRobi75DCrz mosh-client $serverip $radomport

Note that $serverip has to be an ip, no hostname resolution.

How you get the key from one side to the other is up to you. I'd suggest encrypting with a pre-shared key and instant-messaging, mailing, or making a local user dictate it via phone call.

• if there is really a problem with ssh, install inetd and run ssh from there, not as a standalone daemon, e.g. by this configuration line for "classic" inetd.conf, this will run a new daemon each time you log in (note that not all inetd forks handle ipv6):

ssh stream tcp6 nowait root /usr/sbin/sshd sshd -i