Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Well, as you have explained the situation, you aren't really doing much of anything at that point; so the risk would be minimal.
There is nothing useful to be gained by capturing your association with the AP; and as long as you aren't using clear text SSH passwords or protocol 1, the initial SSH handshaking is completely secure.
However, that is assuming there are no other applications running on the machine which you aren't mentioning. If you had something like an IM client that logged in as soon as an Internet connection came up (and therefore wasn't running though the SSH tunnel) it could be possible that those login credentials could be captured.
Always set up SSH to use digital certificates, and to refuse password-style logins. Use a truly-random passphrase to secure the certificate, rigging the passphrase to a secure keychain. (Macintosh OS/X, for instance, does this automagically in its version of ssh_agent.)
The handshake for SSH does not reveal any information.
If the SSH daemon on the receiving end will accept only a digital certificate as its login credential, and if that certificate is cryptographically secured on your machine ... and if you have a padlock on your laptop even if you leave it "just for a second" ... then there's really nothing for anyone to "snoop."
I don't know if it is correct to say "always set up SSH to use digital certificates". For what he/she is doing, non-keybased authentication is fine (not optimal from a security perspective, but OK). In fact, that isn't even what the OP asked about. It will work fine, even without digital certificates, IMO.
Like MS3FGX stated, ensure every client (such as IM) is disabled first (so that traffic can't be sniffed). Then you'll have nothing to worry about.
Distribution: Ubuntu 8.04.1 desk; Red Hat 9.0 server
MS3FGX, sundialsvcs, and unixfool--
Thank you each for helping me.
At this point, I am using a password, but don't know if it is clear text, and I am not sure how to tell which protocol it is using.
The server man file reports that it defaults to protocol 2, which is what I had expected. The man file also says "The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network."
On the server, ssh -V reports: "OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008"; on the client it reports: "OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009"
The man file on the client reads essentially the same as on the server.