About PuTTy and Tutorials, including a PuTTy Tutorial

After my last post about the powers of PuTTy in conjunction with an SSH-enabled router, I started thinking about tutorials.

I am not a big tutorial-fan, cause I always can't quite shake the feeling that I'm doing something here I have no particular knowledge of. And depending on what I do, this bothers me. A lot. Take sewing for instance (yes, I do indeed enjoy the fun of sewing, at least as long as it is fun); in the beginning I only did pre-set tutorials. I got to see some achievements, pretty fast as well, and was happy. But the clothings didn't fit that well, more often than not I had to make corrections to be at least a bit satisfied with my work.

By now, I do most of my sewing patterns myself by taking bits from tutorials and knowledge and putting them together, and it works just fine for me. My point is, tutorials are often brief, giving appealing results in a short time, but often lack some of the necessary theory. Ever happened to you that you did something with a tutorial that just would not work? And after going through the complete text again, looking at all pictures, you realize there's a small mistake in it, or something you wouldn't have thought of, which the author took as given?

I guess that's the reason I don't want to write tutorials, the danger of missing something (or to cut off too much or something like that) or to have people sitting in front of it thinking "Screw this guy, this just doesn't work!". Plus, there are plenty of tutorials out there regarding nearly any topic. Or are there?

But - as the headline suspects - I'm gonna break with this habit for now, and give you a few shots and explanations regarding my former post. No tutorial in a classical sense, but one like I try to write my stuff as well: just concepts and ideas, but this time with pictures.

So let's get started. Since I'm keeping my connection open most of the time, I'm using PuTTyTray instead of the regular PuTTy or its portable cousin, so some functions described here are not available in other versions.

Here we got the starting screen. Use "Settings from file" (at the bottom of the screen) to save sessions to a file in the PuTTy-directory instead of the windows-registry. An absolute must for all portable users. The first ellipse is where you type your target server's (or router's, in our case) IP in. If you can't remember your IP at any time or get dynamic IPs, make an dyndns-account to save you trouble. Most Routers come with built-in dyndns-support anyway nowadays, sparing you the effort of an update tool. Of course, we want to have "SSH" as a connection type, but it's per default enabled, so there shouldn't be any problems.

Ah, that one took me awhile to figure out. Or to be more precise: I was swearing and cursing about the problem I encountered and by accident managed to find a solution in the settings for my terminal, which struck me to be very odd. So I wanna share my insights. The option I circled changes the character send to the server by pressing the backspace-key. Since the routers I mentioned all use some sort of linux, you might wanna change the option to the right one, "Control+? (127)". Without that enabled, my fritzbox would only type "[^" or something like that instead of deleting the last character. Very annoying.

That one is one of the PuTTyTray-only functions I mentioned that I don't wanna miss ever again, regardless how more convenient PuTTyPortable sometimes might be for my purposes. Leave the option on "normal" to start it in normal terminal mode. I prefer that one, since I want to use password-authentication. No use minimizing the window to tray on start, only to have to bring it back up, type the password in and minimize it again. "Always" and "Never" produced funny behaviors that I couldn't get a hold of, but, if you wanna guess and like riddles, go and give it a try.

And oh, the "Accept single-click..."-option is nice as well, if you use this kind of restoring in all of your programs. Mixing double-click and single-click is definitely not a good idea, at least not for me.

Oh, yeah. Not that important, I gotta admit. But it would allow you to pick a username that's hard to remember (please don't say anything about the "root" I typed in there.. it is for demonstration purposes only!), and even harder to guess. When using password authentication, I only have to type in my password and not my username. spares me ~1.2 seconds. yay!

Painting Frenzy!! Okay, now here we go. This tab is the mekka for all your needs, the holy grail of port forwarding.
The first option I circled is recommended to use, but it is not without risks (security, mostly). Some protocols may need this option to function properly though. When you look at the entries 1, 2 and 3 they all have a source port (the first column) and a destination (the second one), like my arrows - done extremely skilled, if I may say so - try to show you.

1.) This is a standard port forwarding like used by any program. I specified my source port, which is 5700 (always select "local" as a type if unsure for the others and their doings), and a destination that is usually an IP plus a port. As you can see or at least guess, it's for VNC (port 5900), and it's for a fictional desktop in my home network.

2.) That one I use for the emulation of a vpn. Remember the virtual network adapter I had to create? I gave it the very innovative IP 10.0.0.1, Windows File Sharing services use port 139, so its 10.0.0.1:139 for source. The destination is my main network-hard drive with the very same port. If you specify an IP for the source port, the port is only forwarded if the accordant network adapter is used. In case of the file sharing, I had to do this, since I wanted to work both ways at the same time - local file sharing and file sharing over SSH. If you need only one of both, feel free to just forward the port without a source IP.

3.) This one is pretty much like the first, but it points to a virtual network card I created on my Router. I did so because it is forbidden to map any ports directly to the routers own IP, but mapping to the virtual NIC is allowed. Here, I'm forwarding localhost's port 80 (do NOT do this when running a webserver or any software using port 80) to the virtual NIC's port 80, so I can display my router's status page in my browser here at work, taking a look at phone lists and the like. I also could've made a port forwarding like "6666 192.168.178.253:80", to view my routers page then, I would have to connect to "localhost:6666" in my browser, as well as for connecting my VNC, I have to connect to "<dyndns-address>:5700" instead of just "<dyndns-address>".

Be careful with the Connection -> Proxy-Tab though. You don't have to specify anything here for PuTTy to provide the SOCKS-proxy I mentioned. This is only necessary if PuTTy is forced (or wanted) to use a proxy to connect to the target net (usually, the internet) itself, like when using PuTTy over TOR for instance, which is by the way in my opinion the most comfortable way of using TOR there is.

Oh my, I almost forgot that one.. this is crucial when keeping your connection up and running for a long time. If the connection gets broken there is a chance that your server-component remains active and running on the router, and if your reconnect, you got a second one running, and a third one if that happens again.. you catch my drift. I chose a value of 60 seconds, and it works for me. It was a more or less random choice though, other values might do equally fine.

Okay. I admit, that didn't hurt that much at all. Maybe I will just... keep posting funny daubed pictures about programs I use...

cya all soon! :)

Advertisement