How to Determine the IP Address of who logged into Root

I'm going to take a guess on this one, but I'm pretty confident.

I bet there's a PermitRootLogin yes line already in your file. SSH will only use the first line it finds, and will ignore a duplicate further down. So if you just added PermitRootLogin no to the end of the file without removing the line above, there will be no effect.

It is true that someone who has physical access to your hardware can't be stopped from accessing the system. In most cases, I'd think all you have to do is replace /etc/passwd and now it's cracked. I imagine this is a little trickier if the entire filesystem beyond the kernel is encrypted. I believe that is possible but I have not done it; maybe someone else will chime in.

Gaining root access to the system, however, does not necessarily allow you to decrypt anything and everything.

I'm not a user of keyrings, but if, as you say, your encrypted folder is mounted and decrypted by a login, that is not very secure at all from this perspective, since gaining root access will circumvent that mechanism.

I do encrypt things; unfortunately I do it programmatically, so I don't have any end user software to recommend, but I can outline some concepts (and I'm sure there is end user software for this if you look; hopefully this info will help you understand what it's for and how to use it). Strongly encrypted data requires a key, which is sort of just a really big password -- e.g., if you have generated SSH keys before (exact same idea), they are usually 2048 bits, which would be 292 ASCII characters. That means there are:

2^(2048) = 32317006071311007300714876688669951960444102669715484032130345427524655138867890893197201411522913463688717960921898019494119559150490921095088152386448283120630877367300996091750197750389652106796057638384067568276792218642619756161838094338476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656

possible such keys. Now, if you had a house full of computers and could somehow attempt to brute force something encrypted with a key like that 1000000 times per second, there are 60*60*24*365=31536000 seconds in a year and so the longest it should take to crack the encryption is: 1024765540059329252305773613922816842987192499673880138005147939736322144180234997881697152826069046920621447264139333444131137720398621292969563431838162199411176983996099571656208705935744929819763370065451153230491889226364147519084160779378366643536962387494809266961173766220860787944176572777902409485093681297237073262959315537372037338116951294879703261608251067330385153244179994740939199418574870520229058971285573863444899516498656960438980771601765830518363954994635344042527812713309592956293713298473385906108764499884354345453308129324880686692782919058638686093522275450436077758547560046

years. Of course, there are I believe much better strategies than brute force, but even if you cut that time by a factor of a billion, don't hold your breath.

That's on purpose -- these are hard core encryption algorithms, some of which were commissioned (and I guess are used) by the US military (which is why there is sometimes weird "export regulations" regarding them). They're effectively unbreakable, period. In war your opponent can potentially gain physical access to your hardware, but if your tish is encrypted and they don't have the key, they're stuck.

So one obvious and easy way to secure encrypted data on your laptop in case it gets stolen is to not leave the encryption key on it. Instead, you put it on a USB stick.

But what if someone gets the laptop and the whatever with the key on it (since it does have to be somewhere, you can't memorize it)? You password encrypt the key. You now have a weak link in the chain, though, because a 16 character ascii password only has 2^(7*16) = 5192296858534827628530496329220096 possibilities, meaning the brute force max @ 1000000 attempts/second is a measily 164646653302093722365 years. I think the number of attempts per second has to slow down though, because in order to test the cracked key they have to apply it to the encrypted data.

What I'm trying to say is: if the decryption is tied to a user login, yes anyone who grabs the hardware can easily crack it. I don't know if that is actually what gnome is doing, but probably, since it cannot get your password (those are one way encrypted, see NOTE) and use that (if it could, that would be smarter, because now if someone changed the password, your login would simply fail to decrypt the folder, and that would be that). But there are options, if you have stuff you really need to protect. [lightbulb: It may be that what gnome does is encrypt using the scrambled form (anything will do) when you logout, then decrypts it when you log in. A way to test this might be to log the user completely out, then log in as root and change the user password with passwd username. Or you could just ask the gnome people about this issue.]

NOTE: One way encryption means a method that is not reversible, but always produces the same result. So, you enter your password and it is transformed and the product of that transformation is compared to what is on record (ie, what is on record is not your password!). If they match, good. But if they don't, there is no way to take what's on record in /etc/passwd and turn it back into your password. That's "one way" encrytion. Obviously it is no good for data, because whatever you encrypt that way is irretrievably lost, but it is the standard way of storing passwords (although I think some big companies that should know better, such as Apple, have actually been caught, post hack, as having not done this for some absurd reason, and stored customer passwords in plain text).