RE: Suggestion to make remote recovery easier
De: [EMAIL PROTECTED] en nombre de Justin M. Wray Enviado el: jue 08/05/2008 5:41 Para: Andrew Sayers; [EMAIL PROTECTED]; ubuntu-devel-discuss@lists.ubuntu.com Asunto: Re: Suggestion to make remote recovery easier As for a name, I personally donot like remote help, nor remote recover. And Remote Assistance is taken :( We need some good name ideas... Remote Power ? Regards. Pedro. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Le mercredi 07 mai 2008 à 03:44 +, Justin M. Wray a écrit : Another idea would be to not only tunnel SSH but also VNC. Allowing the newbie to watch the helper do something at times might be the goal, and will make help facilitate learning. In addition the issue might be with a GTK/GUI app, and VNC would be the fastest approch. If you limit your goal in this spec to general help (as opposed to recovery from an unusable system), then you can do it in a nice and easy way with Telepathy. The newbie only has to select his technical friend while they chat on Empathy, and say Give this contact control on my desktop. Then if a console is needed the geek will start it by itself (gnome-terminal). The drawback here is that in case X does not start anymore, this would not work. But for the most common case of a new Linux user asking how can I do that, this is perfect since you can see what the friend is doing, and possibily learn. And this is nicer because you don't give total control on the computer to a friend who may install what he wants (even if you trust him, this possibility may refrain you from remote help). A word about openssh-server: Please don't disable password connexions by default, it is your script that will have to do so. The defaults now are sane and quick to use. Many people are behind firewalls and can install a SSH server without fear of terrible attacks on their LANs. Only when the user is known to be a newbie not controlling the SSH server we should secure it the most. Very nice idea anyway! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
(starting a new sub-thread for a new proposal) I'm currently swinging back towards remote recovery and remote help being distinct problems that need different solutions. There are three reasons for that: 1) As I mentioned in a previous post, remote recovery needs to be done in an extremely defencive way. Some of the things that could get users into a mess include: * Failure to mount /home * Deleting /root and/or the root account * A half-installed upgrade that leaves sshd_config messed up * /, /tmp/, /var etc. mounted read-only None of these are problems that you need to worry about in the remote help case. 2) While I definitely agree with people that say remote help should be an over the virtual shoulder exercise so that the user can learn some things, remote recovery is generally necessary when they've got themselves into a situation where they don't understand the problem, and wouldn't understand the solution. 3) From the point of view of remote recovery, the problem with public keys is that they're very long and difficult to type. In a remote help situation, you post someone a floppy disk with your public key on, whereas with recovery, you'd have to spell it out over the phone. My public RSA key is 200 characters, while my DSA key is 580. Speaking 1 character per second, it would take more than 3 minutes to type out an RSA key. Passwords strike me as the only practical solution for remote recovery, but I've asked the SSH team whether they would disable password authentication in the default configuration. Their opinion is the one that matters, so I'll work around them in this specific case if necessary. I'd say it's best to wait for the SSH team to reply before making decisions about remote help. The question was posted here: https://answers.launchpad.net/ubuntu/+source/openssh/+question/32326 Given all of the above, here's a rough sketch for my new remote recovery proposal: The expert tells the friend a newly-generated one-time random password that the friend can use to SSH into a chrooted jail. The jail contains two pipes: shell_in and shell_out. A superuser shell is started on the recovery machine, and all input/output to it is routed over the SSH connection and through the pipes on the expert's machine. The expert can then access a root shell on the recovery machine by doing the following on the expert's machine: cat ~remote-recovery/shell_out cat ~remote-recovery/shell_in This reverse login is definitely not great for the recovery machine's security, so it should only be used in emergencies. However, it seems to me that it should be extremely robust in the face of breakage on the recovery machine. Going back to a point I made earlier, this isn't an everything-proof solution. For example, it's no use if the expert's ISP is running a NAT that the expert can't control (as my ISP seems to be threatening to do). However, that sort of thing strikes me as a problem best left for version 2, when we start to see what the actual problems are in the real world. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Andrew, In general a one time emergency, and remote help will be two different situations. But I see no reason the split the ability into two different projects/solutions, and the end-result is the same: a remote user gains access (securely) to your system, in order to fix a problem. I also see the functions/process that we are working out in the so-called remote recovery soultion being reused for a remote help solution, and feel that forcing another reinvention of the wheel, or a serperate package with the same end result pointless. I feel it would be far more simple to add a GUI control (VNC) option to the exisiting setup, allowing the helpless user or expert pick the correct course of action. I would obviosuly not waist my time using VNC to open a shell and make changes to complex system options if the user would gain no advantage by me doing so. But at the same time, it would pain me as well as the user to have two different remote assistance options, in which I would need to explain the diffrence. Maybe I am being a bit extreme about the extra step involved in selecting the correct soultion (if they are split), but at the same time having them combined would truly make everything easier. Package managment, bugs, etc, would all be linked anyway. I agree that the use of SSH keys in a one-time situation would be far more complex, although I think email/web would be a far better way to transfer the key then mailing them, even in a long term situation. Nonetheless the password solution should be fine, with the proper security precautions. The addition of the chroot jail will surly allow the majority of the helpers to feel safe. It should add that extra layer of security needed in the password situation. Altough it may be wise to disable further logins, and/or change the password after the connection has been made. I think adding a small (obvisouly simply) script for: cat ~remote-recovery/shell_out cat ~remote-recovery/shell_in Would be a wise option to streamline the process, but having the ability to split input and output will make this a truly robust solution. Another note on the security front, and the user learning front. I think it would be wise to echo the input and output to the recovery system/helpless user. This would allow them to follow along with the recovery process, and if need be interact directly. Just like VNC, they would be able to watch and possible learn, and chime in with enviroment related questions when need be. But let's for a moment assume they have no idea what the problem is, and will surly not understand the solution. The ability to watch the process does add an extra layer of security. The helpless user can monitor what the helper accesses etc. It should at the very least give them ease of mind. It is far from fool proof, but should be an extra valuable layer, and the educational benifit is huge. And in the case of no X, this still allows the learning process to take place. And this yet again shows value in a combined solution. I think sound command-line options (like: --cli, --gui, --both [default]) would be the best approch. And with good support from the board/community, we could easily get such a solution setup with an easy to use, easy to find frontend. Shipped by default, as long as the solution is robust enough to cover a number of use cases. The one-time issue, and simple teaching/assistance are not so different in nature. Thoughts? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 14:06:53 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier (starting a new sub-thread for a new proposal) I'm currently swinging back towards remote recovery and remote help being distinct problems that need different solutions. There are three reasons for that: 1) As I mentioned in a previous post, remote recovery needs to be done in an extremely defencive way. Some of the things that could get users into a mess include: * Failure to mount /home * Deleting /root and/or the root account * A half-installed upgrade that leaves sshd_config messed up * /, /tmp/, /var etc. mounted read-only None of these are problems that you need to worry about in the remote help case. 2) While I definitely agree with people that say remote help should be an over the virtual shoulder exercise so that the user can learn some things, remote recovery is generally necessary when they've got themselves into a situation where they don't understand the problem, and wouldn't understand the solution. 3) From the point of view of remote recovery, the problem with public keys is that they're very long and difficult to type. In a remote help situation, you post someone a floppy disk with your public key on, whereas with recovery, you'd have to spell it out over
Re: Suggestion to make remote recovery easier
Justin, I agree that a single solution would be best, but I can't see how to make it work in the case of a system that's mostly broken. However, it looks like it's going to be an evidentiary question - either we can make it work or we can't. How would you feel about the following working arrangement: I'll rewrite my remote recovery blueprint based on ideas discussed here, focussing solely on the worst case; you write up a remote help blueprint focussing on the common case. Then we'll liberally criticque/merge/steal ideas and see where that goes. If we wind up with a single blueprint, great! If not, we'll have a good solution for the general case and an ugly solution that's just usable enough to bootstrap into the general case. In the spirit of working towards the middle then... I agree that VNC would be better in the common case. In fact, using VNC leaves the door open to someday expanding the solution to Windows-using friends, although that's definitely a version 2 idea. If we agree that passwords are best in the case of an emergency phone call from someone with no prior relationship, I think we should use keys everywhere else, but leave key exchange up to users. I agree that web/e-mail is better for people who aren't that paranoid, but those that are more paranoid will want the freedom to use whatever mechanism they trust. Showing the SSH session to the user in the recovery case is a very good idea, and should be fairly simple to implement. Some sort of chat session is also a good idea, so long as we can implement it so that two people aren't trying to type on the same command line at the same time. That should just involve putting chat and commands in two separate ttys. Another use case we need to think about is broken video cards/monitors/etc. that make it impossible for the non-technical friend to use their computer at all. This suggests that the expert should be able to log in by default, rather than having access only granted on request. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
On the other hand, I'm wrong about that :) I've just discovered a package called socat, which is an extremely general command line tool for creating connections between things - more so even than netcat. It's in Universe, so it's presumably not that much of an ask to have it upgraded to main. I think we can create a general solution using socat. In the catastrpohic case, this would work if only socat and a shell script were still working (instead of ssh and a shell script). Let's formulate the problem this way: We need to create a bidirectional, secure method of communication between two computers. Some of the ways to set this up include: 1) Helpee connects to helper 2) Helper connects to helpee 3) Helpee and helper both connect to some shared proxy server Each of these can be done over IPv4 or IPv6, over the public Internet or a private connection (such as a modem). Once the connection is made, we need to start up an arbitrary interface using that channel. Possible interfaces include: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys We can implement this using a collection of interface modules that request a particular type of connection from socat, and a collection of socat modules that deliver that connection over whichever protocol has been configured. Users can then add extra socat modules to handle their own esoteric situations. Does this seem workable? - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Having looked quickly at cryptcat, it seems like some interfaces would be best served by cryptcat+socat, so that you can get security and a pseudo-terminal. To generalise your idea even further, how about a bidding system? For example, say the expert asks for a forward remote shell on the friend's computer: First, the program asks for a shell connection to the specified IP address: * SSH doesn't have that IP address in its known_hosts file, so it bids 90 * bash can create a login, but has to sub-contract creation of the PTY. It bids 99, on condition that someone else handle the PTY * telnet can't do security, so bids -1 (i.e. get confirmation before continuing) Since a bid exists that has conditions, we do a second round of bidding. In the second round, the program asks for a PTY on the specified address: * socat bids twice: - 99, on condition that someone else handle the connection - 49 if it has to handle the connection itself Since there's still a bid with conditions, the third round asks for a connection to the server: * SSH still doesn't know the hostname, and isn't designed for that particular purpose, so bids 80 * cryptcat doesn't know that host name, so bids 90 * netcat can't do security, so bids -1 SSH's bid is ignored, because there's already a higher bid with SSH in it Since no more bids have conditions, the various options are ranked first according to the lowest bid in the chain, then according to the number of links in the chain: 1) SSH (90/1) 2) bash-socat-cryptcat (90/3) 3) bash-socat (49/2) 4) telnet (-1/1) 5) bash-socat-netcat (-1/3) Each of these is then tried in order. If the program gets all the way down to (4) without success, it asks the expert whether he wants to try insecure connection methods (there might be nothing wrong with telnet - for example, if the computers are already connected over a modem). - Andrew Justin M. Wray wrote: Yes, this seems to be the robust sort of approch that seems to cover the most use cases and works at a very low level. Thoughts on crytpecat verses socat? It has the benifit of being more secure. I think the solution should work as such: 1). Try SSH, if fail then, 2). Try cryptcat, if fail then, 3). Try socat There will be times when cryptcat will be broken (lib issues etc), so having socat as the last resort seems safe. But for the sakof passwords and data I do not think it should be the first option. In addition SSH is far more robost with added complexity, if it is avaliable, I think it should be used. Thoughts? The ability to have: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys Adding only: 7) Custom command This is the exact sort of options I think should be avaliable in such a solution. Allowing the helpless user pick when running the recovery command. The best connection solution is a reverse connection to the helpless user, this bypasses the NAT/Firewall issues. Ssh allows tunnleing, so when possible we should use this (see above). Else we may want to look into `rrs` (remote reverse shell). Thanks, Justin M. Wray Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 18:57:41 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Having looked quickly at cryptcat, it seems like some interfaces would be best served by cryptcat+socat, so that you can get security and a pseudo-terminal. To generalise your idea even further, how about a bidding system? For example, say the expert asks for a forward remote shell on the friend's computer: First, the program asks for a shell connection to the specified IP address: * SSH doesn't have that IP address in its known_hosts file, so it bids 90 * bash can create a login, but has to sub-contract creation of the PTY. It bids 99, on condition that someone else handle the PTY * telnet can't do security, so bids -1 (i.e. get confirmation before continuing) Since a bid exists that has conditions, we do a second round of bidding. In the second round, the program asks for a PTY on the specified address: * socat bids twice: - 99, on condition that someone else handle the connection - 49 if it has to handle the connection itself Since there's still a bid with conditions, the third round asks for a connection to the server: * SSH still doesn't know the hostname, and isn't designed for that particular purpose, so bids 80 * cryptcat doesn't know that host name, so bids 90 * netcat can't do security, so bids -1 SSH's bid is ignored, because there's already a higher bid with SSH in it Since no more bids have conditions, the various options are ranked first according to the lowest bid in the chain, then according to the number of links in the chain: 1) SSH (90/1) 2) bash-socat-cryptcat (90/3) 3) bash-socat (49/2) 4) telnet (-1/1) 5) bash-socat-netcat (-1/3) Each of these is then tried in order. If the program gets all the way down to (4) without success, it asks the expert whether he wants to try insecure connection methods (there might be nothing wrong with telnet - for example, if the computers are already connected over a modem). - Andrew Justin M. Wray wrote: Yes, this seems to be the robust sort of approch that seems to cover the most use cases and works at a very low level. Thoughts on crytpecat verses socat? It has the benifit of being more secure. I think the solution should work as such: 1). Try SSH, if fail then, 2). Try cryptcat, if fail then, 3). Try socat There will be times when cryptcat will be broken (lib issues etc), so having socat as the last resort seems safe. But for the sakof passwords and data I do not think it should be the first option. In addition SSH is far more robost with added complexity, if it is avaliable, I think it should be used. Thoughts? The ability to have: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6
Re: Suggestion to make remote recovery easier
We're certainly getting there! I haven't yet given up hope of doing this with a shell script (evidentiary question again). The benefit of a shell script is that it leaves open the possibility of packaging a lite version of the program as a single architecture-neutral file, so that we can support users of other unixoid systems that can download a script. The reason I went for numbered rankings was that it makes it easy to compare two modules that don't know anything about each other. If every module needs a greater than/less than function that knows about every other module, that makes O(n^2) work for us every time we want to add a new module. Or more precisely, O(n^2) work for some poor expert we'll never meet that happens to need a particular module for his special case. On the other hand, if you have a non-numeric solution with linear complexity, I always like being proved wrong about these things :) The choice of interface module needs to be made before the choice of lower-level module, because not all interfaces have the same requirements. For example, VNC needs a TCP socket, which has to be passed in the parameters to SSH. Finally, I agree that a GUI would be a good default choice here, although it needs to be written in such a way that the ncurses/plaintext fallback looks quite natural to the user when everything goes wrong. However, I don't really do GUI programming, so it's not something I would be able to do myself. I'm now going to download dash and see whether I can fight my way out of that little box. If not, C it is. - Andrew Justin M. Wray wrote: I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
I see no reason why we can't (even with C) come up with a universal package, that other distros can use. (Most programs are C, the diffrence is normally packaging). But if we can complete this is shell code, there is the benifit of an expert being able to quickly change the code, without needing to recompile, etc. Let me know how the dash adventure turns out. We can then go from there. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 20:07:13 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier We're certainly getting there! I haven't yet given up hope of doing this with a shell script (evidentiary question again). The benefit of a shell script is that it leaves open the possibility of packaging a lite version of the program as a single architecture-neutral file, so that we can support users of other unixoid systems that can download a script. The reason I went for numbered rankings was that it makes it easy to compare two modules that don't know anything about each other. If every module needs a greater than/less than function that knows about every other module, that makes O(n^2) work for us every time we want to add a new module. Or more precisely, O(n^2) work for some poor expert we'll never meet that happens to need a particular module for his special case. On the other hand, if you have a non-numeric solution with linear complexity, I always like being proved wrong about these things :) The choice of interface module needs to be made before the choice of lower-level module, because not all interfaces have the same requirements. For example, VNC needs a TCP socket, which has to be passed in the parameters to SSH. Finally, I agree that a GUI would be a good default choice here, although it needs to be written in such a way that the ncurses/plaintext fallback looks quite natural to the user when everything goes wrong. However, I don't really do GUI programming, so it's not something I would be able to do myself. I'm now going to download dash and see whether I can fight my way out of that little box. If not, C it is. - Andrew Justin M. Wray wrote: I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Also, I know a handful of community members chimmed in originaly, but the feedback has subsided. Does anyone else in the community have any comments on our current outlined process? Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Justin M. Wray [EMAIL PROTECTED] Date: Wed, 7 May 2008 19:28:34 To:Andrew Sayers [EMAIL PROTECTED],[EMAIL PROTECTED],ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier I see no reason why we can't (even with C) come up with a universal package, that other distros can use. (Most programs are C, the diffrence is normally packaging). But if we can complete this is shell code, there is the benifit of an expert being able to quickly change the code, without needing to recompile, etc. Let me know how the dash adventure turns out. We can then go from there. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Wed, 07 May 2008 20:07:13 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier We're certainly getting there! I haven't yet given up hope of doing this with a shell script (evidentiary question again). The benefit of a shell script is that it leaves open the possibility of packaging a lite version of the program as a single architecture-neutral file, so that we can support users of other unixoid systems that can download a script. The reason I went for numbered rankings was that it makes it easy to compare two modules that don't know anything about each other. If every module needs a greater than/less than function that knows about every other module, that makes O(n^2) work for us every time we want to add a new module. Or more precisely, O(n^2) work for some poor expert we'll never meet that happens to need a particular module for his special case. On the other hand, if you have a non-numeric solution with linear complexity, I always like being proved wrong about these things :) The choice of interface module needs to be made before the choice of lower-level module, because not all interfaces have the same requirements. For example, VNC needs a TCP socket, which has to be passed in the parameters to SSH. Finally, I agree that a GUI would be a good default choice here, although it needs to be written in such a way that the ncurses/plaintext fallback looks quite natural to the user when everything goes wrong. However, I don't really do GUI programming, so it's not something I would be able to do myself. I'm now going to download dash and see whether I can fight my way out of that little box. If not, C it is. - Andrew Justin M. Wray wrote: I agree with your generalization, and ordering. It provides fault tolerance, security, and usability. Making the entire process esasier (the main goal of this project). I am unsure if I feel adding a numeric value to each option is needed, when simple programming conditions can handle the tasks. I think the numbers (bids) adds some uneeded complexity/confusion. The robustness and power of the solution we are now talking about exceeds the power of simple shell scripts and code hacks, thus needing a higher level language. But I personally see this as a good thing (speed, security, etc). I think it would be best to go through each option as you have them listed, and try them, once. If it works use it, if not move on. Only prompt the user if we get to an insecure option. But at the same time I think the helpless user should have the ability to over-ride the option, or the helper over-ride the option (with approval from the helpless) at start. A GUI front-end would le such choices be easily made. And an expert can easily tell the helpless to type --telnet at the end of the command. One more note, if we do use something like 'c' we could easily add a socket into the app itself. So we would have the following options, in said order: 1) SSH 2) bash-socat-cryptcat 3) bash-socat-netcat 4) bash-socat 5) telnet 6) bash-socket (I've changed the order around a bit, to what I think would more secure and sound.) And after connection, having the following recovery options: 1) A VNC-based GUI 2) An X-based GUI (for e.g. broken video cards) 3) A screen-based TUI (for those of us that love screen) 4) A pty-based TUI (so that editors like vi work) 5) A pipe-based TUI (for dire emergencies) 6) A non-interactive mechanism for swapping keys 7) Custom command (Which should have been selected when the recovery-command was first run.) It seems like we are on track, what do you think? Thanks, Justin M. Wray Sent via BlackBerry by ATT -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel
Re: Suggestion to make remote recovery easier
Okay, I've got the auction part of the dash adventure completed. In principle, the rest should be relatively easy. The code isn't vastly useful or commented so far, it's just a proof of concept really. The script doesn't prune unlikely matches (e.g. socat+ssh when ssh is already provided), because that doesn't work in the general case: say there are two pipelines, a-b-c and a-c-b. If a-b-c fails, it could be due to a problem in a, b, c, or some interaction between the three. Without knowing more about the error, we can't assume that a-c-b will fail. Here's a rough guide to the script: * Right now, the script reads bids from remote_help.txt, but will eventually take bids by polling a separate set of module scripts * A module script is run with a to-be-decided set of command line arguments. I'm currently thinking it'll be something like: my-module.sh --want remote-shell --remoteuser andrew \ --remotehost example.com this will have to be decided as modules are written - there'll doubtless be some rules, some precedents, and some totally protocol-specific things * Modules that sub-contract part of the job will be assumed to handle subcontracts internally (it's just a matter of calling remote_help.sh again with the appropriate arguments) * Every module is polled in every auction. Inapplicable scripts will return no bids, bids with a variety of subcontractors will return multiple bids * A bid is a line printed on standard output, of the form: integer command line The integer is the bid, the remainder of the line is a command to pass to /bin/sh * The highest bidder is repeatedly run until a bidder returns successfully (note: currently, all bids are run) * This would have been a lot easier if I could rely on `sort` and `head` existing! How should we proceed with this? Set up some space on Sourceforge? Do you have any better ideas for names than remote help? - Andrew remote_help.sh Description: application/shellscript -1 echo problem 3 /bin/false 2 echo foo 2 echo '2' 3 echo bar -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
I will look at your script as soon as I get to my desk. As for the project, let's set it up on sourceforge and on launchad. You want to create the projects, as you came up with the idea to start with? As for a name, I personally donot like remote help, nor remote recover. And Remote Assistance is taken :( We need some good name ideas... Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Thu, 08 May 2008 01:35:50 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Okay, I've got the auction part of the dash adventure completed. In principle, the rest should be relatively easy. The code isn't vastly useful or commented so far, it's just a proof of concept really. The script doesn't prune unlikely matches (e.g. socat+ssh when ssh is already provided), because that doesn't work in the general case: say there are two pipelines, a-b-c and a-c-b. If a-b-c fails, it could be due to a problem in a, b, c, or some interaction between the three. Without knowing more about the error, we can't assume that a-c-b will fail. Here's a rough guide to the script: * Right now, the script reads bids from remote_help.txt, but will eventually take bids by polling a separate set of module scripts * A module script is run with a to-be-decided set of command line arguments. I'm currently thinking it'll be something like: my-module.sh --want remote-shell --remoteuser andrew \ --remotehost example.com this will have to be decided as modules are written - there'll doubtless be some rules, some precedents, and some totally protocol-specific things * Modules that sub-contract part of the job will be assumed to handle subcontracts internally (it's just a matter of calling remote_help.sh again with the appropriate arguments) * Every module is polled in every auction. Inapplicable scripts will return no bids, bids with a variety of subcontractors will return multiple bids * A bid is a line printed on standard output, of the form: integer command line The integer is the bid, the remainder of the line is a command to pass to /bin/sh * The highest bidder is repeatedly run until a bidder returns successfully (note: currently, all bids are run) * This would have been a lot easier if I could rely on `sort` and `head` existing! How should we proceed with this? Set up some space on Sourceforge? Do you have any better ideas for names than remote help? - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Wow, you guys are going at this problem with a ferocious intent. We are already working on a remote support tool, a lot of what you've been talking about we have already talked about and built. So far it's not finished and much work is needed in peer review so if you can lend your time to looking at: https://launchpad.net/locoremotesupport/ We would be most grateful. Our plans are remote support using a combination of reverse tunnel ssh and jabber chat services. Do let me know if you start another project (coding) or if you figure out the ideal way of organising ssh. Best Regards, Martin Owens, Ubuntu-US-MA leader 2008/5/8 John McCabe-Dansted [EMAIL PROTECTED]: On Wed, May 7, 2008 at 6:56 AM, Andrew Sayers [EMAIL PROTECTED] wrote: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state thread. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
RE: Suggestion to make remote recovery easier
De: Andrew Sayers Enviado el: lun 05/05/2008 21:26 Para: ubuntu-devel-discuss Asunto: Suggestion to make remote recovery easier I'm a Linux user of sufficient experience that friends are starting to phone me up when there's a problem with their computer. I guess most people here know how long and painful those conversations can be, so I think it would be better if Ubuntu had a mechanism to let me SSH into people's computers using only instructions that I can describe to newbies over the phone without confusing them. Of course, the problem is doing this in a way that's both secure and robust. I've got an approximate outline of how it would work, so could people tell me how practical this idea is: Added to https://wiki.ubuntu.com/RemoteRecovery . Good work. You could propose it to Brainstorm and to Launchpad to make it a specification. The more secure way to work is in local phone call (modem). Regards. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
I've now updated the page that Pedro kindly started at https://wiki.ubuntu.com/Recovery/Remote - this includes all the ideas I've got so far. This is my first Ubuntu development thing, so yes, any help very much appreciated! You're quite right that the people you have to worry about aren't the ones that know nothing, but the ones that know just enough to be dangerous. In fact, given the desire for robustness (and the Robustness Principle in general), I think it would be best to design this facility based on the assumption that the user has been damaged their system as much as possible without actually disabling the remote-recovery script. That should encourage a sufficiently defencive design. Help with managing a system is an interesting use case, but I'm not sure if we want to be targeting it with this particular solution. I agree that sane defaults with powerful configuration is a good approach for users that know what the configuration options mean, but newbies with a broken system should be asked as few questions as possible (especially when they're paying for a long-distance phone call). Also, I think you're talking about an ongoing remote help relationship, rather than an emergency one shot thing. How about we break this off into a separate feature request: The Add User dialogue in Users settings (System-Administration-Users and Groups) should have the following extra options: * Disallow password logins * generate an SSH key, using either no passphrase, a randomly generated passphrase, the login password, or a specific passphrase. When the user account is added, the SSH public keys are given in a popup box * Add specified SSH public keys to .ssh/authorized_keys Then we can add a page to the help wiki, describing how to create a user for port-forwarding, how to create an SSH-only user, and how to make that user an administrator. That would give intermediate users all the tools they need to set up a permanent remote help relationship that they can tune to their particular needs. Given the above, I've left the iptables things more-or-less intact on the Remote Recovery page, since it's a good piece of robustness against newbies. Finally, two more ideas have occurred to me: 1) Rather than create a remote-recovery user on the recovery machine, why not just let the expert log in as root? Given all the other security measures, it wouldn't be any less secure, and would avoid the need to have a password kicking about. 2) Experts that have just finished a remote recovery session are probably the best people there are for providing high quality bug reports. Ubuntu already asks for unstructured feedback when installing a system, so it seems natural to give the same option to these people. Presumably we need to ask someone at Canonical about whether they'd be interested in this feedback? If so, who? - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like The basic solution we're looking at here is to make it possible for the technical friend to set up an SSH connection to the non-technical friend's computer, using an account that has some way to execute superuser commands (with sudo or by actually being the root user). This breaks down into three sub-problems: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state In (1) and (3), I had been concentrating on setting up a mechanism to trust someone temporarily, but I now realise that's not a particularly common use case, because if I trust you today, I will probably trust you tomorrow too. Getting people to jump through the same set of hoops every time there's a problem makes life harder than necessary for non-expert users, which I've been complaining about all thread. Reliably doing (2) is a hard problem. The solution I had come up with strikes me as a good solution for a common use case, but there's no way to deal with the general case without introducing more complexity. Solving the three sub-problems individually allows for more flexibility, because then intermediate users can mix-and-match the parts that they're interested in. Creating, modifying, and deleting accounts is a standard problem, and I've already suggested ways to add the necessary bits into Ubuntu (specifying an authorised key when creating an account, etc.). Since I used the alternate install CD, I don't know whether the default Ubuntu installation gives you the option to set up extra user accounts after installing. If it does, I'd recommend adding a technical friend user account creation option. But since most people will click straight through the above option, it would be good if this was offered explicitly somewhere in the System menu, and if a program like friendly-recovery could offer the same functionality from the command line. If there's an interest in it, I would be happy to maintain some sort of ssh-strategies script/page that walks people through an increasingly complex decision tree, trying to set up an SSH connection. In order to work easily, there would probably have to be some sort of ssh-strategies-minimal package in the default install. I'd be even more happy if Canonical were willing to host a couple of very simple scripts at ubuntu.com to confirm the user's world-visible IP address and to reflect half a dozen SSH packets back to the address they came from. The former can't be done over HTTP because of the mess of transparent proxies on the net nowadays, and the latter should be safe so long as just enough packets to appear in the SSH log are sent, but not enough to try a password are sent. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
On Tue, 06 May 2008 23:56:18 +0100 Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like 7) Most end users have an extremely niave view of security. They want security, but understand very little about how changes to their systems affect the security of their systems. Changes made cannot make systems less secure. I'd invite you to look at the rate of ssh dictionary attacks on internet exposed boxes and consider if any password based ssh solution is appropriate. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
On Tue, May 6, 2008 at 8:20 PM, Scott Kitterman [EMAIL PROTECTED] wrote: On Tue, 06 May 2008 23:56:18 +0100 Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like 7) Most end users have an extremely niave view of security. They want security, but understand very little about how changes to their systems affect the security of their systems. Changes made cannot make systems less secure. I'd invite you to look at the rate of ssh dictionary attacks on internet exposed boxes and consider if any password based ssh solution is appropriate. There has been quite a bit of research on this topic at Clarkson University. see: http://monitor.sclab.clarkson.edu/thesis.doc and http://monitor.sclab.clarkson.edu/appendicies.doc Abstract: In its Top-20 Security Risks report for 2007, the SANS Institute called brute-force password guessing attacks against SSH, FTP and Telnet servers the most common form of attack to compromise servers facing the Internet.Another recent study also suggests that Linux systems may play an important role in the command and control systems for botnets. Defending against brute-force SSH attacks may therefore prove to be a key factor in the effort to disrupt these networks. We report on a study of brute-force SSH attacks observed on three very different networks: an Internet-connected small business network, a residential system with a DSL Internet connection, and a university campus network. The similarities observed in the methods used to attack these disparate systems are quite striking. The evidence suggests that many brute-force attacks are based on pre-compiled lists of usernames and passwords, which are widely shared. We were able to confirm the existence of one such pre-compiled list after it was discovered in a SSH attack toolkit captured in a related honeypot project. Analysis of the passwords used in actual malicious SSH traffic suggests that the common understanding of what constitutes a strong password may no longer be sufficient to protect systems from compromise. Study data are also used to evaluate the effectiveness of a variety of techniques designed to defend against these attacks. Cheers, Todd -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Based on this evidence, does anybody object to a bug report being filed against openssh-server, saying that password authentication should be disabled by default? Of course, that leaves all my ideas in serious trouble, but that's a secondary matter. - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
On Tue, May 6, 2008 at 8:40 PM, Andrew Sayers [EMAIL PROTECTED] wrote: Based on this evidence, does anybody object to a bug report being filed against openssh-server, saying that password authentication should be disabled by default? Of course, that leaves all my ideas in serious trouble, but that's a secondary matter. One intermediate take away from the study is that using a high non-standard port is often good enough (for now). Also, having denyhosts configured with a sync download threshold of 3 will block a high percentage (I think it said %75 or so) You have to remember that security is a game of escalation and even though people should try to stay ahead of the attackers, they often don't. Should Ubuntu packages force them to do things that they don't necessarily yet understand? I think that topic is a thread of its own if people want to go down that path. More closely to the thread at hand, a reasonable amount of security could be gained by using a non-standard port, a hard username/password, and/ or using SSH keys. Cheers, Todd -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
On 5/7/08, Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like The basic solution we're looking at here is to make it possible for the technical friend to set up an SSH connection to the non-technical friend's computer, using an account that has some way to execute superuser commands (with sudo or by actually being the root user). This breaks down into three sub-problems: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state In (1) and (3), I had been concentrating on setting up a mechanism to trust someone temporarily, but I now realise that's not a particularly common use case, because if I trust you today, I will probably trust you tomorrow too. Getting people to jump through the same set of hoops every time there's a problem makes life harder than necessary for non-expert users, which I've been complaining about all thread. Reliably doing (2) is a hard problem. The solution I had come up with strikes me as a good solution for a common use case, but there's no way to deal with the general case without introducing more complexity. The other option here might be to flip the problem around: the technical user almost certainly _is_ in control of the NAT they're behind, so you could try writing up a server on the techy-friend side that a client connects to in order to get help. This would have the advantage that you probably don't need to care about what NAT/firewall the helpee is behind, and might also ease some security concerns - the helpee must explicitly start the connection, the helper can start the server only when required, and it doesn't give shell access to anyone who connects. And the obvious disadvantage that this client/server needs to be written. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
This was the original idea, with the SSH reverse tunnel... It would be the easiest way to deal with the NAT/Firewall issue, without complex pre-help assistance and documentation. It can also be used in conjunction with ACL's (for SSH) and therefore secure the process even more. (Ie, limit SSH to loclhost only) Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Christopher Halse Rogers [EMAIL PROTECTED] Date: Wed, 7 May 2008 11:51:29 To:Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier On 5/7/08, Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like The basic solution we're looking at here is to make it possible for the technical friend to set up an SSH connection to the non-technical friend's computer, using an account that has some way to execute superuser commands (with sudo or by actually being the root user). This breaks down into three sub-problems: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state In (1) and (3), I had been concentrating on setting up a mechanism to trust someone temporarily, but I now realise that's not a particularly common use case, because if I trust you today, I will probably trust you tomorrow too. Getting people to jump through the same set of hoops every time there's a problem makes life harder than necessary for non-expert users, which I've been complaining about all thread. Reliably doing (2) is a hard problem. The solution I had come up with strikes me as a good solution for a common use case, but there's no way to deal with the general case without introducing more complexity. The other option here might be to flip the problem around: the technical user almost certainly _is_ in control of the NAT they're behind, so you could try writing up a server on the techy-friend side that a client connects to in order to get help. This would have the advantage that you probably don't need to care about what NAT/firewall the helpee is behind, and might also ease some security concerns - the helpee must explicitly start the connection, the helper can start the server only when required, and it doesn't give shell access to anyone who connects. And the obvious disadvantage that this client/server needs to be written. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Another idea would be to not only tunnel SSH but also VNC. Allowing the newbie to watch the helper do something at times might be the goal, and will make help facilitate learning. In addition the issue might be with a GTK/GUI app, and VNC would be the fastest approch. Just another thought, the security problems tend to be the same, but the same ACLs can be applied (limit to localhost etc). Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Justin M. Wray [EMAIL PROTECTED] Date: Wed, 7 May 2008 03:40:52 To:Christopher Halse Rogers [EMAIL PROTECTED],Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier This was the original idea, with the SSH reverse tunnel... It would be the easiest way to deal with the NAT/Firewall issue, without complex pre-help assistance and documentation. It can also be used in conjunction with ACL's (for SSH) and therefore secure the process even more. (Ie, limit SSH to loclhost only) Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Christopher Halse Rogers [EMAIL PROTECTED] Date: Wed, 7 May 2008 11:51:29 To:Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier On 5/7/08, Andrew Sayers [EMAIL PROTECTED] wrote: At this point, I'm trying to walk the line between unrealistic wouldn't it be great if... type ideas and overly-strict reliance on solving the specific problem I have in my head, so I'd like to go back to first principles for a moment. Please tell me if any of these are false: 1) It's common for new Linux users to have a technical friend that deals with their problems. This is a healthy relationship that we should look for ways to support 2) People generally don't formalise that sort of thing until it's too late 3) All Linux users can be behind arbitrarily complex sets of firewalls/NAT, including multiple layers of NAT or firewalls, not all of which are under either user's control 4) We can expect experts to do some considerable work (e.g. installing packages and configuring routers), but non-technical users need simple instructions from the default installation 5) There's some interest in making small changes to the default install to cater to the above issues 6) Since the people in most need of help are more likely to stick to LTS releases, we can afford to add this sort of feature gradually, and see what public reaction is like The basic solution we're looking at here is to make it possible for the technical friend to set up an SSH connection to the non-technical friend's computer, using an account that has some way to execute superuser commands (with sudo or by actually being the root user). This breaks down into three sub-problems: 1) Creating or modifying an account that has the necessary permissions 2) Creating an SSH connection 3) Destroying or reverting an account to its original state In (1) and (3), I had been concentrating on setting up a mechanism to trust someone temporarily, but I now realise that's not a particularly common use case, because if I trust you today, I will probably trust you tomorrow too. Getting people to jump through the same set of hoops every time there's a problem makes life harder than necessary for non-expert users, which I've been complaining about all thread. Reliably doing (2) is a hard problem. The solution I had come up with strikes me as a good solution for a common use case, but there's no way to deal with the general case without introducing more complexity. The other option here might be to flip the problem around: the technical user almost certainly _is_ in control of the NAT they're behind, so you could try writing up a server on the techy-friend side that a client connects to in order to get help. This would have the advantage that you probably don't need to care about what NAT/firewall the helpee is behind, and might also ease some security concerns - the helpee must explicitly start the connection, the helper can start the server only when required, and it doesn't give shell access to anyone who connects. And the obvious disadvantage that this client/server needs to be written. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Suggestion to make remote recovery easier
I'm a Linux user of sufficient experience that friends are starting to phone me up when there's a problem with their computer. I guess most people here know how long and painful those conversations can be, so I think it would be better if Ubuntu had a mechanism to let me SSH into people's computers using only instructions that I can describe to newbies over the phone without confusing them. Of course, the problem is doing this in a way that's both secure and robust. I've got an approximate outline of how it would work, so could people tell me how practical this idea is: * There should be three ways to enable remote recovery: - In the GRUB menu, there should be a remote recovery option - From the command-line, there should be a remote-recovery command - From the GUI, there should be System Tools-Remote Recovery * Experts should be able to run /usr/sbin/connect-to-remote-recovery to prepare their system for a remote recovery. Running or connecting to a remote recovery should start by doing the following: 1) Create a remote-recovery user whose home directory is /.remote-recovery, and who has no useful permissions 2) Set their home directory to be chmod 500 3) Create a ~remote-recovery/password file, chmod 400 4) Give the remote-recovery user a random password, and put the password in ~remote-recovery/password 5) If the SSH server isn't running, enable it. If it won't enable, try various things: * If the package doesn't exist, ask if you can install it * If /usr or /usr/bin doesn't exist, check whether they're mentioned in /etc/fstab, and if so, whether they're mentioned in `mount`, then tell the user what's going on, and offer to print the contents of both. Then, running remote recovery should: 1) pop up a warning about how doing this gives complete control of your system to a specified computer, and should only be done at the behest of someone you trust. 2) Add the remote-recovery user to /etc/sudoers 3) Ask for the IP address and remote-recovery password of the person you'll allow access to 4) `ssh [EMAIL PROTECTED] -L22:localhost:` 4a) if that fails, do various diagnostics: * Does the computer have an IP address? Does it have a gateway? * Do a tracepath to that address and print the results 4b) If it succeeds, copy .ssh/id_dsa.pub on the remote host to ~remote-recovery/.ssh/authorized_keys on the local host, then touch .ssh/id_dsa.pub to confirm that the copying is complete 5) Tell the user whether SSH succeeded or failed 6) Inform the user that they can press ctrl-c to quit remote recovery 7) Wait until `w` reports a remote-recovery user logged in 8) Read lines of text and `write` them to the remote-recovery user's tty 9) When the remote-recovery user logs out, ask whether they want to wait for the user to log in again. 9a) If no, go to 10 9b) else go to 7 10) Remove the remote-recovery user, remove them from sudoers, and delete their home directory Alternatively, connecting to a remote recovery should do: 1) Find the IP address(es) of the computer 1a) If any addresses are public (not e.g. 192.168.*.*), print them 1b) Otherwise, tell the user to find their public address (e.g. through the settings page of their wireless router), and make sure that connections on port 22 are forwarded to private IP address port 22. 2) touch ~remote-recovery/password 3) Create a ~/.ssh/id_dsa with no passphrase 4) Print the contents of ~remote-recovery/password, then print it again, using the NATO phonetic alphabet (so that it can be spoken over the phone) 5) Make sure the SSH server is running 6) Wait until the ctime of ~remote-recovery/password is less than the ctime of ~remote-recovery/.ssh/id_dsa 7) `sudo -u remote-recovery ssh [EMAIL PROTECTED] -p ` 8) The user now has a shell on the newbie's computer, as user remote-recovery. They can then read the password in ~/password, and sudo whatever they need to sudo. 9) Remove the remote-recovery user and delete their home directory - Andrew Sayers -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Fw: Suggestion to make remote recovery easier
Sending to the list... Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Justin M. Wray [EMAIL PROTECTED] Date: Tue, 6 May 2008 00:08:39 To:Milosz Derezynski [EMAIL PROTECTED] Subject: Re: Suggestion to make remote recovery easier A random password would be far more secure then the password set by the average user seeking this service. Far too often I see someone using things like helpme or password as the normal newbie cannot come up with a complex password on the spot. However, I do agree that I dislike the current way the password is retrevied by the remote-helper. I think it would make more sense to print the random password to the screen and then allow the newbie to read it to the person they trust. Therefore if anythink goes wrong, there is one more layer of security, not that I think the security of a systenm should be left in the hands of a newbie user, it is there system. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Milosz Derezynski [EMAIL PROTECTED] Date: Tue, 6 May 2008 01:56:50 To:Andrew Sayers [EMAIL PROTECTED] Cc:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier There is IMO no real need for a random password; instead, the user of the machine to be recovered should be allowed to enter a password which he then can tell to the user recovering the machine remotely. This doesn't neccessarily have to be more insecure; a random alphanum password is probably better secured against brute force cracking but i don't like the fact that the computer hands out a password for the user automatically, even if he gets to see it. 2008/5/5 Andrew Sayers [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : I'm a Linux user of sufficient experience that friends are starting to phone me up when there's a problem with their computer. I guess most people here know how long and painful those conversations can be, so I think it would be better if Ubuntu had a mechanism to let me SSH into people's computers using only instructions that I can describe to newbies over the phone without confusing them. Of course, the problem is doing this in a way that's both secure and robust. I've got an approximate outline of how it would work, so could people tell me how practical this idea is: * There should be three ways to enable remote recovery: - In the GRUB menu, there should be a remote recovery option - From the command-line, there should be a remote-recovery command - From the GUI, there should be System Tools-Remote Recovery * Experts should be able to run /usr/sbin/connect-to-remote-recovery to prepare their system for a remote recovery. Running or connecting to a remote recovery should start by doing the following: 1) Create a remote-recovery user whose home directory is /.remote-recovery, and who has no useful permissions 2) Set their home directory to be chmod 500 3) Create a ~remote-recovery/password file, chmod 400 4) Give the remote-recovery user a random password, and put the password in ~remote-recovery/password 5) If the SSH server isn't running, enable it. If it won't enable, try various things: * If the package doesn't exist, ask if you can install it * If /usr or /usr/bin doesn't exist, check whether they're mentioned in /etc/fstab, and if so, whether they're mentioned in `mount`, then tell the user what's going on, and offer to print the contents of both. Then, running remote recovery should: 1) pop up a warning about how doing this gives complete control of your system to a specified computer, and should only be done at the behest of someone you trust. 2) Add the remote-recovery user to /etc/sudoers 3) Ask for the IP address and remote-recovery password of the person you'll allow access to 4) `ssh [EMAIL PROTECTED] -L22:localhost:` 4a) if that fails, do various diagnostics: * Does the computer have an IP address? Does it have a gateway? * Do a tracepath to that address and print the results 4b) If it succeeds, copy .ssh/id_dsa.pub on the remote host to ~remote-recovery/.ssh/authorized_keys on the local host, then touch .ssh/id_dsa.pub to confirm that the copying is complete 5) Tell the user whether SSH succeeded or failed 6) Inform the user that they can press ctrl-c to quit remote recovery 7) Wait until `w` reports a remote-recovery user logged in 8) Read lines of text and `write` them to the remote-recovery user's tty 9) When the remote-recovery user logs out, ask whether they want to wait for the user to log in again. 9a) If no, go to 10 9b) else go to 7 10) Remove the remote-recovery user, remove them from sudoers, and delete their home directory Alternatively, connecting to a remote recovery should do: 1) Find the IP address(es) of the computer 1a) If any addresses are public (not e.g. 192.168.*.*), print them 1b) Otherwise, tell the user
Re: Suggestion to make remote recovery easier
Milosz Derezynski wrote: There is IMO no real need for a random password; instead, the user of the machine to be recovered should be allowed to enter a password which he then can tell to the user recovering the machine remotely. This doesn't neccessarily have to be more insecure; a random alphanum password is probably better secured against brute force cracking but i don't like the fact that the computer hands out a password for the user automatically, even if he gets to see it. I'm not sure if I follow. If you're complaining about the password on the expert's machine, I'm suggesting that the newbie SSH in to the expert first because I'm happier to assume that an expert would know how to poke a hole through their firewall/NAT router/etc. than I am to assume the same of a newbie. Once that first connection is made, everything gets tunnelled over it. If you're complaining about the password on the newbie's machine, getting them to make decisions and speak passwords is likely to add stress and errors, because they might feel silly about being asked more questions they don't know anything about, might feel silly about spelling a password out phonetically, and might (as Justin pointed out) choose a bad password. Having said all that, how would you feel about these changes: * The connect-to-remote-recovery script on the expert's machine suggests a random password, and asks if you want to choose one manually. * While waiting for an SSH connection, the connect-to-remote-recovery script on the expert's computer keeps an eye on `w` and/or the ssh log, waits for the user to press enter, then does `passwd -d remote-recovery` as soon as they do. That would make brute-forcing an SSH connection to the expert's machine impractical * The remote recovery script on the newbie's computer does `iptables -I INPUT -i ! lo -m state --state NEW -j DROP` (and the same with iptables6) before creating the remote-recovery user, and removes those rules after deleting the user. That would make brute-forcing any connection impossible, even if (for example) the newbie had set himself up a publicly-available FTP server Also, how would people feel about the following changes based on unrelated problems: * Instead of /.remote-recovery, set the user's home directory to /tmp/rr, so it works even on some weird UMSDOS partition, and gets auto-deleted if the computer gets unexpectedly rebooted * Create an init script that deletes the remote-recovery user at boot (again, in case of unexpected reboots) - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Andrew, et all, The iptable changes would be a plus, but should be configurable, with sane defaults. I personally would be upset if my current rules were altered without my approval. And it may not be feesable to completely firewall the entire system. In general, if you setup a SSH key (or use one already created), then brute-force shouldn't be a huge issue. Its just the transmission of the password to sudo. And storage thereafter that needs to be secured. The changes to a home directory in /tmp is a smart move, incase something goes wrong, and it is a bit cleaner as well. However on some systems this may not work nicely (noexec on /tmp, etc). Remember not all newbies are completely lost. Someone may want assistance with a complex system or service, and likes the ease of remote recovery, but that doesn't mean they don't manage the system properly, thus the comments above. I find it unwise to make assumtions about the users of a service/solution. It is better to come up with clear defaults, with powerful configuration options. The clean-up scripts is also a wise addition. +1 for the general idea. Remote Help should be easy to obtain, and I too have been on the support call debugging ssh/firewalls before I could work on the true issue. So I welcome the addition of a sound solution. I am on the road at the moment. But in a bit (few hours), I am going to sit down, review what you have already mentioned, and attempt to help workout a clear plan of action. If you have not created a blueprint, you should do so, if you would like I can assist with the creation the blueprint, etc. Thanks, Justin M. Wray Sent via BlackBerry by ATT -Original Message- From: Andrew Sayers [EMAIL PROTECTED] Date: Tue, 06 May 2008 02:51:25 To:ubuntu-devel-discuss@lists.ubuntu.com Subject: Re: Suggestion to make remote recovery easier Milosz Derezynski wrote: There is IMO no real need for a random password; instead, the user of the machine to be recovered should be allowed to enter a password which he then can tell to the user recovering the machine remotely. This doesn't neccessarily have to be more insecure; a random alphanum password is probably better secured against brute force cracking but i don't like the fact that the computer hands out a password for the user automatically, even if he gets to see it. I'm not sure if I follow. If you're complaining about the password on the expert's machine, I'm suggesting that the newbie SSH in to the expert first because I'm happier to assume that an expert would know how to poke a hole through their firewall/NAT router/etc. than I am to assume the same of a newbie. Once that first connection is made, everything gets tunnelled over it. If you're complaining about the password on the newbie's machine, getting them to make decisions and speak passwords is likely to add stress and errors, because they might feel silly about being asked more questions they don't know anything about, might feel silly about spelling a password out phonetically, and might (as Justin pointed out) choose a bad password. Having said all that, how would you feel about these changes: * The connect-to-remote-recovery script on the expert's machine suggests a random password, and asks if you want to choose one manually. * While waiting for an SSH connection, the connect-to-remote-recovery script on the expert's computer keeps an eye on `w` and/or the ssh log, waits for the user to press enter, then does `passwd -d remote-recovery` as soon as they do. That would make brute-forcing an SSH connection to the expert's machine impractical * The remote recovery script on the newbie's computer does `iptables -I INPUT -i ! lo -m state --state NEW -j DROP` (and the same with iptables6) before creating the remote-recovery user, and removes those rules after deleting the user. That would make brute-forcing any connection impossible, even if (for example) the newbie had set himself up a publicly-available FTP server Also, how would people feel about the following changes based on unrelated problems: * Instead of /.remote-recovery, set the user's home directory to /tmp/rr, so it works even on some weird UMSDOS partition, and gets auto-deleted if the computer gets unexpectedly rebooted * Create an init script that deletes the remote-recovery user at boot (again, in case of unexpected reboots) - Andrew -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Suggestion to make remote recovery easier
Personally, I'd suggest leaving any neophyte user's computer exposed to the internet and not behind a firewall of some kind would be a mistake. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
