grep 192.168.111.100 ~\/.ssh\/known_hosts<\/strong>\nraspberrypi,192.168.111.100 ecdsa-sha2-nistp256 AAAAE2...ABBBBqf<\/pre>\n\n$ ssh pi@192.168.111.100<\/strong>\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\n@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @\n@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\nIT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!\nSomeone could be eavesdropping on you right now (man-in-the-middle attack)!\nIt is also possible that a host key has just been changed.\nThe fingerprint for the ECDSA key sent by the remote host is\nSHA256:6rR+0\/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.\nPlease contact your system administrator.\nAdd correct host key in \/home\/toff\/.ssh\/known_hosts to get rid of this message.\nOffending ECDSA key in \/home\/toff\/.ssh\/known_hosts:10\nECDSA host key for 192.168.111.100 has changed and you have requested strict checking.\nHost key verification failed.<\/pre>\n\nYou could now open the file ~\/.ssh\/known_hosts<\/code> in a text editor and delete the offending line 10 from the list by hand, but there is a better way: with ssh-keygen -R IP-address<\/code>, you remove the key from the file with a single command, so the next time you connect, you start from scratch \u2013 and have to confirm the key just like the very first time you connected to this machine. This also works if you use the hostname instead of the IP address to connect. To be on the safe side, the command copies the old state to ~\/.ssh\/known_hosts.old<\/code> in the same directory.<\/p>\n\n$ ssh-keygen -R 192.168.111.100<\/strong>\n# Host 192.168.111.100 found: line 10\n\/home\/toff\/.ssh\/known_hosts updated.\nOriginal contents retained as \/home\/toff\/.ssh\/known_hosts.old<\/pre>\n\n$ ssh pi@192.168.111.100<\/strong>\nThe authenticity of host 'raspberrypi (192.168.111.100)' can't be established.\nECDSA key fingerprint is SHA256:6rR+0\/i3KnPLds3EuGkfWiudIgu8VMpe1xq+X3I3yNM.\nAre you sure you want to continue connecting (yes\/no)? yes\nWarning: Permanently added '192.168.111.100' (ECDSA) to the list of known hosts.\npi@192.168.111.100's password:\n\nThe programs included with the Debian GNU\/Linux system are free software;\nthe exact distribution terms for each program are described in the\nindividual files in \/usr\/share\/doc\/*\/copyright.\n\nDebian GNU\/Linux comes with ABSOLUTELY NO WARRANTY, to the extent\npermitted by applicable law.\nLast login: Fri Apr 22 08:40:10 2016 from 192.168.178.57<\/pre>\n\nForcibly terminating an SSH connection<\/h2>\n\n If you are logged in to a remote machine via SSH and shut it down with shutdown<\/code>, halt<\/code> or reboot<\/code>, the system doesn’t kill the SSH connection abruptly. It stops the SSH server cleanly during shutdown, so you end up back in the terminal of the client machine and can keep working in the same terminal window. Now, I \u2013 and surely other Pi tinkerers too \u2013 like to unplug the Raspberry Pi and plug it back in to restart it quickly and painlessly. This is certainly not ideal for the integrity of the data on the memory card, but if I’m going to set up the system on it from scratch anyway, I don’t much care.<\/p>\n\n\n\t\t\t\n\t\t\t\tSSH connections can be managed with a set of escape sequences.<\/figcaption><\/figure>\n\nThe downside is that SSH usually hangs in the terminal when you do this \u2013 after all, you just pulled the chair out from under it. You could now kill the SSH process or close the terminal window and open it again, but there is a clean solution for this situation, too: SSH knows a number of escape sequences that let you manage the current SSH session. You get an overview of the available commands if you type ~?<\/code> on a new line in the terminal. To be on the safe side, simply press Enter once beforehand.<\/p>\n\npi@raspberrypi:~ # ~?<\/strong>\nSupported escape sequences:\n ~. - terminate connection (and any multiplexed sessions)\n ~B - send a BREAK to the remote system\n ~C - open a command line\n ~R - request rekey\n ~V\/v - decrease\/increase verbosity (LogLevel)\n ~^Z - suspend ssh\n ~# - list forwarded connections\n ~& - background ssh (when waiting for connections to terminate)\n ~? - this message\n ~~ - send the escape character by typing it twice\n(Note that escapes are only recognized immediately after newline.)<\/pre>\n\nThe first sequence shown in the help is exactly the function we’re looking for: if you type ~.<\/code> as text during an SSH session, you terminate the current SSH connection, no matter what. This doesn’t only work with a session that is still active and working (which you could close with exit<\/code> at any time anyway), but also when, for example, you cut the power to the Pi and nothing happens in the terminal anymore. Here, too, it can help to press Enter once more before the actual command. Otherwise the escape sequence may come to nothing.<\/p>\n\nPausing and resuming an SSH connection<\/h2>\n\n The escape sequences can do other handy things, too. For example, you can suspend an SSH connection and resume it later without having to use a terminal multiplexer such as screen<\/code> or tmux<\/code>. If a process takes longer than expected, you can park the connection this way while the process on the remote machine keeps running. Unlike with the two terminal multiplexers mentioned, you don’t have to think ahead that the task might take longer and start them as a precaution. The corresponding sequence is the somewhat cryptic ~^Z<\/code>, where the caret doesn’t stand for a character but for the Ctrl key. So you type ~<\/kbd> and then press Ctrl<\/kbd>+Z<\/kbd>. You then land back in the terminal of the machine on which you originally ran ssh<\/code>. From there, you can pick up the connection again by typing fg<\/code> and pressing Enter.<\/p>\n\n\n\t\t\t\n\t\t\t\tPausing and resuming an SSH connection.<\/figcaption><\/figure>\n\nIf you work on a “truly” remote system over the internet, the connection may well drop. On the one hand, this is because the server terminates the connection after a period of inactivity; on the other hand, your own network infrastructure (read: the router) may interfere. However, you can prevent the timeout with a keep-alive function. Depending on the situation, you can either configure the SSH server accordingly (which of course requires root privileges) or call SSH with the appropriate parameters right away. In that case, you don’t need any special privileges on either system.<\/p>\n\n
Keep-alive on the server side<\/h3>\n\n### Default keep-alive settings:\n$ grep Alive \/etc\/ssh\/sshd_config<\/strong>\n#TCPKeepAlive yes\n#ClientAliveInterval 0\n#ClientAliveCountMax 3\n### Edit the SSH server configuration:\n$ sudo nano \/etc\/ssh\/sshd_config<\/strong>\n\n### In the end, the relevant lines should look like this:\n$ grep Alive \/etc\/ssh\/sshd_config<\/strong>\nTCPKeepAlive yes\nClientAliveInterval 60\nClientAliveCountMax 3\n\n### Restart the SSH server once:\n$ sudo systemctl restart sshd<\/strong><\/pre>\n\nKeep-alive on the client side<\/h3>\n\n### Keep the SSH connection alive from the client side\n$ ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=1 pi@raspberrypi<\/strong><\/pre>\n\nIn the first case, the setting applies to all users who want to log in to the system via SSH. As a rule, you should therefore only make this change if all users actually need it. Most of the time, though, you only need keep-alive in exceptional cases, so it makes sense to set the option only when needed when calling ssh<\/code>. For me, this is the case with a web service I can log in to via SSH, for example. If I start long-running backups there, my router terminates the connection before the backup process can report success. With the keep-alive settings mentioned above, however, that’s no longer a problem.<\/p>\n\n","protected":false},"excerpt":{"rendered":"SSH tips: remove changed host keys with ssh-keygen -R, kill hung connections and park sessions.<\/p>\n","protected":false},"author":2,"featured_media":157,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"lui_source_id":39416,"lui_source_hash":"ee52307882091e69f66ea9735d27f7ed925f6340865d67730060865fc0dc0de4","lui_source_translated":"2026-10-06","lui_source_reviewed":true,"lui_via_url":"","lui_via_label":"","lui_source_url":"","lui_source_label":"","footnotes":""},"categories":[2],"tags":[],"class_list":["post-153","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-gnu-linux"],"_links":{"self":[{"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/posts\/153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/comments?post=153"}],"version-history":[{"count":0,"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/posts\/153\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/media\/157"}],"wp:attachment":[{"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/media?parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/categories?post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/linuxundich.de\/en\/wp-json\/wp\/v2\/tags?post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"SSH](\"https:\/\/linuxundich.de\/wp-content\/uploads\/2016\/05\/raspberry-pi-ssh-steuercodes.png\")