<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ssh on ilikeorangutans</title><link>https://kuelzer.ca/tags/ssh/</link><description>Recent content in Ssh on ilikeorangutans</description><generator>Hugo</generator><language>en</language><copyright>© 2026 Jakob Külzer</copyright><lastBuildDate>Sat, 18 Apr 2026 15:20:20 -0400</lastBuildDate><atom:link href="https://kuelzer.ca/tags/ssh/index.xml" rel="self" type="application/rss+xml"/><item><title>Passwordless sudo with remote `nixos-rebuild` and SSH keys</title><link>https://kuelzer.ca/posts/2026-04-18/remote-nixos-rebuild-ssh-key-sudo/</link><pubDate>Sat, 18 Apr 2026 14:58:23 -0400</pubDate><guid>https://kuelzer.ca/posts/2026-04-18/remote-nixos-rebuild-ssh-key-sudo/</guid><description>&lt;p&gt;In my homelab I now have a few machines that run NixOS. This came to be because I wanted the ability to quickly rebuild machines from scratch without having to fiddle with individual settings. Thanks to NixOS I now have a repository that holds a flake that can build bootable images and perform remote &lt;code&gt;nixos-rebuild switch&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;Having the ability to remotely perform &lt;code&gt;nixos-rebuild switch&lt;/code&gt; is great. All changes are tracked in git, I can standardize certain aspects via Nix modules and it covers all aspects of a system, something I never really got to work reliably in Ansible. Remote &lt;code&gt;nixos-rebuild&lt;/code&gt; switch works by specifying &lt;code&gt;--target-host user@host&lt;/code&gt; which will use ssh to perform switch on the other machine. If pubkeys are set up authentication will be automatic. However, if the remote user is not root, and it shouldn&amp;rsquo;t be, &lt;code&gt;sudo&lt;/code&gt; is required via &lt;code&gt;--sudo&lt;/code&gt; and &lt;em&gt;that&lt;/em&gt; will require password and with &lt;code&gt;-S&lt;/code&gt; &lt;code&gt;nixos-rebuild&lt;/code&gt; will ask you for the password. Not ideal.&lt;/p&gt;</description></item><item><title>SSH (Remote) Tunnels</title><link>https://kuelzer.ca/posts/2011/01/02/ssh-remote-tunnels/</link><pubDate>Sun, 02 Jan 2011 12:36:58 -0400</pubDate><guid>https://kuelzer.ca/posts/2011/01/02/ssh-remote-tunnels/</guid><description>&lt;p&gt;Just figured out how SSH remote tunnels work and wanted to write it down.&lt;/p&gt;
&lt;p&gt;Nomenclature:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;em&gt;[Local] Client&lt;/em&gt;: your local computer. In fact, if I say local, I mean the client.&lt;/li&gt;
&lt;li&gt;&lt;em&gt;[Remote] Server&lt;/em&gt;: the server you connect to. If I say remote, I mean server.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="forward-tunnels"&gt;Forward Tunnels&lt;/h3&gt;
&lt;p&gt;Your standard tunnel, allows you to take a local port and redirect it to a remote port on the server:&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;$ ssh -L REMOTEPORT:client:CLIENTPORT user@server
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Now, that by opening a tunnel in this way:&lt;/p&gt;</description></item></channel></rss>