Results matching “putty” from CLICK

I've had my $10 Sparcstation 20 sitting on the desk for awhile. I don't have a monitor, mouse or keyboard hooked up, so I've been running it over the serial port, which was surprisingly easy to do, via my Windows box and PuTTY, which provides for connections over SSH on the network or via the serial port. (I've also used Tera Term and Minicom (the latter in Linux), as well as the cu utility in Linux and OpenBSD to facilitate serial connection to this box.)

Thus far I've had trouble loading and running just about everything on this 1995-era Sparc. The easiest system thus far to install has been OpenBSD. It boots and installs from a floppy, with the filesets coming over the network, with little trouble.

The only problem with OpenBSD is that many of the apps I want on the box are not in the Sparc 32 packages repository, which has many fewer prebuilt binary packages than are available for 64-bit Sparc systems. Thus, for things like Web browsers that aren't Dillio (which runs great under OpenBSD on the Sparc 20, by the way), I need to use ports. And every time I try to install one of those apps (so far Seamonkey, Firefox and the Geany text editor) from ports, the build fails.

Maybe that's why these apps aren't in packages: They won't build in Sparc 32.

I tried to install Debian Etch. The floppies I made wouldn't boot on the Sparc, and the CD stalls at loading the esp driver for the CD. I've seen this in bug reports, but if you can't get the installer to work, who knows what else lurks in Debian for Sparc 32?

Now I'm trying NetBSD 4.0.1 on CD. I would've tried the floppies there, but I could barely understand how to make them. (You need two, and I couldn't get the first one to boot on the box.) As far as making a bootable install floppy, OpenBSD is the only OS with which I've been able to do that successfully.

But NetBSD for Sparc 32 had many, many binary packages, and I actually have a good chance of setting up a nice box ... if I can load the OS.

Once I got the CD drive hooked up, my first try with the NetBSD CD ended with read errors when pulling the filesets off the disc.

But since I was able to boot the system from the NetBSD CD and then start the install process (which is extremely clear and straightforward, by the way), I opted to pull the filesets over ftp.

That worked, and now I'm booting into NetBSD 4.0.1, still over the serial port.

The box works. I had trouble with the terminal type, which defaulted to sun. That doesn't play well with the PuTTY on the serial port.

When I installed the system, I chose the Bash shell for root. I probably should've used the ksh, which which I'm becoming more familiar with in OpenBSD, but since I had Bash, this is how I set the terminal type in the console:

# TERM=vt100 ; export TERM

After changing the terminal type at the Bash prompt, I was then able to use vi to get into /etc/ttys and change that terminal type from sun to vt100 without the whole file blowing up — something that has bitten me you know where in my previous OpenBSD install on the Sparc. Morale of story: If you have the choice to set a terminal type and aren't using the attached Sun keyboard and monitor (or another Sun over the serial port), DON'T CHOOSE SUN AS YOUR TERMINAL TYPE. Use VT100, VT220, or whatever it is your terminal software emulates.

Without this change, you might be OK at a prompt, but bad things will happen in vi.

Tomorrow I'll try to control the box over SSH instead of the serial port and see if I can run X over SSH (and maybe ... finally ... get my $5 adapter to hook up a VGA monitor to the Sparc).

Right now, if I didn't need any applications from the ports tree, OpenBSD would run very well on the Sparc 20. But if I can manage to get a "real" Web browser (Firefox or Seamonkey) and my preferred X text editor (Geany) on the box with NetBSD packages, I'll stick with NetBSD and hopefully have a little fun with my 50 MHz Sparc 20.

Photo at top right: Thanks to HolyCowPie! for the "Stack of Sparcs" image. If you're in Omaha, Neb., or near it, HolyCowPie! will fix your hardware for $35 an hour with a two-hour cap, meaning you won't pay more than $70 — a stake in the collective heart of the pricier, Best Buy-owned Geek Squad.

(Here is a screenshot of my Windows XP desktop using PuTTY and Xming to tunnel X over SSH from The Self-Reliant Thin Client running Debian Etch. Click the picture above for a full 1280x1024 image. Clockwise from left, I'm running GNOME's Update Manager, a console with PuTTY and the Rox-filer file manager).

I hadn't used my go-to SSH and X apps in Windows XP to access a Unix-like box in a long while. I actually had to find PuTTY before I could create a shortcut and run it. I already had an Xming shortcut, so I started that and left it in the background until I was ready to begin my X session.

If you use both Windows and Linux/Unix boxes and are not familiar with PuTTY and Xming, you're really missing out. In case it's not totally clear above, PuTTY enables you to run an SSH console session from your networked Unix-like box, and Xming allows you to run X apps over that same connection.

It's all good, clean geeky fun, especially over a local network. One of these days I'm going to experiment with dynamic DNS and figure out how to SSH from a box that isn't in the same building. The stakes there are a bit higher, as the box is out there on the Internet for all to see. But with the proper tools and procedures in place, everything should be secure.

Still, running Linux apps both in the console and in X on a Windows box really never does get old (to me at least).

Related:

Cleaning up the mess left by the OpenSSH vulnerability in Debian and Debian-based distros (including Ubuntu) is easier than I thought.

For those who haven't heard about the problem, I refer you to my recent entry, or invite you to Google it.

I've had my Etch box -- which has both OpenSSH-client and OpenSSH-server installed -- turned off for the past few days. I'm using it as a Web server on the local network, and yes, I've been SSHing into the box for weeks now.

Here's what I did:

1) I run the Update Manager, and I have three packages to update:

openssh-blacklist
openssh-client
openssh-server

2) I click Install Updates to download and install the new packages.

3) After the updates are installed, a window from Debconf opens.

It says, "Configuring openssh-server" on the first line, and "Vulnerable host keys will be regenerated" on the next line. The rest of the text can be read in the picture above.

4) I click the Forward button. I assume that this regenerated my host keys.

5) I don't think this next part is mandatory, but per the suggestion in the window, I open a terminal and run ssh-vulnkey.

The output that comes back in the terminal window tells me that both of my keys -- one a 2048-bit key and the other a 1024-bit key -- are "Not blacklisted."

6) I SSH into the Debian box via PuTTY, which warns me that the SSH key on the server has changed and to proceed if I expected this (which I did). I do, and I'm back to SSHing into my Debian Etch box.

---------------------------------------

So while nobody's happy with the fact that a) Debian had this vulnerability in the first place and b) it took 2 years for somebody to notice, at least the fix was relatively painless in my case.

Final question (which I will be looking into): I have new keys on the server. Do I need to do anything on my non-Debian clients? On my Mac I'm using MacSSH, and that application generated its own keys. I imagine the same is true for PuTTY, but I'm not 100 percent sure.

So who hasn't heard about the bug in OpenSSL in Debian-based distributions that renders any SSH keys created in the past two years extremely weak from a cryptographic standpoint?

The problem is that instead of many millions of potential cryptographically generated keys, due to the error there have been only 32,767. That's easy for a hacker to crack. Not a good thing at all.

According to my feeble understanding of the issue, there was a problem with the random-number generator used for the process of creating the keys needed for secure access to servers. And yes, I do use OpenSSL quite a bit and will be discarding and re-generating my keys very soon now. As soon as I figure out how to do it, that is.

Here is one of the many Debian developer/maintainer blog posts that attempts to explain the whole thing.

And here is the Debian Security announcement with instructions on how to deal with it.

Some are calling this bug the worst thing to ever happen to the Debian project. The worst part is that systems have been vulnerable for the past two years. And this means Ubuntu, too.

There's been plenty of carping and gloating about this on the OpenBSD mailing lists. OpenBSD, in case you don't know, is the project where OpenSSL originated, and there's been plenty of blaming going on. And since OpenBSD is extremely focused on security and cryptography, those who develop and use it are extremely ... interested in the snafu.

What I'd like to see is an easy way for users to know that they need to regenerate their SSH keys -- along with an equally easy way to do it. To that end:

Here's a really good Ubuntu blog post on how to make it right on your machines.

The security announcement from Ubuntu is also very helpful.

And in case it got missed in any of these others (although I can't imagine that it did), here's a post that goes into how to generate new keys for OpenSSH-server.

In my case, I think I only have server keys on my Debian Etch box. I don't recall using OpenSSL as a client on any Debian or Ubuntu installs because I've been using MacSSH on the Powerbook 1400 and PuTTY on the Windows box as clients. And the only servers affected are the aforementioned Debian Etch install.

The only other server on which I have OpenSSL-server is my OpenBSD machine, which is unaffected by all of this. As a point (or two) of information, In OpenBSD you get both the OpenSSL client and server in the base system; in Debian you get the client but must add the server if you want it.

Final note: I'm no expert when it comes to these things, hence the voluminous number of links included in this post. I'll be studying them myself over the next few days or so.

I'm pretty lazy. I turned off the monitor and have pretty much been running a Debian Etch box over SSH on the local network from my Windows box.

I'm using PuTTY to start the session, then Xming to run X apps. Before all this worked, I had to install sshd on the Debian box and then enable X over SSH.

The last time I played around with this, I got over my thing about running a full GNOME desktop over SSH. That just doesn't work. But I can certainly run any X app I want with Xming.

It's pretty sweet. Next thing I want to do is run a terminal over the serial port. I almost had it figured out with my old Powerbook 1400, but not quite. I'll have to try with a Windows box. I just need a DB25-DB9 with the proper genders to get my null modem cable hooked up.

It was my initial frustration with just getting my Powerbook 1400cs to work at all with the "modern" World Wide Web and Internet e-mail that led me to abandon the project (and the resulting This Old Mac blog for the infinitely greener pastures of Linux and BSD on older, cheaper, more-compliant PC (as in IBM-PC, or Windows and MS-DOS compatible) hardware.

But I never forgot about the Powerbook 1400. Sure, I didn't take it out of the bag for over a year, but when I got it in my head that I could use the Powerbook not as a stand-alone Linux box (the only alternative for this vintage of PowerPC-equipped Mac being MkLinux, a distro as dead as can be and not even downloadable) but as a terminal with my many Debian, OpenBSD and various other Linux/Unix setups.

I did get to the point where I had wired and even wireless networking on the Powerbook, and with the most modern browser I could find (the hard-to-get Netscape Communicator 4.8), I could kind of, sort of use the Powerbook with the Macintosh System 7.6.1 for basic Web browsing. Before I go on, everything I know about 7.6.1 I learned from the fine people at System 7 Today, a terrific resource for anybody thinking of running an old Mac on System 7.

That's where I got MacSSH, which, not coincidentally, I managed to configure today to run an SSH session over the local network with my Debian Etch box. First of all, read the documentation for MacSSH. I had to create a "Favorite" for my Debian box, and part of that was creating the SSH keys.

Once I turned off compression and selected MD5 authentication, the connection began working. I typed in the password for my SSH key when the Mac prompted me (I picked a long password, unfortunately). As the MacSSH documentation suggested, I entered my account name for the Debian box, but not the password.

I was prompted for that, and upon entering it, I was in a Debian shell.

Basic commands worked fine, as did the Lynx text-only Web browser. I could even post to LXer.

Things seemed to get a little hinky when using vi and nano to edit configuration files, and I couldn't get the function keys to work (and they're kind of essential for Nano, at least).

And while running X on a computer with a 117-or-so-MHz PPC processor and 48 MB of RAM. But I'd like to try.

See, I get an old Powerbook to actually run a console session with a real, live Linux box, and already I want to get X on a machine that in all likelihood can't handle it.

But I've already got quite a few leads on how to get an X server running, mostly for OS 9, but a few that just might work in System 7.

And while I'm at it, I got into System 7.6.1 and couldn't remember how to open a text editor. I didn't want to use MS Word (which I do have, and which is slow as anything, even though it's the PowerPC build), WriteNow (very quick, but can't make credible text files).

It took me a minute or so to remember SimpleText. I'm not sure whether or not I'm actually generating ASCII text, but it is quick, and yes, simple.

Anyhow, my initial wish, when this project began a few days ago, was to connect to a Linux or BSD box via serial port. I got a cable that connects that weird round printer/modem port on the Powerbook 1400 to a DB9 serial port. I don't know whether or not it's a "null modem" cable, so I also got one of those at Fry's for a couple bucks, with an adapter to get the genders right on the DB9-DB25 connection.

The only problem is that I can't seem to turn the Mac serial port on. I think I do have it. It has something to do with TCP/IP, but if I do turn on the serial port, I think I'll lose the connectivity I have over Ethernet with my PowerPort Platinum card. So since MacSSH is working, I'll stick with it.

I still wouldn't mind getting Zterm to work over the serial port, since I wouldn't even have to open up SSH if I didn't want to (although I would have to enable serial connectivity, which I've done on the Linux end already).

But just getting a 12-year-old, pretty-much-obsolete Macintosh to even run as a terminal with a modern Linux system is a great thing. (Somewhat ironically, but not really, the Powerbook would be less obsolete, I figure, if it had an older Motorola processor; then I'd have a snowball's chance of installing Linux or BSD on it, since many distros still support Motorola 68000 CPUs.)

So I'll play with MacSSH for a few days and bask in the glory of actually finding something useful for the Powerbook 1400 to do. OK ... I could just, you know, use the keyboard connected to the actual Linux box itself, but what's the fun in that?

Before I go: MacSSH seems to die when the Powerbook's screensaver turns on. No big deal, just an observation. The app itself doesn't die, but the session does.

(Note: This entry was written with SimpleText in Mac System 7.6.1. It was then copied and pasted into a file with Nano, running via MacSSH, in Debian Etch. I then started an X session over SSH on my Windows box with PuTTY and Xming, then ran Geany and Iceweasel (aka Firefox) to copy and paste the entry into Movable Type, after which you see it here. Byzantine, yes, but that's part of the whole geek thing. One thing I will say is that the PuTTY/Xming combination is a great way to run X sessions over SSH from Windows boxes. I'd love for the same thing to be true with Mac System 7.6.1, or even OS 8.5 or 9, to which I'm reluctant to upgrade, but I'm not holding out hope, although I will now start looking for MacX 1.1.7, something Apple shipped with A/UX, to further my quest.)

I did a Debian Etch install on one of my test machine drives recently, and today I added the openssh-server package so I could play around with PuTTY and Xming.

Once I installed openssh-server (I used Synaptic, in case you were wondering), using PuTTY to start the connection, I was asked whether or not I expected the encryption key to change (I was, since this is the Debian install, not OpenBSD, which I've been using until now).

One bonus of using this Debian Etch install: The OpenBSD drive is noisy, which probably means it's gonna go. The drive on which I installed Etch is much quieter. I probably need to get some newer, bigger drives ... or a whole new test box, but that's another story for another time.

Quirks in Debian Etch with openssh-server: I can run X apps, no problem. When I run:

$ nautilus &

... I get a huge window with the entire GNOME desktop, minus the toolbars. And I can't close that window -- Xming won't let me, I think. X-ing it out doesn't work. I had to kill the process in my PuTTY terminal. (Note: $ startx & does not work ...)

Speaking of security: OpenBSD is known for its security above all else. Here's how using openssl openssh (which was created by the OpenBSD team) differs -- at my lowly level, anyway -- between OpenBSD and Debian Etch:

In OpenBSD: The sshd server is included in the standard install. But it can't be used until rootly powers are used to implement it. Running X over ssh is not allowed until the appropriate configuration changes are made. But root logins are allowed over ssh by default; the administrator, however, can choose to block root login (which I did).

In Debian: Debian installs without the ssh server installed. So without the administrator specifically installing openssh-server, nobody can ssh into the box. But once that package is installed, Debian automatically allows ssh logins -- and X logins as well. As with OpenBSD in its default state, root logins are permitted over ssh until that feature is turned off in /etc/sshd_config.

I don't understand all the lines in sshd_config, but I probably should get better acquainted with each and every one of them.

Speed? It could be the fact that this Debian Etch box has the GNOME desktop, and I've been running OpenBSD either from the console or the default Fvwm window manager, but everything happens a lot faster with the OpenBSD install (hardware is the same for both). I could modify Debian to boot to a console instead of GDM, and that might speed it up a bit (memory is 256 MB), but whatever the reason, thus far OpenBSD is a bit smoother. (Later, things seemed to run a bit better when I didn't log in on the Debian box and hence didn't have GNOME running).

More on security: If this box wasn't just something for me to play with on the local network, the stakes would be a lot higher. I suppose not having sshd is pretty good security when compared to having sshd installed but not enabled. And I also suppose that installing sshd (openssh-server) means that you want to actually use it. But in the case of both OpenBSD and Debian, I wonder why root logins over SSH are enabled by default. If anything, I'd expect OpenBSD to disallow them until the administrator of the box decides to turn that feature on.

And since you can always use su or sudo (Ubuntu has conditioned me to like sudo, and I always add myself to the sudoers list with visudo, there's really no reason for a root login over ssh.

Side note: Debian doesn't automatically add the primary user to the sudoers list, something I always do because on many occasions I'd rather use sudo than su.

Ubuntu, by default, disables root logins entirely and only offers sudo. It makes setting root's crontab a pain in the ass. I use sudo -i crontab -e to get into root's crontab in Ubuntu.

Side note to a side note: While I can fake my way around vi, I like it when nano is the default editor and crontab -e brings up nano instead of vi. The one thing I don't like about nano is that when you wrap text, actually linefeeds are inserted. At least in vi you can have the text break in the middle of a word without turning word wrap on (although you are able to do so if you want wrapped text). The one thing I like in X editors is the ability for text to look wrapped without actually being wrapped.

Quick notes because I've got time for no more:

Debian Lenny: I hadn't updated Debian Lenny in about a week. Bugs are getting fixed all over the place. The latest wave of upgrades includes a couple of fixes for the Epiphany browser, which as a result is running better than ever. Most of what I noticed was cosmetic, but it just adds to the excellent functionality that Lenny already offers users. If you've been worried about running Lenny instead of Etch, I think the time is right to move to Lenny as it makes its way from Testing to Stable.

Preload in Debian: After reading about preload in Linux Journal, I finally installed it. Preload is supposed to monitor what apps you use most and automatically load them into memory, adjusting if your application habits change. Since I tend to run the same apps a lot, and since I have plenty of memory, I'm anxious to see how well preload works.

FreeBSD and the need for speed: FreeBSD 7 is now beginning its life as a stable OS. It's supposed to be up 15 percent faster than the fastest Linux kernels, up to 350 percent faster than FreeBSD 6x under normal loads, and up to 1,500 percent faster under heavy loads. I'm anxious to see how the hardware recognition performs. So far, I've had quite a bit of luck with DesktopBSD 1.6, which is based on FreeBSD 6, and I can only hope for better things with FreeBSD 7, which I plan to test soon.

OpenBSD update: I've been having a lot of fun -- and learning quite a bit -- with OpenBSD. I have the box on the local network, and I've been playing around with the ftp server, Apache Web server and with SSH. First I installed the PuTTY ssh client on my Windows XP box so I could connect from the XP box to the OpenBSD box. I could run any console program I wanted, and while it may not be a huge deal to the more experienced of you out there, it's a huge deal for me.

I wanted to run X over SSH, so I made the appropriate changes in OpenBSD to allow X11 forwarding over SSH. Ahd with the help of my friends over at LXer, I found out about Xming, an X client for Windows.

It took me awhile to figure out that I had to enable X in PuTTY to make it work. Xming runs in the background on the Windows box, and when I open an X program from the PuTTY console:

$ rox &

... A window opens on my XP desktop with the OpenBSD X program in it (which, in the case of the line above, is the Rox-filer). Pretty slick. (The & after the app name makes the process run in the background. I had one snag: I couldn't run the Dillo browser over SSH until I installed all the X fonts for Xming. There's a way to just use Xming to enable the SSH session, but that hasn't worked for me thus far. But since the PuTTY/Xming combination is working, that's what I'm going with.

I'd like to run a full X session with a full window manager running in a window on my XP box, but besides being slower than running single apps, I get the feeling that such a thing isn't exactly looked upon lovingly by the hard-core Unix geeks out there.

But being able to run any OpenBSD (or Linux) app on a network-connected box from a Windows-only PC is so totally cool that I should be sated in my dose of geekdom for the next week at least.

The $0 Laptop and its CPU fan discontents: I've been working with controlling my Gateway Solo 1450's CPU fan for months now. In Linux, I've had it controlled pretty well with a cron job, and in the case of Puppy a few added kernel modules.

But since then, I've come to realize that the cron job, which checked the CPU temperature every five minutes and turned the fan on or off depending on that temperature, is unnecessary.

All you need to do is turn the fan off at boot, and then ACPI will manage it just fine. This revelation comes after considerable work in the console, checking the temperature, running commands, running scripts and generally seeing what happens during the course of a computing session.

So I turned off my cron jobs, and now all I need to do is add the following line to /etc/rc.local:

echo 3 > /proc/acpi/fan/FAN0/state

That turns the fan off. I initially thought that only this line -- echo 0 > /proc/acpi/fan/FAN0/state -- would turn the CPU fan back on, but that is most definitely not the case. Once the fan is turned off with the "echo 3" command (which you can run from the console, just as you can the "echo 0" line), when the CPU gets warm, the fan turns on and then turns off when the CPU cools down.

So that one line added to /etc/rc.local is enough to get ACPI management of the fan working, at least in the Gateway Solo 1450.

Now there's the matter of OpenBSD, FreeBSD and NetBSD and this same CPU fan. So far nothing has worked, but I will keep trying.