Getting the Most Out of SSH 284
jfruh writes "If you have to administer a *nix computer remotely, you hopefully ditched Telnet for SSH years ago. But you might not know that this tool does a lot more than offer you a secured command line. Here are some tips and tricks that'll help you do everything from detect man-in-the-middle attacks (how are you supposed to know if you should accept a new hosts public key, anyway?) to evading restrictions on Web surfing."
What are your own favorite tricks for using SSH?
InfoWorld at it again (Score:3, Informative)
Re:InfoWorld at it again (Score:5, Interesting)
My favorite trick is
1) have a server on the internet, let someone ssh -R their port 22 there
2) connect to that server too with ssh -L putting their port 22 on the local port 8022
3) Now you have a peer-to-peer ssh (with -Y), and you can run graphical applications remotely.
Re:InfoWorld at it again (Score:5, Informative)
Re:InfoWorld at it again (Score:5, Informative)
Using sshuttle [github.com], the applications don't even need to support SOCKS; it proxies all traffic over SSH.
Re: (Score:3)
Re:InfoWorld at it again (Score:5, Informative)
Host gate1
Hostname 128.141.81.163
User joe
Host local12
Hostname 192.168.1.12
User joe
ProxyCommand ssh -e none gate1 exec netcat -w 5 %h %p
You can now ssh to "local12" just by typing "ssh local12", whether you are on the LAN or not.
Re: (Score:3)
Indeed. And that was the closest thing to an "ultimate hack". Everything else was basic intro to Linux type stuff.
That and the randomart stuff was very poorly explained. Personally I think that feature is pointless anyway. If you are in a position where you feel you might actually get a MiM attack.. copy the key onto a USB stick.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re:InfoWorld at it again (Score:5, Informative)
PermitRootLogin
Specifies whether root can log in using ssh(1). The argument must be "yes", "without-password", "forced-commands-only" or "no". The default is "yes".
Re: (Score:2)
Re: (Score:2)
Ubuntu has a root user.
Re: (Score:3)
Re:InfoWorld at it again (Score:5, Informative)
My mistake, then. I'd heard they'd gone the same route as OS X (incorrectly, it appears). Apologies to all.
Nope, you heard correctly. The bit you're mistaken about is that OS X also has a root user. In both cases, the account is "locked" (no matchable password is set). Set a password for the root user and it works as normal.
Re: (Score:3)
On the sshd_config which ships with FreeBSD has this disabled.
Re: (Score:2)
Not on Debian.
Re:InfoWorld at it again (Score:4, Insightful)
I was 16 once, and I would try to figure out how to do all the cool new trick that my new systems has... As we get older we get in a groove (mostly due to the fact that we are paid to do a particular job, and if we spend too much time finding something new and cool would prevent us from getting things done by are estimated time)
And after 8+ hour of work when we get home the last thing we want to do is more work.
Re:InfoWorld at it again (Score:5, Informative)
Yep I shoulda looked before I clicked...nothing non-obvious here folks, move along.
Here's an actual handy tip: You can make your RSA keyfiles also act as shellscripts for the connection, so you only need to carry 1 file to open the connection from any *nix machine.
To do it, just prefix your keyfile (say it's called ssh_my_server) like this:
#! /bin/sh
ssh user@hostname -i ssh_my_server
exit
----------BEGIN RSA PRIVATE KEY--------
(key goes here, use 4096-bit key for extra l33tness)
Make the file executable and now you can open the connection just by cd'ing to it and running it.
Re: (Score:2)
Wow. Thanks!
And yeah.. that was more useful and more worthy of being called an "ultimate hack" then everything in this lame article combined.
Re:InfoWorld at it again (Score:5, Insightful)
To be fair, I'm sure there are sixteen year olds reading /.
I don't expect every article to be useful to me. Not sure why you would expect that.
I haven't read the article - I think I'm familar enough myself with ssh - but as long as the info is accurate, I'd image it's a useful tutorial for folk getting into Linux.
Re: (Score:3)
Problem is the article is all over the place. It lists basic "intro to linux 101" stuff right next to "security paranoid enterprise server admin" stuff (which is does a very bad job of explaining anyway).
There are plenty of good "intro to SSH" articles and plenty of good "advanced SSH tricks" articles out there. This is just trash.
Re: (Score:2)
I know about a lot of stuff like this too, but when I was 16 the internet didn't really exist the way it is today. I remember using telnet and rsh for everything for example.
Re: (Score:2)
Well good for you. You're a 1337 h4x0rz, I guess. There are still some people in the world who are just getting their feet wet.
Please sit down and shut up. (Score:2, Insightful)
OP should be -1 overrated. You jerks who keep saying things like "everyone is doing X because I am" or "this isn't knew" or "this isn't important" really need to STFU. There are people coming into the world all the time who haven't learned what you learned or had the same experiences that you do. Much of what you learned from is burried now under mountains of information and its very often not clear where people should start from. So sit down, shut up and let others learn, otherwise all you will do is scare
Re:InfoWorld at it again (Score:5, Funny)
What about unlimited encrypted storage?
you need TCP forwarding enabled in your sshd_config, then
ssh -L localhost:2222:localhost:2222 localhost
$ echo "data you wanna save" | nc localhost 2222
# or if you want to backup your hdd, try: /dev/sda1 | nc localhost 2222
$ cat
# the data will be forwarded forever in the loopback link at no cost until you read it back:
$ nc localhost 2222 > hdd-backup.bin
# profit!
Re:InfoWorld at it again (Score:4, Informative)
It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.
Re:InfoWorld at it again (Score:5, Informative)
That's what nohup is for
Re:InfoWorld at it again (Score:5, Informative)
It does matter though. Didn't use screen? Lost a connection? Your processes are terminated. Linux sucks in that regard, you need to know about the hangup "feature" that immediately kills your processes when the terminal dies.
Yes, but this isn't even explained in the article!
Re:InfoWorld at it again (Score:5, Interesting)
In my opinion, I think it might be a better idea to kill the errant job if the controller/user gets disconnected than to continue with a job that may need a followup command that may never come, possibly leaving the server in an unusable state. So you have a choice of trusting the user or having the user say explicitly, "trust me, this is what I want to happen (screen/nohup)... even if I get disconnected."
Re: (Score:3, Informative)
The GP is certainly asking for a default screen session evey time he does SSH, emulating what he gets on Windows.
Oh, well, most people prefer the option of choosing what session to use when they connect, thus things don't get linked the way he wants, but it is easy enough to set ssh to execute "screen -r" when one connects... The GP needs only to RTFM (the first line of it).
Re:InfoWorld at it again (Score:4, Informative)
Even better is the screen/tmux wrapper called byobu (https://launchpad.net/byobu [launchpad.net]). It puts a nice face on screen (and now also tmux) and greatly simplifies basic usage. It also has a large selection of status notifications that can be displayed on the bottom one or two lines of your terminal which show things like the current screens, load, time, etc.
The default key mapping uses the function keys for the most common commands. For example, F2 for a new window, F3/F4 for previous/next window, and so on. It provides a wrapper around the session handling as well, so that, in general, you can almost always just run "byobu" and get your session back or start a new one if there is none existing. And if it finds that you have more than one session running, it will ask you which one to connect to.
In the configuration menu (F9), the last item allows you to toggle auto-launching at login. Select it and it will add a line to the end of your shell's profile file to start byobu when you login.
Development has been proceeding at a very rapid pace over the past year and the feature set it quite nice. Recently, the default backend was switched from screen to tmux, but because byobu is a wrapper on top of those programs, I didn't need to learn a new set of keys... though it did help to read up on tmux to see what it could/couldn't do as compared to screen. For the most part, the change was transparent, though tmux only does one status line at the bottom of the terminal versus the two that you had with screen. One of the nicest changes is that tmux can determine what command you are executing in a window and it shows this in place of a window's generic title in the status line. Screen could do this too, but you had to jump though some hoops, change your shell prompt, and it didn't always work.
Anyway, with the additions byobu brings to screen/tmux, I always have it running which has the added benefit that in the (these days, not very likely) event of SSH dropping my connection, nothing is lost. I usually use it in local terminals too, so if X or my terminal ever crashes for some odd reason, I'm saved there, too.
Hopefully? (Score:5, Insightful)
If you're still using telnet to administer anything that offers SSH, you should probably choose another field to work in.
Re:Hopefully? (Score:5, Interesting)
Re:Hopefully? (Score:5, Insightful)
Telnet has a protocol. Look at socat and netcat. Socat supports ssl, you can check your smtps server port.
Re:Hopefully? (Score:5, Informative)
smtps was deprecated years ago (not that I agree). You should use:
openssl s_client -starttls smtp -connect host:(25|587)
Something socat doesn't appear to support (that's a first).
Re: (Score:2)
Port 110 is trivially tested by hand... port 80 also.
Re:Hopefully? (Score:5, Insightful)
Re:Hopefully? (Score:5, Informative)
Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.
Bullshit. It was designed that way. And I can prove it, unlike your assertion.
http://tools.ietf.org/html/rfc15 [ietf.org]
Re: (Score:3)
Not bullshit. A telnet client works best with a telnet server; while you can use it against other servers, it is not ideal. The client interprets certain byte sequences as commands.
Furthermore, I quote the wiki:
a Telnet client application may also be used to establish an interactive raw TCP session, and it is commonly believed that such session which does not use the IAC (\377 character, or 255 in decimal) is functionally identical. This is not the case, however, because there are other network virtual terminal (NVT) rules, such as the requirement for a bare carriage return character (CR, ASCII 13) to be followed by a NULL (ASCII 0) character, that distinguish the telnet protocol from raw TCP sessions.
The wiki lacks citations; I point you to RFC 854 [ietf.org] (bottom of page 11).
Thus, the protocol is not plain text. It is very close, close enough that most things should work fine, but if you actually desire the ability to deal with raw TCP streams, you'd be much better off using a tool designed for it. Such
Re:Hopefully? (Score:4, Insightful)
When I see someone testing port 25 or 80, it's usually nothing more than a liveness test. Not worth the overhead of writing a program to open a socket and read and write data. perl/python is a tad more accessible, but still for a once in a blue moon use is generally more trouble than it's worth.
Re: (Score:2, Funny)
MasterMan (2603851) - You do know that you can use real programming language like C++ for that, right?
C++ programmers are truly masters of the universe. I salute you sir for taking hours and object oriented wizardry to do what most programmers would do in 5 mins with a short script.
Re:Hopefully? (Score:5, Interesting)
Re:Hopefully? (Score:4, Funny)
And in 2002, when I was contracting for the government, I needed some data that was stored on a government server. They set up a user account for me and rather than email the password to me, called to tell it to me over the phone, because they felt that was more secure than email.
The joke was that I was to connect via telnet. They didn't have ssh on that server. They didn't even have some kind of secure telnet that would at least try to encrypt the password. Just plain old telnet, with the password transmitted in the clear.
Re:Hopefully? (Score:5, Informative)
Emails are cached in a lot of intermediate servers and stuff. The logs are routinely backed up. Undelivered emails get forwarded to all sorts of addresses and admins. Even if nobody was maliciously scooping on you, the passwords could land on some random person's hands.
It *is* more secure over the phone in that sense.
And it's not a common practice to log down telnet traffic. Anyone who gets your telnet password is probably sniffing maliciously.
Not to say it's a sane policy to use telnet, but there are these differences in "levels" of safety (both levels are of course very very low). To a security conscious person it may be equivalent, but practically you have less chance a random John Doe will get your password this way. Maybe it matters, don't ask me....
Re: (Score:2)
Wait wha? I mean, I can see blocking it on outgoing ports in the firewall so that you can't tunnel to the outside world, but blocking it internally? Besides, it's trivial to set SSH to listen on port 23 and viola. New tunneling setup.
Re: (Score:3)
Sounds like a case of throwing out the baby with the bathwater, but in a really secure environment, SSH *is* a huge can of worms, especially when combined with Corkscrew [wikipedia.org].
I once worked for a large company with a draconian firewall policy and no remote access solution. SSH connections were forbidden in both directions. So, I came up with a ssh reverse tunnel solution.
On a box inside the firewall, run this script as a daemon:
#!/bin/bash
while true
do
nohup ssh -O ProxyCommand=/us
Re: (Score:2)
There may be reasons to use telnet over SSH. Challenge the assumption that it's always better to encrypt communications rather then let someone listen in.
That being said, your presumption is normally right; ISP administrators who block SSH and only allow file transfer by FTP fall into the same category. They should be fired.
Re: (Score:3)
My professor for the computer security class at my college demoed this exact scenario - its not a safe protocol.
Re: (Score:2)
Ha, I'm still using rlogin!
Re: (Score:2)
Hardware encryption is still not widely available and Linux support for it where it does exist isn't great (drivers belong in the kernel, especially drivers you need a high level of security for, but there's so much antipathy towards encryption in the kernel that hardware drivers that merely happen to involve encryption have a very hard time of it).
As such, SSH is more CPU-intensive (unnecessarily, since a chip could offload the CPU-intensive part of the workload), which means there will be times when SSH i
Re: (Score:2)
CPU-based encryption is hard, but there's ports like HPN-SSH that works to keep the connection fast while making sure the authentication still happens in a secure manner.
My team maintains a system that has a few hundred people logged in at any time, both for interactive connections to our HPC cluster, but also to send data in and out. All of it goes over SSH and the CPUs are rarely breaking a sweat to keep up - it's usually the storage that is lagging.
Re: (Score:2)
Agreed. Those tend to be thinner on the ground, though, which is incredibly annoying. There's also a lot less awareness of acceleration patches and ports, which I suspect has led to a lower adoption level than would have otherwise been the case. I can't remember the last person I talked to who was aware that such software even existed.
Re: (Score:2)
SSH Tunnel (Score:2)
SSH Tunneling by far: http://www.debian-administration.org/article/38/Tunneling_connections_securely_with_SSH [debian-adm...ration.org]
Re:SSH Tunnel (Score:5, Insightful)
Traffic pattern matching over SSL. A web session over an SSL connection looks very different than an ssh tunnel session over SSL, not to mention the length of life of the socket. It's trivial to have the firewall identify the ssh connection over port 443 and disconnect it in the first few seconds of the session based purely on the pattern of the traffic regardless of content.
Re: (Score:3)
How's that again? (Score:5, Informative)
(how are you supposed to know if you should accept a new hosts public key, anyway?)
Seriously? If you don't know enough about what's going on with the machine at the other end to make that decision... that's the whole bloody point of the warning!
Re: (Score:2)
Just because you use SSH doesn't mean you administer the machine.
I get a cheap ISP, it offers shell access to help me set up my scripts or website. I usually access it through the hostname I've attached with my DNS record: ssh shell.mydomain.com One day, they
Re: (Score:2)
At no point. That is because there is no way for them to tell you the new key (or even that the key changed) whitout the possiblity it was forged. You shouldn't trust an email either.
The wrong thing here is that they are changing the keys. They shouldn't. If they have several servers pretending to be one, they should configure them to share the key and IP address.
Re: (Score:2)
Yes, that is the point of the warning, but now that I've been warned, what's the proper next step?
"OK, so I'm connecting to a server that I don't admin using SSH, and I don't already have the public key stored. So how do I know there's not a MITM attack going on?"
Most wanted feature which SSH lacks? (Score:2)
Imagine that you could just pipe the output from a command into some magical ssh command in a remote machine and your ssh client would ask where you would like to pipe the stream in your local machine.
Re: (Score:2)
this is possible.
first thing to look into:
[enter]~?
the ssh escape-key is ~, but only after a newline. and look out for deadkeys. ~? is a short help on this. There you can manage sub-connections and other stuff.
~. is very useful for terminating a ssh-process, which is still waiting for a network timeout.
And multiplexing a single ssh-connection: read the manpage of ssh for "ControlMaster". then a unix-socket which contains username and hostname in the filename is used to use a single ssh-connection for multip
Wow (Score:5, Interesting)
I am impressed, not!
How about
- ssh master connection, for svn+ssh ?
- ssh agent forwarding
- opening ssh ports using knocking
- auto blacklisting with something like sshblack
I think the above are more advanced options than the ones mentioned in the article, no ?
Re:Wow (Score:4, Insightful)
I'd love to see stuff like that as well as:
OpenSSH signed certificates (Not X.509) and TrustedUserCAKeys options and their usage. This way, I can hand a new cow-orker signed ssh host keys and assuming he or she knows enough not to just blindly replace a key if it isn't right, will minimize the chance of a MITM attack.
Revoking SSH keys.
Using SSHGuard to lock out brute force attempts.
Proper configuration of the sshd_config file. Stuff like only allowing root in via RSA keys (or blocking root access entirely.)
Auditing logs to know that key "A" ssh-ing to root is from user Alice, and key "B" is from Bob, so that one can tell who just wiped out the wrong filesystem come an inquiry.
Running sshd as a user, not as root.
Getting a backup program like NetBackup to form a ssh tunnel, do the backup, then close down the connection cleanly.
Re: (Score:2)
Or the key agent, or ~, or...
Re: (Score:2)
Really lame (Score:5, Informative)
Tip 16 and friends (the keyart stuff) is very poorly explained. You don’t know that the key is secure, but you magically know that the randomart is? That’s the bit they forgot to mention. It’s a visual representation of the key that _you have to have seen before to be able to verify_. Personally if you are going to go to the trouble.. I say throw the key on a USB stick and be done with it.
The screen stuff maybe worth mentioning the more modern alternative tmux.
SSHFS is better than NFS
For quick one-off stuff .. maybe. Cryptographic overhead is still startlingly effective at slowing things down, even on fast hardware (random: can anyone explain why.. you’d think it shouldn’t make any difference at this point.. I’m guessing it has something to do with network framing?).
Tip 4 (logging in with server-specific keys ) seems like the kind of thing that very few people will ever need to do.. and if they do.. they’ll google it. Kinda silly putting it in an article like this.
Tip 2 (ssh tunnel) is probably the only thing in here that _might_ be considered an “ultimate” hack (everything else is pretty much Linux 101).
Tip 1 (Evading silly web restrictions) is great. Alternate title: “my job is important, but damnit I need my facebook/twitter fix”.
Re: (Score:3, Interesting)
Any clued network admin will eventually get wind of a ssh connection going to the same box from someone's workstation, especially if there is a lot of traffic going to and from it. Then, depending on how much they like/dislike the person with the tunnel, they will either ignore it, mention to be careful about PPP over SSH in passing, randomly kill the connection, block the destination IP at the router, block ssh from going outside from that workstation, or just sit there, watch statistics, then present HR
Re:Really lame (Score:5, Informative)
I am the developper of libssh (www.libssh.org).
SSHFS is slow because it's a packet based TCP-encapsulated file transfer protocol. All requests are initiated by the client and somewhat replied to by the server in an asynchronous design, but in practice no sftp server really has an asynchronous implementation. Opening a file, querying its length and downloading 8KiB require at least 3 or 4 RTT.
Compare with NFS, UDP based and mostly kernel-land and fully asynchronous.
Crypto is the main overhead in libssh and I suspect in openssh too, mainly because the crypto libs used do not probe for AES extensions or accelerators by default. And last but not least, OpenSSH's Channel window handling (similar to TCP windows) is not optimal for bulk transfers at high speed.
There are also some remote filesystem features missing in SFTP, like server-send feedback, locks and friends.
Re: (Score:2)
(random: can anyone explain why.. you’d think it shouldn’t make any difference at this point.. I’m guessing it has something to do with network framing?)
What happened is that advances in communication at the kernel has made everything else MUCH faster. System calls like sendfile() basically tell the kernel to dump everything in the file to that port and don't bother me until you're done, which eliminates all of the syscall context switching overhead for read()ing data from the file to a
Re: (Score:2)
My favourite SSH trick is using SSHFS along with AUTOFS to automagically connect to other servers' filesystems. Again, not the best performance, but as long as the server is running an SSH daemon, you're good to go.
SSh tunnel (Score:2, Funny)
Re: (Score:3)
Re: (Score:2)
OpenVPN beats both solutions.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Beyond the shell (Score:2)
1.) File transfers between 2 hosts (via scp or sftp)
2.) Tunnelling (aka the "poor man's VPN"...great for accessing hosts behind a Unix-based firewall securely without having to setup additional DNAT rules)
Remote TCP port forwarding (Score:2)
My favorite is to use SSH remote port forwarding (-R) to allow my machines to connect back home from an unknown (and possibly changing) IP and then allow me to ssh back to them. And key authentication all the way along!
And, by the way, SSH tunneling is not TCP port forwarding!
Should have been titled "ssh basics". (Score:2, Interesting)
Also... screen? When there's tmux???
Re: (Score:3, Insightful)
I'd never used tmux. i've officially learned more from /. comments than the actual articles. Thanks!
Connection Multiplexing (Score:2)
The MITM 'help' is worthless. (Score:3)
Basically they go into some detail about the ascii art representation, and at the end acknowledge that you need to securely get the keys to know what to expect. If you have a secure means of getting the ascii art, you have a secure means of getting the key. The only exception I can think of is if you have someone cell-phone picturing the local console, which could be helpful.
The real useful thing would be for people to do DNSSEC and SSHFP records.
My fav (Score:4, Interesting)
Rather than more complaining, I thought I'd say my favorite option. I like using the ~/.ssh/config file and the use of a master connection. In mine, I have:
host *
controlmaster auth
controlpath ~/.ssh/ssh-%r@%h:%p
controlpersist yes
This creates a master socket on my client. When I first connect, I need to use my passphrase. But when I exit, the SSH tunnel stays up. Futher connections via SSH and sftp and scp use this connection, multiplexed. So no more asking from my passphrase. When I'm finished for the day, I close down the connection with
ssh -O exit host
replacing "host"
Comment removed (Score:5, Informative)
Wikibook on OpenSSH (Score:2)
SSH Feature Wish: Server policy on SSH keys (Score:4, Interesting)
I wish it was possible to require SSH keys for some (or even all) users to have a passphrase, and enforce this requirement on the server.
As it stands right now, even if you generate a key for someone with a pass phrase, they can remove it easily on the client side and the server has no way of knowing. This means you could have passwordless logins to remote systems. Not good.
At least with modern systems and key agents you can get passwordless ease of use once you log into your local account, and if someone happens to get your private key they don't immediately have instant access to the machines you can log into. You should have a little time to secure the machines. [Think lost/stolen laptop or backup drive.]
Re: (Score:2)
I wish it was possible to require SSH keys for some (or even all) users to have a passphrase, and enforce this requirement on the server.
As it stands right now, even if you generate a key for someone with a pass phrase, they can remove it easily on the client side and the server has no way of knowing. This means you could have passwordless logins to remote systems. Not good.
Such a policy would require the server to take the client's word for it that the private key was encrypted with a passphrase.
At least with modern systems and key agents you can get passwordless ease of use once you log into your local account, and if someone happens to get your private key they don't immediately have instant access to the machines you can log into. You should have a little time to secure the machines. [Think lost/stolen laptop or backup drive.]
Agreed. If someone is removing the passphrase from their private key, there is some other problem that needs to be solved. Personally, I like ecryptfs for my home directory and LUKS for my backup drive with the LUKS passphrase inside my login keyring.
Re: (Score:2)
This Article's True Purpose (Score:5, Insightful)
Get real SSH tips from people complaining (rightly or not) that it doesn't contain any actual advice.
I live in the post-SSH world (Score:2)
the 1970s was cool and all
Speedwise (Score:2)
Speedwise, ssh -2 still holds up my Mac 840AV up for several minutes to login :-)
My SSH Utility (Score:2)
Feel free to check out a little perl utility I wrote for creating aliases or shortcuts for remote ssh logins. If you have a lot of hosts to manage it can make your life easier:
http://www.cpan.org/authors/id/L/LD/LDAVIS/remote-ssh-access-1.7 [cpan.org]
Download the file, name it "remote-ssh-access". To read the perl documentation just use "perldoc remote-ssh-access"
Personally I like (Score:4, Interesting)
tar cf - somedir | ssh remote@remotehost 'tar xf -'
A nice way to get things moved around. a similar trick is:
tar cf - somedir | (cd /a/local/path; tar xf - )
Which lets you copy things around a local file system.
Re:I hope the list of tricks (Score:4, Funny)
You misspelled "NoScript".
Re: (Score:3)
I stopped taking NoScript seriously when they thought it was a good idea to deliberately disable AdBlock and obfuscate the code that did so.
Re: (Score:2)
No, not Informative... even the GP said Interesting. ;)
Re: (Score:2)
There might be a story about how to do something INSIGHTFUL in a magazine I borrowed from someone a few months back in some place somewhere.
Karma bonus, here I come...
Re: (Score:2)
Buh-bye.
(No, I wasn't one who modded it, especially after posting this.)