Gnome, seahorse, gnome-keyring-daemon - any good howtos or overviews anywhere?
I'm considering (though I'm rapidly going off the idea at the moment) using seahorse and gnome-keyring to manage passwords/keys etc. None of the manuals gives a clue as to what they all actually *do*. All you get is information about the mechanics of entering data into seahorse etc. which is pretty straightforward and obvious anyway. I want to know how it actually works to make keeping keys etc. easier and to make logging in to other systems easier. At present I do things manually by editing and copying the various files in $HOME/.ssh directly myself. I don't run ssh-agent, I *assume* that gnome-keyring is a sort of replacement for that but can't find anything that tells me anything actually useful. What concerns me slightly is that it's all a total waste of time if it's only protected by my login password which I think, by default, it is. I.e. if I understand things right (and I'm not at all sure about this) when I log in to the X gui and enter my password then gnome-keyring (and/or seahorse) extracts my key[s] from somewhere and then when I ssh to other systems that key is used and I don't have to type it in. Have I got that anything like right? If this *is* the way that it works how is it even remotely more secure than simply using password login on those systems I ssh into? If not can someone clarify a bit for me, or, as I said, point me at some sort of overview document that explains things. -- Chris Green
Chris G <cl@isbd.net> asked:
What concerns me slightly is that it's all a total waste of time if it's only protected by my login password which I think, by default, it is. I.e. if I understand things right (and I'm not at all sure about this) when I log in to the X gui and enter my password then gnome-keyring (and/or seahorse) extracts my key[s] from somewhere and then when I ssh to other systems that key is used and I don't have to type it in. Have I got that anything like right?
Pretty much, but with ssh-agent (not sure about the others) you can remove keys or lock keys. Also, ssh keys are usually protected by their own passphrase and not your login password, but again I'm not sure about gnome-keyring or seahorse.
If this *is* the way that it works how is it even remotely more secure than simply using password login on those systems I ssh into?
It's more secure because the authentication password never goes across the network - an attacker would need to break both the transport security *and* the private key that corresponds to the public key. Also, if one workstation is compromised, you can remove that one key and not need to change all passwords. You can also limit the features that can be accessed by a key-based login.
If not can someone clarify a bit for me, or, as I said, point me at some sort of overview document that explains things.
http://www.ibm.com/developerworks/linux/library/l-keyc.html and parts 2 and 3 maybe explains both publickey authentication and the keychain idea better than I can here. Hope that helps, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On Thu, Dec 17, 2009 at 01:20:20AM +0000, MJ Ray wrote:
Chris G <cl@isbd.net> asked:
What concerns me slightly is that it's all a total waste of time if it's only protected by my login password which I think, by default, it is. I.e. if I understand things right (and I'm not at all sure about this) when I log in to the X gui and enter my password then gnome-keyring (and/or seahorse) extracts my key[s] from somewhere and then when I ssh to other systems that key is used and I don't have to type it in. Have I got that anything like right?
Pretty much, but with ssh-agent (not sure about the others) you can remove keys or lock keys. Also, ssh keys are usually protected by their own passphrase and not your login password, but again I'm not sure about gnome-keyring or seahorse.
But then that's only like setting up a system where you need two passwords to get in, obviously more secure but that would be true anyway. I.e. to connect to system xxx from my home system the intruder needs to break into my home system and then needs *either* the passphrase to get at my keys *or* the password of the remote system.
If this *is* the way that it works how is it even remotely more secure than simply using password login on those systems I ssh into?
It's more secure because the authentication password never goes across the network - an attacker would need to break both the transport security *and* the private key that corresponds to the public key.
OK, so it's more secure against being compromised by any sort of man-in-the-middle attack, I can see that. However I don't really believe that my systems are likely to be attacked that way, I'm a thousand times more likely to be targetted by someone simply banging away at an ssh port.
Also, if one workstation is compromised, you can remove that one key and not need to change all passwords. You can also limit the features that can be accessed by a key-based login.
Not really my sort of scenario, there is only one 'workstation', my desktop machine. :-)
If not can someone clarify a bit for me, or, as I said, point me at some sort of overview document that explains things.
http://www.ibm.com/developerworks/linux/library/l-keyc.html and parts 2 and 3 maybe explains both publickey authentication and the keychain idea better than I can here.
Not quite what I was after, I want a *user* guide to tell me how to set it all up and get it working with gnome-keyring, seahorse or whatever. As it is all I can run seahorse and enter passwords and keys but I haven't a clue what it does with them, how I can get it to ask me at start up (or use my login password) or whatever. I've hunted around for HowTos and FAQs but they just repeat similar stuff to what you have pointed me at above. I know enough (I think) about the mechanics of Public Key authentication, I also know how to set up ssh and sshd pretty well for command line use. What I don't know, as I said, is what seahorse et al add to what I already do. I know that gnome-keyring is an ssh-agent replacement (at least I think it is) but I can't find *anything* that tells me how to use it, how it asks me for passphrases etc. or how it integrates with seahorse.
Hope that helps,
Yes, thanks for continuing to humour me! :-) -- Chris Green
On Thu, Dec 17, 2009 at 01:20:20AM +0000, MJ Ray wrote: [snip]
http://www.ibm.com/developerworks/linux/library/l-keyc.html and parts 2 and 3 maybe explains both publickey authentication and the keychain idea better than I can here.
I went and had a good read of all this. It does explain a bit more of the 'user' side of things than I originally thought, however it's quite old of course so doesn't really help much explaining gnu-keyring, seahorse etc. When I'd got to the end it I really felt that the considerable extra complexity of using ssh-agent, ssh-add, keyring and remote authentication is counterproductive. The possibilities for getting something wrong and thus losing the extra security are significant. I also think that 'selling' Public Key authenticated logins as 'passwordless' is misleading. To do it securely you *still* need to remember a key of some sort. In addition with Public Key the key *has* to be kept in a file somewhere and you're relying on the passphrase encryption to protect it. With password login there is nothing written down or in a file, it's simply in your head. Still, enough of this maundering on, thanks for all the help and it *has* given me some ideas and thoughts on how to keep things reasonably secure. -- Chris Green
Chris G wrote: [...]
I also think that 'selling' Public Key authenticated logins as 'passwordless' is misleading. [...]
Not really, because you're only typing the password in to allow the agent to access the key, rather than typing it in every time you access the remote system. Once per sit at the keyboard is much harder to shoulder-surf than once per connection. I think I also struggled to find gnome-keyring documentation but I think the basic mechanics of loading the keys in should be similar to ssh-agent. It's the specifics of what key and passphrase does what that may differ. Regards, -- MJ Ray (slef) Webmaster and LMS developer at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
On Thu, Dec 17, 2009 at 05:39:41PM +0000, MJ Ray wrote:
Chris G wrote: [...]
I also think that 'selling' Public Key authenticated logins as 'passwordless' is misleading. [...]
Not really, because you're only typing the password in to allow the agent to access the key, rather than typing it in every time you access the remote system. Once per sit at the keyboard is much harder to shoulder-surf than once per connection.
... but it's still not passwordless, unless by that is meant less as in not so much! :-)
I think I also struggled to find gnome-keyring documentation but I think the basic mechanics of loading the keys in should be similar to ssh-agent. It's the specifics of what key and passphrase does what that may differ.
It turns out that part of my problem is that is doesn't work! I.e. as delivered it's broken. I'm slowly creeping towards getting it working but now I know that I'm actually trying to debug it things are becoming a little easier. -- Chris Green
On Thu, Dec 17, 2009 at 10:32:08AM +0000, Chris G wrote:
passphrase encryption to protect it. With password login there is nothing written down or in a file, it's simply in your head.
Utter nonsense, of course the password is in a file (ok, not in a form that is simple to read back out again) if it wasn't then you couldn't authenticate using it, i'd think from reading your reply that you are only really considering half the scenario. Adam -- New signature required, suggestions on a post card please.
On Thu, Dec 17, 2009 at 06:48:59PM +0000, Adam Bower wrote:
On Thu, Dec 17, 2009 at 10:32:08AM +0000, Chris G wrote:
passphrase encryption to protect it. With password login there is nothing written down or in a file, it's simply in your head.
Utter nonsense, of course the password is in a file (ok, not in a form that is simple to read back out again) if it wasn't then you couldn't authenticate using it, i'd think from reading your reply that you are only really considering half the scenario.
No it isn't. It's in a file *at the other end* totally inaccessible to the intruder until he's guessed it. The private key on the other had *is* at the end where the intruder is so has to be encrypted. -- Chris Green
On Thu, Dec 17, 2009 at 09:57:08PM +0000, Chris G wrote:
On Thu, Dec 17, 2009 at 10:32:08AM +0000, Chris G wrote:
passphrase encryption to protect it. With password login there is nothing written down or in a file, it's simply in your head.
No it isn't. It's in a file *at the other end* totally inaccessible to the intruder until he's guessed it. The private key on the other had *is* at the end where the intruder is so has to be encrypted.
Can you spot the contradiction? Adam -- New signature required, suggestions on a post card please.
Chris G wrote:
No it isn't. It's in a file *at the other end* totally inaccessible to the intruder until he's guessed it. The private key on the other had *is* at the end where the intruder is so has to be encrypted.
You are taking one (relatively unlikely) attack vector where an intruder gains access to your specific machine in order to get access to another. This is the explicit case where the private key protects you and with the current state of the encryption used a brute force would be pretty much the only viable way of getting the passphrase to open the key, in which time you would hopefully have noticed the local breach and changed it. At which point they may as well have tried a direct brute force attack against sshd itself. Normally the intruder would be coming from a different machine and wouldn't have the private key in the first place. Don't make the mistake of dreaming up one possible attack vector and basing all your security measures upon that assumption. The fact is that if you are only allowing key based authentication then an intruder needs to break into your machine first *and* crack the passphrase on the private key. At the point your local machine is compromised and had you been using a password login to the remote system they could have just installed a keylogger or a login spoof and captured a password for the remote system anyway. So overall if you are using passphrase protected keys you have still increased overall security because the private key has to be stolen and compromised first. Making an attack from a machine other than yours pretty difficult and an attack from your machine as difficult as if they didn't have a password for interactive authentication (they still have to guess or capture the passphrase, which is the same effort as guessing or capturing a login password)
On Thu, Dec 17, 2009 at 10:44:42PM +0000, Wayne Stallwood wrote:
Chris G wrote:
No it isn't. It's in a file *at the other end* totally inaccessible to the intruder until he's guessed it. The private key on the other had *is* at the end where the intruder is so has to be encrypted.
You are taking one (relatively unlikely) attack vector where an intruder gains access to your specific machine in order to get access to another. This is the explicit case where the private key protects you and with the current state of the encryption used a brute force would be pretty much the only viable way of getting the passphrase to open the key, in which time you would hopefully have noticed the local breach and changed it. At which point they may as well have tried a direct brute force attack against sshd itself.
Normally the intruder would be coming from a different machine and wouldn't have the private key in the first place.
Not generally true unless they're doing IP spoofing as well because I only allow access from two specific IP addresses. The important case for me is access from 'out there' in to my machine (well, in to my server machine actually, there's a further hurdle to my desktop machine). The 'out there' machines are not mine, most definitely 'untrusted', the security rules then suggest that you *shouldn't* keep any private keys there.
Don't make the mistake of dreaming up one possible attack vector and basing all your security measures upon that assumption. The fact is that if you are only allowing key based authentication then an intruder needs to break into your machine first *and* crack the passphrase on the private key. At the point your local machine is compromised and had you been using a password login to the remote system they could have just installed a keylogger or a login spoof and captured a password for the remote system anyway.
The key logger can capture my passphrase too can't it? Then the intruder has access to every system where I'm using that key.
So overall if you are using passphrase protected keys you have still increased overall security because the private key has to be stolen and compromised first. Making an attack from a machine other than yours pretty difficult and an attack from your machine as difficult as if they didn't have a password for interactive authentication (they still have to guess or capture the passphrase, which is the same effort as guessing or capturing a login password)
I can see what you're getting at and I half agree but I'm not sure that the game is worth the candle still. -- Chris Green
Chris G wrote:
Normally the intruder would be coming from a different machine and wouldn't have the private key in the first place.
Not generally true unless they're doing IP spoofing as well because I only allow access from two specific IP addresses.
No...no..no..no Connection from specific addresses is not to be considered a primary layer of security, it is a secondary one. Your initial layers (from the something you have/are/know model) should be good enough that you would be happy enough using just one. Quite obviously an ipaddress isn't sufficient for that. So you need to build a secure layer of authentication first and then layer on top things like blocking from all but specific addresses as belt and braces. Put it another way, I am guessing you are on a NAT'ed connection at home yes, so blocking access to an external machine from your external ip address doesn't just restrict access to your machine. Anything on your local network has this capability, as does anyone wanting to try at various points down the line, including your ISP or the ISP that is hosting the other machine. You are making the same fatal assumption people do when they stick a firewall in front on an inherently insecure network and figure that makes them safe. The reality is you are better building a network that considers everything as equally untrusted until it has authenticated itself properly. That way if the firewall is breached or the attack comes from the private side of your network you are still going to give people a hard time....Good networks shouldn't *need* the firewall to be secure. By this stance you can treat blocking from all but specific IP addresses the same way, yes it helps but it is too easily spoofed so don't depend upon it.
The important case for me is access from 'out there' in to my machine (well, in to my server machine actually, there's a further hurdle to my desktop machine). The 'out there' machines are not mine, most definitely 'untrusted', the security rules then suggest that you *shouldn't* keep any private keys there.
No you don't do that, each machine 'out there' has it's own private key and put it's corresponding public key into authorized_hosts on your server. That way you can revoke access to an individual machine by deleting its key. If you are talking about machines "out there" to which you have had no prior access to set up the keys then I would suggest that a. if you care about security you shouldn't be logging into your home system from them anyway and b. there are options to carry your (passphrase protected) private key on a memory stick and symlink it to ~/.ssh on the machine you want to access from. Or (personally I found that option annoying due to uid mapping issues) do what I do. I carry a qemu based VM (running DSL) that is bootable on Windows or Linux boxes from a memory stick which has it's own private key. It's passphrase protected anyway but if I lost the stick all I need to do is get it's public key out of my authorized_hosts. However if we are following best practice here then private keys should never leave a machine, and you shouldn't be establishing a trusted connection from an untrusted host.
Don't make the mistake of dreaming up one possible attack vector and basing all your security measures upon that assumption. The fact is that if you are only allowing key based authentication then an intruder needs to break into your machine first *and* crack the passphrase on the private key. At the point your local machine is compromised and had you been using a password login to the remote system they could have just installed a keylogger or a login spoof and captured a password for the remote system anyway.
The key logger can capture my passphrase too can't it? Then the intruder has access to every system where I'm using that key.
Yes, but this is no worse than what a keylogger would do if it captured your passwords for interactive login. I was merely using this as an example of how key based auth doesn't *lower* security which is what you seem to be suggesting. At the point the passphrase (which can be more complicated if you like because you only need to remember one) is compromised you would have to assume that any and every password you have used on that machine would be equally so..no ?
So overall if you are using passphrase protected keys you have still increased overall security because the private key has to be stolen and compromised first. Making an attack from a machine other than yours pretty difficult and an attack from your machine as difficult as if they didn't have a password for interactive authentication (they still have to guess or capture the passphrase, which is the same effort as guessing or capturing a login password)
I can see what you're getting at and I half agree but I'm not sure that the game is worth the candle still.
Well the beauty is that it isn't really *that* much effort to set up and the benefits are well worth the effort in my opinion. Unless you only have a few passwords to remember or they are very simple/reused often you will generally have a hard time remembering them all. So ultimately you end up recording them all somewhere anyway :)
On Fri, Dec 18, 2009 at 10:59:14AM +0000, Wayne Stallwood wrote:
Chris G wrote:
Normally the intruder would be coming from a different machine and wouldn't have the private key in the first place.
Not generally true unless they're doing IP spoofing as well because I only allow access from two specific IP addresses.
No...no..no..no
Connection from specific addresses is not to be considered a primary layer of security, it is a secondary one.
Yes, I realise that, it's easy enough for someone to spoof the IP addresses I'm allowing. It will prevent most scanning though.
Your initial layers (from the something you have/are/know model) should be good enough that you would be happy enough using just one. Quite obviously an ipaddress isn't sufficient for that. So you need to build a secure layer of authentication first and then layer on top things like blocking from all but specific addresses as belt and braces.
Quite agree.
Put it another way, I am guessing you are on a NAT'ed connection at home yes, so blocking access to an external machine from your external ip address doesn't just restrict access to your machine. Anything on your local network has this capability, as does anyone wanting to try at various points down the line, including your ISP or the ISP that is hosting the other machine.
I'm not quite sure I follow you here. Yes, our little (three or four machines) SoHo network is NAT'ed by a Draytek Vigor 2820n router. It's the router that only allows specific IP addresses to connect. The local network is 'trusted' in that it's just family (OK, they're not perfect but they're not malicious attackers either). Thus I'm not worried about people hacking into my [desktop] machine from other machines on the network behind the router. Yes, other people with a shell login on the machine 'out there' will have the same (permitted) IP address. I'd already said that and agreed that it is something to be considered. However it's not a machine with hundreds of users, shell logins there belong to paid for accounts, they're not freely available. I.e. it's certainly not a trusted machine but it's not at the other extreme either.
You are making the same fatal assumption people do when they stick a firewall in front on an inherently insecure network and figure that makes them safe. The reality is you are better building a network that considers everything as equally untrusted until it has authenticated itself properly. That way if the firewall is breached or the attack comes from the private side of your network you are still going to give people a hard time....Good networks shouldn't *need* the firewall to be secure. By this stance you can treat blocking from all but specific IP addresses the same way, yes it helps but it is too easily spoofed so don't depend upon it.
As I said the private side of the network *is* secure and trusted. Anyone who can get to the private side can physically get at the computers anyway in which case everything we're talking about here is pointless.
The important case for me is access from 'out there' in to my machine (well, in to my server machine actually, there's a further hurdle to my desktop machine). The 'out there' machines are not mine, most definitely 'untrusted', the security rules then suggest that you *shouldn't* keep any private keys there. No you don't do that, each machine 'out there' has it's own private key and put it's corresponding public key into authorized_hosts on your server. That way you can revoke access to an individual machine by deleting its key.
Well other advice I've read doesn't agree with this. It suggests that you use a 'remote keys' set up with ssh where the keys (the private keys for the untrusted client systems) are kept on trusted hosts.
If you are talking about machines "out there" to which you have had no prior access to set up the keys then I would suggest that a. if
No, I do have access to set up ssh keys there. The process when I'm out on the road as it were is:- Connect my 'throw away' EEEPC to WiFi or whatever Use ssh to connect to one of my 'out there' shell logins Then ssh from that shell account to my home system.
you care about security you shouldn't be logging into your home system from them anyway and b. there are options to carry your (passphrase protected) private key on a memory stick and symlink it to ~/.ssh on the machine you want to access from. Or (personally I found that option annoying due to uid mapping issues) do what I do. I carry a qemu based VM (running DSL) that is bootable on Windows or Linux boxes from a memory stick which has it's own private key. It's passphrase protected anyway but if I lost the stick all I need to do is get it's public key out of my authorized_hosts.
However if we are following best practice here then private keys should never leave a machine, and you shouldn't be establishing a trusted connection from an untrusted host.
That last bit is a counsel of perfection isn't it? It would mean one could never connect from the internet into one's home machine.
Don't make the mistake of dreaming up one possible attack vector and basing all your security measures upon that assumption. The fact is that if you are only allowing key based authentication then an intruder needs to break into your machine first *and* crack the passphrase on the private key. At the point your local machine is compromised and had you been using a password login to the remote system they could have just installed a keylogger or a login spoof and captured a password for the remote system anyway.
The key logger can capture my passphrase too can't it? Then the intruder has access to every system where I'm using that key. Yes, but this is no worse than what a keylogger would do if it captured your passwords for interactive login. I was merely using this as an example of how key based auth doesn't *lower* security which is what you seem to be suggesting.
I don't think I was suggesting it was worse, rather that it wasn't much (if at all) better and being more complicated means one is more likely to get things wrong and compromise security that way.
At the point the passphrase (which can be more complicated if you like because you only need to remember one) is compromised you would have to assume that any and every password you have used on that machine would be equally so..no ?
I think your comments about the passphrase apply equally to a password. If there's only one passphrase (you said "which can be more complicated if you like because you only need to remember one") then all the issues are the same as if you only have one password for all your logins, in which case you could have an equally long and secure password which you would only have to remember once.
So overall if you are using passphrase protected keys you have still increased overall security because the private key has to be stolen and compromised first. Making an attack from a machine other than yours pretty difficult and an attack from your machine as difficult as if they didn't have a password for interactive authentication (they still have to guess or capture the passphrase, which is the same effort as guessing or capturing a login password)
I can see what you're getting at and I half agree but I'm not sure that the game is worth the candle still.
Well the beauty is that it isn't really *that* much effort to set up and the benefits are well worth the effort in my opinion. Unless you only have a few passwords to remember or they are very simple/reused often you will generally have a hard time remembering them all. So ultimately you end up recording them all somewhere anyway :)
As I said the "only one passphrase" to secure all those logins is surely *just* as bad as using the same password for all those logins. Anyway, thanks for all the comments and help, I am taking some/all of it on board and tuning (rebalancing maybe) my systems' security as a result. -- Chris Green
On Fri, Dec 18, 2009 at 11:35:02AM +0000, Chris G wrote:
Yes, other people with a shell login on the machine 'out there' will have the same (permitted) IP address. I'd already said that and agreed that it is something to be considered. However it's not a machine with hundreds of users, shell logins there belong to paid for accounts, they're not freely available. I.e. it's certainly not a trusted machine but it's not at the other extreme either.
I was recently asked to take a look at a machine that had suddenly started to not work "correctly". In the process of looking I discovered a root kit and other evidence that the machine had been broken into. Anyhow, I reported this back to the owner to let him decide what he wanted to do. Six or seven hours later I got email from my IDS to let me know that someone was attempting to brute force ssh logins from the remote machine and it had blocked them. They had seen that I had logged in and were trying my username and guessing passwords based on the log files of the remote machine, I wouldn't be surprised if the passwords they were trying were also those that would be used to access the remote machine. Adam -- New signature required, suggestions on a post card please.
participants (4)
-
Adam Bower -
Chris G -
MJ Ray -
Wayne Stallwood