Slashdot Mirror
Keep SSH Sessions Active, Or Reconnect?
borjonx writes "Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open? Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients. At home and at work, I wonder if it would be safer to just leave the connection open (my clients are physically secured, the servers limit connections with hosts.allow). Is it more secure to re-establish the connection over an insecure link (big bad internet) where people can sniff that handshaking, or is it more secure to just remain connected? I connect 1 to 4 times per day, most days."
Just use the program, "screen", if you want to resume your sessions.
Seriously..
The minor advantage over one or the other is moot.. because unless you've got something of actual importance (in which case it shouldn't be on your home computer) no one is going to go through the bother of trying to break in either way.
If someone wants whats on your computer.. they'll probably just grab you and beat you to a pulp until you give them your password.
What gives you the impression that the key-exchange in SSH is vulnerable?
The short answer is: Whatever.
http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
You kind-of answered your own question. Rebuilding the link over and over is of course more open to being seen/sniffed than an estabilished tunnel.
Just modify a telnet server to use one-time pads and you don'te have to worry about handshakes being sniffed. Just carry around 8GB of one-time pad around on a CF card (cause SD has DRM and is therefore evil)
If you're worried that the possibility someone is going to perform an MITM attack on you is greater than infinitesimal, then there are far more important things for you to worry about than whether or not to leave your SSH sessions connected.
I'd be more concerned about security on the end points, particularly on the Windows XP machine. Not hard, but far more pressing than someone finding you interesting enough to insert themselves into your communication.
Unless you -are-, in which case you should manually perform the key exchange and never actually send the passwords in the first place.
I like screen and shwatchr then you can reconnect to your session and if it's from a unauthorized host it gets the boot!
Darwin Enforcement Agent
Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?
Breaking the crypto is almost assuredly not the weakest point in your connection. I'd stay connected, since by far the biggest danger is user errors: you accidentally connecting to the wrong serves, ignoring a cert change alert or something else boneheaded.
Assuming you're not using SSH1, the client and server should periodically regenerate session keys, so it's not like you'll be encrypting vast sessions with just one key (not that this is likely to be the biggest point of failure in your system even without re-keying).
rage, rage against the dying of the light
....if one can be broken, probably the other one too. The chance that the frequency of which you connect matters is <0.001% in my opinion. Either it's secure or it isn't, and either way slashdot won't be able to answer that.
Live today, because you never know what tomorrow brings
Both the persistent connection and the handshake protocol to establish a new connection are completely secure for any practical purpose. If both the server and the client are completely secure, and the connection between them is secure (via strong crypto in ssh) then pick whichever method works best for you.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
If it's an "insecure link" (which is the whole reason SSH was developed ANYWAY), then ANY connection is technically compromised. You can't just assume one that was established "sometime before" is more secure than a new one now. If you carry your assumptions through consistently, they're both compromised and you should just disconnect.
If the servers and clients are physically safe/locked that is. SSH renegotiates the encryption keys by default when nessesary. So even if an adversary tries to break your keys, he would have to sart over pretty soon.
reconnect as needed, but tunnel your ssh over an ssh session which is always active.
Do you even lift?
These aren't the 'roids you're looking for.
All the cool kids are using Reddit nowadays, Digg has dugg its own grave.
Are they using the interwebs to hack the mainframe, or crack the mainframe? You need to consider if they are after your Datasheets or your Hard-Diskette. Theres so many factors to consider. Perhaps they just want to plant a worm that will grow into a virus which will grow into a trojan, if you don't stop it in its Larval stages. You can use cyber worms and cyber Larva in some advanced Phishing techniques, so don't waste them if you come across them. I suppose the only way to be sure 100% secure is to encrypt your entire house on the molecular level. Before you head off to work, you should arrange each everything into 8 mol groups and hash into some kind of cipher, its the only way to be both virtually and physically secure.
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
rage, rage against the dying of the light
I find using the screen to manage my many simultaneous SSH sessions extremely helpful. This tool is so useful it's on the same level as Adblock is to Firefox. With this tool, the reconnect/connect issue is a moot point.
It is good that you are concerned about security. It is bad that you are asking Slashdot for security advice.
If I told you that it is far more secure to leave your connection open all day, would you take my word for it?
Do some research on the subject. Learn what terms like IND-CPA, IND-CCA, and IND-CCA2 mean and how to evaluate this situation for yourself. In terms of security, blindly following someone's advice is the less secure choice.
Ask Slashdot: Where bad ideas meet poor googling skills.
Intuitively, longer sessions can lead to session hijacking. This implies that it's safer to reconnect. I'm sure ssh has some way to prevent session hijacking though.
Even if there were unknown bugs, you still wouldn't be able to decide: staying logged in gives the attacker more encrypted material to analyze from the same session & keys. Re-loging in every 10 minutes gives them more handshake data.
By the way, I hope that hosts.allow is not the only way you're protecting your servers from the "big bad internet"...
If you assume that the remote server is safe, and the communication is safe, then the risk could be at your own box.
Forgetting to set even a screensaver with password in a place where are more people (i.e. kids, or in an office ) or even not people (dont think a cat could hit rm -rf, but is your server, not mine) could make a difference in that question. Could be also an hypotetical risk of some rogue app/trojan (?) sending events to the window that have the ssh session too, but odds are somewhat low.
the only thing that is important is that you verify the public key fingerprint presented by your server to prevent MITM attacks. Aside from that there is absolutely no reason to believe the ssh protocol itself has been broken.
If you're connecting with putty it implies starting of from a risky platform.
Otherwise it wouldn't make a big difference.
With enough resources session keys can probably be replayed either way.
People using html in email should be shot.
Go outside.
I prefer a void in conversation to a vacuous one.
When you cross the two encryption streams you may get total protonic reversal, or you may get 1 REALLY POWERFUL STREAM.
How much is your data worth? Back it up now.
It's safer to log out and re-establish. UNLESS you are subverting host key verification - just clicking past the big warning sign that OpenSSH throws up when it sees an unknown host key - in which case you certainly can get MITM'd. Keep copies of your public (not private!) host keys on a thumb drive for use the first time you connect from an outside box.
I believe the "handshake" is a diffie-hellman key exchange. It can't be sniffed and cracked in realtime. On the other claw, I suppose it's theoretically possible that if you leave the connection open long enough, a determined attacker with titanic resources can brute your session key. In reality, I personally don't think that will ever happen to you, it'd be cheaper for anyone with those kind of resources to use the $5 wrench upside your head method.
Here's something to consider: If your computer is turned off, it's not being hacked. If your computer is turned off, it's not getting a virus. If your computer is turned off, nobody is sniffing your packets. If your computer is turned off, lightning isn't blowing through the ground line of your UPS like a knife through butter and turning your motherboard into a campfire. If your computer is turned off, a jealous colleague is not sneaking into your office and using it without leaving a login record. If your computer is turned off, it's not part of a botnet. If your computer is turned off, it is immune to zero-day exploits that are absolutely unstoppable by any other means.
The most secure computer is turned off. Any time you don't need your computer to be turned on, just turn it off. If everyone did this, we'd save millions of dollars (and hopefully, cut off some funding to energy suppliers who hate us).
You're right, but they do both use Diffie-Hellman for key exchange, so the security implications of setting up the connection are similar.
Yes, you are correct, but you may want to upgrade from ROT-13 to ROT-26.
Make sure everyone's vote counts: Verified Voting
keep alive of course, just in case you get fired
they might change passwords, regenerate keys, restarts sshd, but by default sshd does not drop existing connections ;-)
so, when when you get home, all depressed, you sit down in front of your computer, the screen comes on, and you go "hey, I am still logged in"
then with a smirk on your face, you can still go to work
next few days when they call you that you are hired back, send them your consulting rate (3-4X your regular salary)
dont you read BOFH to know this?
LMGT4U;
http://www.google.nl/search?q=overworrying&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:nl:official&client=firefox-a
"Kill 'em all and let Root sort 'em out"
Reconnect. Leaving the sessions constantly open means if your workstation is compromised, you may have compromised the servers as well.... at least you've increased the risk profile of the servers.
Connect as needed - use proper key management and passwords, etc.
This is exactly the sort of question that Stack Overflow was created for....
Not really, SSL and SSH uses the DH handshake differently. SSL performs all sort of craziness where you select different chipers, sizes and wheter to encrypt at all. SSH does not.
I do IT Security for a university. One of my projects is to do some rudimentary traffic analysis of our SSH sessions.
I look for the negotiation between SSH server and client and log connections. Since the negotiation is port independent, I can log the start of SSH sessions, no matter what port they are on. This allows me to:
1) Notice if important systems have sprung a new SSH backdoor.
2) Notice if important systems are SSH'ing out to weird places.
3) Check with local sys-admins and say things like: 'Looks like the Chinese have found your supersecret SSH port. Again. You have proved that TCP/222 and TCP/2222 are not good choices. Maybe this time you want to borrow my HexDice?'
Anywho, my rudimentary traffic analysis can be defeated if you change the SSH negotiation. It can be hindered if you just leave the connections running for days at a time.
So, if you want to annoy people like me, you may want to leave the connections up.
Miles
The tunnel can be considered safe, regardless of whether you reconnect often, or leave it connected. The attack target worth considering in this case is the tunnel endpoints. Consider that your box is owned and the remote box is not. The remote box can only be tampered with while the tunnel is established, so leaving the ssh session active leaves you more vulnerable. (This is only valid if establishing the tunnel requires three-factor-authentication, such that the attacker can't reestablish the tunnel at will.)
Like many of you, I use OpenSSH to connect to my Slackware Linux boxes remotely
If many of us are connecting to your Slackware boxes, reconnecting is not your largest vulnerability!
(sorry, couldn't resist)
Unless you lock your desktop every single time you get up and walk away from your desk, it's better to generally disconnect, because you lessen the (admittedly very small odds) that someone else will simply walk up to your workstation, and either out of malice, curiosity or just mistake (they think you are logged in someplace it's ok for them to poke around), they end up accessing your remote session.
It may also look suspicious to sysadmins that you keep sessions alive for so long.
Is it possible for a Windows admin to poke around your desktop, remotely, without your knowledge? I believe they normally have to make a request that you accept before you hand over control of your desktop to a Windows admin, but I don't know if Windows (or other corporate monitoring software) allows this to happen without your knowledge.
In a real emergency, we would have all fled in terror, and you would not have been notified.
Here is a better idea, do not open ssh to the world. Make them vpn in first, then ssh. Security in layers.
That's a maddeningly recursive solution...
Can you be Even More Awesome?!
That has no bearing on comparing logout/login vs. staying logged in. Yes, the very very first handshake can be bad (there are methods to mitigate, but that's beyond the scope of this discussion), but once you establish that trust, logging out does not break it.
XML is like violence. If it doesn't solve the problem, use more.
If you log in typing in a password, it might be easier for somebody to get your password by looking over your shoulder, installing a camera in your premises or use a keyboard sniffer. In the case of password authentication, every time you log in is a weak point.
Everything I write is lies, read between the lines.
This initial message is what Monkeysphere is designed to fix.
Monkeysphere distributes GPG-signed SSH host keys. If you have the admin's trusted public key, and they sign their hosts' keys, you can trust the host key even if you haven't connected to it before.
http://web.monkeysphere.info/
Other than looking at the protocol itself, there is one other thing to consider that may raise the stakes more than someone's ability to crack SSH or not. By keeping yourself logged in and using a keep alive option such as TCPKeepAlive, you are further exposing your existence. If someone was listening at a router or something and wanted to find interesting hosts to break into, you're opening a larger window for discovery by leaving your session logged into 24x7. The fact that you're using SSH would tell someone that you have shell accounts in different places, which is most definitely interesting to hackers.
VPNs are somewhat easier for compromised systems to exploit, since the new endpoint shows up as a new interface... they don't have to go through the modest trouble of exploiting the SSH connection by compromising the executable, they can just run their attacks on internal systems directly through the VPN... the surface area for attack is larger.
On the other hand, if they HAVE compromised the SSH executable, having it wrapped in a VPN isn't going to add much (if any) additional safety.
So all in all, unless you're a true bastard and the VPN is terminated in a DMZ that only has the SSH servers visible (and if so, bravo to you), VPN (with or without SSH) is probably a net loss in security.
If there is someone powerful enough to break those systems *and* keep the discovery secret, they're waaay above the league where they'd be interested in your SSH connections. That is, unless you work for the military of a major world power and are known to be transmitting valuable intel.
Or if you work for a hi-tech company with, say, technology that China (for example) wants badly enough to put their version of the NSA to work cracking you and then handing the company's designs to (for example) Huawei.
The company I work for would qualify.
The problem with the tunnel is that it can turn a successful attack on one end into a successful attack on the other. Taking it down when not using it reduces the window of exploitable time. (Which probably still doesn't make a lot of difference for attackers of major-power-intelligence-community level, so never mind. B-) )
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Assuming there is no publically known exploit, the only other risk assessable item is a theoretical unpublished exploit against the protocol. Without any evidence to support the key-exchange being the weak point, it must then be considered that any point in the system could be weak.
If the initial one-off exchanges are exploitable, then you should minimise connections to minimise the number of theoretically exploitable packets.
If the on-going packets are exploitable, then you should minimise total amount of packets set over time, by minimising packets set over time.
Since leaving a session running sends more packets overall ( keep alives, etc ) , it would make sense to terminate your connections unless doing it frequently. the mathemeticians out there can determine the precise number of packets in a session initialisiation, and in the keepalives, and determine the official "point of minimum packet use".
Just remember this: you can't get hacked if you are not connected.
No way in Hell I use WinXP. Fuck That.
For search engine friendliness its best to call it by it's full name, GNU Screen.
i wish i could stop
If somebody manages to crack DHE this guy's home server security will be the least of our problems. The algorithm is pretty straightforward.
Come on people what is this? Tagging such a story where someone asks about some security where some obscure attack may be possible and then tagging it "you aren't that important"?!
This is the same messageboard that wants https for everything, even for this board.
This is the same board that seems to hold privacy above all.
And on top of it, it is full of nerds that tend to love to go into this kind of obscure detail.
And then tag it "you aren't that important" implying "what are you worried about", or with a little further stretch "you have nothing to hide, so don't bother". This is quite ridiculous.
To me I am the most important person in the world, and I would like to live safe and secure. The poster is likely the most important person to himself, and he also wishes to live safe and secure. I wouldn't go as far as poster does, but that's besides the point. He does want to go this far, and has a genuine question that many may consider over the top for personal security but which may have consequences for entities that are under constant attack, where any minute attack vector may mean the difference between safe and 0wned.
"youarentthatimportant" is the worst tag I have ever seen. It's denigrating at best. It's stupid, and shows lack of respect for other people. I may hope this was intended as a joke and a joke alone.
They don't have to crack DHE in general, all they need to crack is diffie-hellman-group1-sha1.
Since a fixed DH group is used, this could be attacked through precomputing many values for the discrete logarithm.
If the key negotiation happens to fall into one of the precomputed values, then that session is in trouble.
If you are really worried about having an insecure link you could try creating a tunnel or VPN between the two machines. These can be long term connections setup indefinitely and have provide their own layer of security. Then just make sure you SSH through the VPN/Tunnel to get back to the server. This will protect your hand shaking between the two systems.
Also be sure to have you private/public keys setup. For ease of use they do not need to have a password (although they can), which is handy for using scp.
However this seems like overkill to me. I am in a similar situation where I SSH home, but because I am a small time home user I find the security provided by SSH and private/public key encryption good enough for me.
In my opinion there is no answer to this question. Both scenarios are subject to an equal amount of risk. The most important thing is securing the workstation itself. If done properly, the risks of staying connected or re-connecting are self-canceling. Do what is most convenient for you, just make sure your workstation is as secure as it can be.
...google.nl/...
But that's in Dutch. He meant a new word in English.
now if only kevin rose were to fall in that grave :(
Davis
that stay connected is more secure that start connection again. Why is that? Well in any case when you initiate a connection then you do several things (DH) and also... stay connected. And well then there are more points were things could fail. If you stay connected too long and for example you are using blowfish and transfer more than 2^64 bytes (2^128 for AES) there is an attack that abuses that. Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff.
that stay connected is more secure than start connection again. Why is that? Well in any case when you initiate a connection then you do several things (DH) and also... stay connected. And well then there are more points were things could fail. If you stay connected too long and for example you are using blowfish and transfer more than 2^64 bytes (2^128 for AES) there is an attack that abuses that. Anyway you are unlikely to transfer that much and the connect/reconnect security should be high enough to not worry about that kind of stuff.
How could anyone really answer your question without knowing the value of the servers you are logged into? If the servers you are connecting to are in a secured bunker and you are leaving the connection open from your house while your not there and the data is something valuable enough for some to break into your house.. Well then no, you should not leave the session logged in. In general it is a bad idea to leave a connection you are not using logged in. If you are locking your workstation (you did not say), than maybe it is still ok.
Keep strict host key checking on and just log out when you are not using the box. If the key changes and your not expecting it, either someone has already broken into your server, your DNS server (on either end), or it is time to talk to the isps on the endpoints and find out which one is out to get you. The "big bad" Internet is the least likely place for you to have a security problem, it is simply too unpredictable.
Nah, the original question says the guy is using puTTY and OpenSSH. They both implement RFC4419.
we already have a great structure for the distribution of OTPs .... trillions and trillions of bits distributed around the world. We call them record stores - by the same CDs, rip them and use the LSBs
I use OpenSSH to connect to my Slackware Linux boxes remotely from Linux and WinXP (putty.exe) clients.
You are fixing a non-problem. You should be fixing the weakest point of attack first, that being the windows machine you are connecting from.
Here is a better idea, do not open ssh to the world. Make them vpn in first, then ssh. Security in layers.
There is little to no additional security in that. The problem isn't getting cracked from the network it's getting cracked on your client machine.
SSH exchanges new session keys ones in a while (every hour?). So you are no more at risk just cause you keep connected.
Program that figures out session keys, need a lot of network packages. The less you send (during the use of one session key) the less they can get.
Private/Public key is not unsecure and the handshake is safe. No one will hijack you connection if you are careful about how you distribute your keys.
*Do not only use Password Login, if you want to be secure*
*Do not have a guessable password on the server you want to connect to*
*If possible turn off SSH password login on server*
It is possible to dictionary hack a password, SSH or not.
Connect fewer times also means that you are less exposed to SSH errors in the login procedure (think: Root user replaces SSHD).
You also expose your KeyStore password lesser times on your own side.
Not that there's anything wrong with putty per se (AFAIK), but the underlying platform is a concern. Sure, putty will send everything over SSH back to your Linux boxes at home, but there is more than a little malware these days that logs your keystrokes, something against which SSH cannot protect you. I would only log into the home machines from your Linux machine at work, and even then only if root belongs to you. It's unlikely your employer would be using keystroke loggers, but they could; it's not illegal if they tell you, and maybe not even if they don't. The usual boilerplate in network access policies could be interpreted to mean everything from log scanning for anomalous activity to recording everything you do.
Next, set up public/private key login and don't allow password login. I do this even within my internal network, and there are no Windows machines on it. At work, where Mac, BSD, and Linux are the majority of the boxes, of course I do it too. Those boxes may be fairly secure and there aren't a lot of Windows boxes on my part of the network, but not trusting any box you don't control is a good idea.
As far as the connection duration, I'd leave them up all the time unless there is some other operational need not to.
"Is it safer to stay in the car, or is it safe to go outside? Like many of you, I use a car to go to work and whatnot. At home and at work, I wonder if it would be safer to just stay in the car then going outside. Is it more secure to lock my car with a key (big bad parking lot) where people can come up and steal my keys, or is it more secure to just remain in the car? I use my car 1 to 4 times per day, most days." On a serious note; when you have used so much time to secure your connection why not used now and then.
Seriously, is this really a question or just wasting everyones time. I *know* you want to get your name on slashdot but at least come up with something constructive to ask.
In other news, I just had a shit, is it safer to wipe or air dry??
"Is it more secure to re-establish the connection or to just remain connected? I connect 1 to 4 times per day, most days."
Since you make new connections on a regulary basis the question does not makes sense: either way, your encryption keys are likely to be known in advance by your opponents (even before you start a new connection). If you have anything worth being protected, start questionning yourself about the very simple steps you are following to transmit your data (and where it made sense for opponents to dig into).
Why use hosts.allow? isn't that a rather old and crufty way of doing it...
How about using iptables rules to allow certain hosts instead, that way someone who isn't authorised to connect won't even see the ssh service port open and won't be able to cause load on your machine by repeatedly trying to connect.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Read the big red book "Applied Cryptography: Protocols, Algorithms, and Source Code in C". http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-Source/dp/0471117099/ref=sr_1_1?ie=UTF8&s=books&qid=1265363727&sr=8-1 Highly recommended to anyone who uses public key encryption or needs to implement VPN's, mail encryption or tunnels.
In essence, no it doesn't make any difference. However, if for example you application would communicate short commands often through public key encryption it would be more economical to use persistent connections instead of making new connections all the time. Key generation is Expensive.
Also, in you situation, just use screen.
How in the hell does retarded 'ask slashdots' make the front page, but not my submission of http://itpomminpurkaja.blogspot.com/2010/02/css-anchor-pseudo-class-concerns.html and http://www.fizzl.net/ for which I actually expended some effort to create.
Bot Assisted Blogging
I run a Gnu Virtual Private Ethernet and change the host keys every 2 weeks. And 90% of my ssh sessions go over the VPN.
For access outside of my vpn I run ssh on non standard port and change that regularly too.
Also you may opt not to use password authentication for ssh.
It does use the OpenSSL library for crypto implementation, which is maybe why the GP is confused, but as you rightly say it does not use the SSL protocol.
You seem to have concentrated entirely on breaking the encryption. However, if we assume that this is hard to do (which your post seems to indicate) doesn't continuously making new connections put you more at risk of a man-in-the-middle attack whereas an already established connection cannot be interfered with in this way without first breaking the encryption?
I've been thinking this same thing (using USB keys for a OTP, and "why don't we do that?") for a couple years now, but 10 minutes after reading your post, the following problems/"considerations" with the USB OTP approach did start to enter my mind:
1) I can see that with a big 2TB pad, you'd also want/need to cycle through pads... the longer you keep the same pad without destroying it, the more data an attacker can get with rubber-hose cryptography if they recover your pad... by coming to your(or his/her) house with a gun and ripping the USB key off your neck. Or seizing it when you/they travel.
2) Also, the other trouble I can forsee with OTPs is that you need one of them for each person you need to communicate with securely. Typically if you are doing something needing this security, you are not doing it with just one other person... you also need to communicate with multiple parties. Once you have 5-10 parties to communicate securely with, the OTP can get a little cumbersome. Carrying around 5-10 USB keys and keeping them straight? And I can't envision it working with 200+ counterparties (a USB-OTP-for-the-web scenario). If you partition your 1TB USB into, say, 10 parts, one for each counterparty, you still have problems. You still need to get 1/10th of that USB key to each of the other parties without giving them the other 9/10ths of the key. (Or your whole gang could use a set of the same 1TB keys and you are trading off convenience versus chances of an informant/leaker, and if you're paranoid enough to be using 1TB OTP, why make that tradeoff?) And don't the counterparties need to communicate so they need their own web of keys?
3) There is the little problem of USB-PC security: wouldn't putting the USB key in a PC expose your whole OTP to the perhaps-infected PC? How does this actually work?
One can see that subversion-resistant secure random number generation, secure transport, and secure key usage, and secure key destruction are all required to make OTPs actually secure.
I predict someone will attempt to market USB one-time pads within 5 years as a sort of snake-oil bandaid, and I can see a distant future where they get used, but I don't see them becoming used widely/securely particularly soon. (Disclaimer: bank tokens that give you 5-digit codes for authenticating transactions do make a lot more sense to me however and might be one targetted use of this technology.)
--LP
P.S. I have not read the security literature on one-time pads. Forgive me if I'm stating the obvious.
P.P.S. I was kind of stunned last week though when getting a mini-SD card for my phone that I can, for $50, get something that is literally the width/length/thickness of my pinkie fingernail that contains 8GB.
LOL .nl is just me.
All the results are in English as you might have noticed, the
I'm actually interested in languages and new words...
"Kill 'em all and let Root sort 'em out"
Is a really long RS232 cable. Stretch it between your home and work.
You're comparing oranges and orangutans.
Damping absorbs vibrations. Dampening is caused by moisture.
When you talk about generating 2TB of pad, I gotta admit, that sounds formidable. But it's a question of quantity/time. Generating numbers is easy; I just don't know how long it would take to come up with 2TB.
Many of us walk around every day, carrying a device that contains a radio antenna and microphone. It probably has a SSD, and maybe has an accelerometer. It passes through yogsothoth-only-knows-what environment, constantly filled with each person's totally unique mundane minutia and perspective. Your best-funded worst enemy has no chance of recreating that. Gathering entropy is easy, it's just a questions of bits per day.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Want a still better idea? Keep ssh open, but forbid passwords.
Voila! No Chinese computers accessing your network, and you still have a secure channel from the outside.
I don't understand why the BSD folks still think the default configuration of ssh is secure enough. Inertia, maybe, or backward compatibility?
Rethinking email
these aren't home servers - these are production servers at work. they're in the data center, so i ssh to them, weather i'm at work or home.
Answer: Safer to logout and re-negotiate SSH when you return.
Reason: SSH authentication negotiation is secure.
Reality: Physical access to your desktop is the primary concern.
Also:
1) setup a personal security policy. Some examples are:
- never know the SSH passwords. Use long random passwords and secure these locally with a strong passphrase (memorized).
- setup a rotation schedule for your SSH keys passphrase
- set your screensaver to "lock desktop" when it starts
- always shut your PC off at end of day (flush raw keys from memory with no exceptions)
- always logout (not just lock screen) when you expect to be away from your PC longer then bathroom/coffee tasks.
- always lock the screen when you step away for those short period breaks (bathroom/coffee)
- setup more then one account for personal vs business. This way you can do less secure things on the personal account which has no access to your SSH keyring.
- determine and follow a new password minimum criteria (like: must be at least X chars, needs alpha & numeric, etc)
- keep backups of keys and passphrases in a very very secure place (consider a lock box)
- never attempt to access these machines via SSH from a Windows box (these are known to be insecure and new malware is known to go undetected for months). There is no guarantee of security no matter what steps you follow.
2) Depending on the physical security of your work environment:
- install Linux onto a fully encrypted Hard Drive (luks works well with Debian and can be setup on install with some distros by default)
- install user home directory encryption (ecryptfs works for me).
- use 'shred' instead of 'rm' when removing old keys/passphrase's etc.
* the reason to do these steps is to provide peace of mind in cases of physical theft.
Reasons to leave SSH connected:
1) it is faster to leave these SSH connections open when you later want to access them. But generally, if speed has higher priority then security for your clients... then why even worry about asking your post? I assume this is not true for you, so just don't do it. It IS worth a little extra time to do things securely.
Parent isn't a troll, it's off-topic, like me.
Idiot mods. See, now I'm flamebait, somewhat informative and just a little redundant. If I were a little cleverer I even might have made troll rank. To summarize, you're really being too kind to the parent.
http://xkcd.com/538/
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Most appreciated. Thank you. :)
Serious? Seriousness is well above my pay grade.
One needs to stage man-in-the-middle attack to hijack existing session, whereas broken handshake can be used to establish new connections. Not looking at crypto-analysis, keeping connections open is much more secure ;-)
I don't know about you, but I have a hard time glossing over a message like "KEY CHANGED--SOMEBODY COULD BE TRYING TO BREAK IN!"
Even if you received an email beforehand coming from your sysadmins indicating that they had installed a new version of SSH and because the key had changed so don't worry about any warnings. If they can manage a man-in-the-middle attack then faking an email will be trivial.
The answer to the question is simple. If you have a session established, it can be attacked. If you don't have a session established, it cannot be attacked.
If your clients use it when they need it and turn it off when they don't, they're minimizing the attack surface. If an attacker can detect an ongoing, always-on ssh session, then he can apply any potential techniques and resources that he or his backers have. If he has to wait for a session to appear and once a session starts, he has a limited amount of time to act, that limits what he can do.
References:
(basic security design, "minimize your footprint")
Tzu, Sun. "The Art of War"
In which case my original statements still hold.
If you maintain a connection when you are not physically present you have downgraded your security to nearly non-existent. Your unattended computer is not secure if it is powered on. It is vulnerable to physical attacks and to zero-day exploits that it would not encounter if it were turned off when not being used.
If you make a fresh connection to a host that you have already got the host keys for - that italicized clause there is what protects you from man-in-the-middle attacks - you are making a Diffie-Hellman key exchange which is not crackable by sniffing and cannot be brute-forced in real-time. A fresh connection is vastly, fundamentally safer than an unattended computer, even if your computer is locked in Superman's Fortress of Solitude.
If you aren't familiar with how DHE works, you should check it out. Very elegant and simple.