Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy:> Hi Everyone, > > Does anyone have any idea on how to give my customers a "web console" > for their VMs? > > Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set > up a remote session for them, by doing > ajaxterm.py -c xm console <DOMNAME> > However is there any way to make this automatic? Maybe I could put it in the vif script? > > Thanks > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Felix, Thanks for the email.>a simple init=/bin/bash added to the kernel command line allows resetting the root password...ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy:> > Hi Felix, > > Thanks for the email. > > >a simple init=/bin/bash added to the kernel command line allows > resetting the root password... > ok this worries me. Can you please explain this a little further? Do > you need to have access to the Dom0 to begin with? > > Thanks > > ------------------------------------------------------------------------ > *From:* xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans > *Sent:* Fri 18/06/2010 12:54 > *To:* xen-users@lists.xensource.com > *Subject:* Re: [Xen-users] Web Console Access > > Hi Jonathan, > > do you definitely need a web console (so really browser-based) or > would you consider a SSH-based console? > > I personally prefer SSH because it is more secure, easier to set up > and it is somehow the default way of accessing remote consoles. You > can do a modified SSH setup that only allows access to the console, or > optionally, access to xm console, xm list, xm shutdown, xm create but > restricted to the own VM of your customer. With chroot-jails etc., > other commands cannot be executed. > SSH also has the advantage of good copy & paste of larger commands, > and the possibility to work with multiple client certificates and / or > passwords. Probably your administrative interface allows uploading of > multiple public keys, so that your customers can have multiple > adminsitrative accounts for the server (but only one can access the > console at a time). > > I''ve got no experiences with ajaxterm, but you should really control > its security: > Console access is quite useful for hackers, e.g. some customer may > forget to log out root or if you use pvgrub / pygrub, a simple > init=/bin/bash added to the kernel command line allows resetting the > root password... > So it must be a really secure application, not vulnerable to XSS, SQL > Injections, Connection hijacking, ... and SSL encrypted. > > Regards, > Felix Kuperjans > > Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >> Hi Everyone, >> >> Does anyone have any idea on how to give my customers a "web console" >> for their VMs? >> >> Using http://antony.lesuisse.org/software/ajaxterm/ I can manually >> set up a remote session for them, by doing >> ajaxterm.py -c xm console <DOMNAME> >> However is there any way to make this automatic? Maybe I could put it in the vif script? >> >> Thanks >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Felix, I actually have that guy''s book who wrote that article - The book of Xen - very good book indeed! What I really wish to do, is provide a similar sort of thing to that SSH setup, except allow it to be accessed via a web browser. I have an idea where I can use ajaxterm and some PHP scripting. Once a user logs on with a username and password, I could tell php to start ajaxterm and piple xm console through it. This is what Slicehost does I think. The console would be protected with php sessions. But my main worry was whether or not the Dom0 could be compramised via the above method, but I don''t think that''s the case. Thanks Jonathan ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 13:50 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy: Hi Felix, Thanks for the email. >a simple init=/bin/bash added to the kernel command line allows resetting the root password... ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, the Dom0 cannot be compromised as long as your SSH or web-based console does not have any security leaks. PHP sessions are not as secure as SSH, but with SSL and suhosin patched PHP considerably OK. As I said, I don''t use web-based consoles so I can''t help you there, but I''d *really* consider whether it is a good thing to setup a webserver on a Dom0 and it may be probably hard to do web-based consoles without that. Regards, Felix P.S. Anyway, considering the method I posted, you should always setup GRUB and BIOS passwords for all of your Dom0s. I once requested KVM access at my provider and ended up at the wrong server... Am 18.06.2010 15:03, schrieb Jonathan Tripathy:> Hi Felix, > > I actually have that guy''s book who wrote that article - The book of > Xen - very good book indeed! > > What I really wish to do, is provide a similar sort of thing to that > SSH setup, except allow it to be accessed via a web browser. I have an > idea where I can use ajaxterm and some PHP scripting. Once a user logs > on with a username and password, I could tell php to start ajaxterm > and piple xm console through it. This is what Slicehost does I think. > The console would be protected with php sessions. > > But my main worry was whether or not the Dom0 could be compramised via > the above method, but I don''t think that''s the case. > > Thanks > > Jonathan > ------------------------------------------------------------------------ > *From:* xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans > *Sent:* Fri 18/06/2010 13:50 > *To:* xen-users@lists.xensource.com > *Subject:* Re: [Xen-users] Web Console Access > > Hi Jonathan, > > this is a common way to reset lost / forgotton root passwords: > > You need: > - Physical access to a machine (if you want to reset the password of > the Dom0 or a native linux) or console access to a DomU > - Access to the kernel command line, via lilo, grub or pygrub/pvgrub > in XEN > > Then you do: > - Modify the kernel command line, add the init=/bin/bash option, for > example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash > - You''ll directly end up in a root console without password or any > services started after the kernel booted > - enter those commands: > mount -o remount,rw / > passwd root > <enter new password> > exec /sbin/init > > The root password will then be the newly set one. > > DomUs generally are not vulnerable to this method, as long as the > kernel command line is set in the domain configuration. But > pygrub/pvgrub is a nice thing for hosting customers, because they can > compile their own kernels, containing their preferred settings, > modules and builtin functionality. Generally this problem is avoided > by adding a password to grub, but some customers may forget that step. > So physical access can always be a strong weapon, but it is necessary > for repairing a machine or for some advanced setups (especially when > setting up a firewall, one easily gets locked out of the server...). I > think the best way is securing this access, by restricting virtual > console access to highly encrypted and authenticated sessions (IMHO > the best way is SSH here). > > I''d also think about customers forgetting to log out, because leaving > xm console does *not* logout root inside the console. > > The tutorial I posted to your I/O question contains a SSH-based setup > for xm console access with sudo, which may be nice to start with. I > personally use an own wrapper inside a chroot jail, to provide the > ability of entering commands like create / rescue / setup (rescue > starts another domain configuration with NFS root + rescue-Kernel, > setup starts a virtual Debian setup). It''s quite handy for VPS customers. > > Regards, > Felix > > Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >> >> Hi Felix, >> >> Thanks for the email. >> >> >a simple init=/bin/bash added to the kernel command line allows >> resetting the root password... >> ok this worries me. Can you please explain this a little further? Do >> you need to have access to the Dom0 to begin with? >> >> Thanks >> >> ------------------------------------------------------------------------ >> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >> Kuperjans >> *Sent:* Fri 18/06/2010 12:54 >> *To:* xen-users@lists.xensource.com >> *Subject:* Re: [Xen-users] Web Console Access >> >> Hi Jonathan, >> >> do you definitely need a web console (so really browser-based) or >> would you consider a SSH-based console? >> >> I personally prefer SSH because it is more secure, easier to set up >> and it is somehow the default way of accessing remote consoles. You >> can do a modified SSH setup that only allows access to the console, >> or optionally, access to xm console, xm list, xm shutdown, xm create >> but restricted to the own VM of your customer. With chroot-jails >> etc., other commands cannot be executed. >> SSH also has the advantage of good copy & paste of larger commands, >> and the possibility to work with multiple client certificates and / >> or passwords. Probably your administrative interface allows uploading >> of multiple public keys, so that your customers can have multiple >> adminsitrative accounts for the server (but only one can access the >> console at a time). >> >> I''ve got no experiences with ajaxterm, but you should really control >> its security: >> Console access is quite useful for hackers, e.g. some customer may >> forget to log out root or if you use pvgrub / pygrub, a simple >> init=/bin/bash added to the kernel command line allows resetting the >> root password... >> So it must be a really secure application, not vulnerable to XSS, SQL >> Injections, Connection hijacking, ... and SSL encrypted. >> >> Regards, >> Felix Kuperjans >> >> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>> Hi Everyone, >>> >>> Does anyone have any idea on how to give my customers a "web >>> console" for their VMs? >>> >>> Using http://antony.lesuisse.org/software/ajaxterm/ I can manually >>> set up a remote session for them, by doing >>> ajaxterm.py -c xm console <DOMNAME> >>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>> >>> Thanks >>> >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Felix, Probably the main reason why I want to use a web console is so that I can run the web server on a different machine (Or maybe in a VM connected to an isolated network). Thanks for the tip on the Grub password for the Dom0. That''s scary about the KVM! Thanks Jonathan ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 14:13 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, the Dom0 cannot be compromised as long as your SSH or web-based console does not have any security leaks. PHP sessions are not as secure as SSH, but with SSL and suhosin patched PHP considerably OK. As I said, I don''t use web-based consoles so I can''t help you there, but I''d *really* consider whether it is a good thing to setup a webserver on a Dom0 and it may be probably hard to do web-based consoles without that. Regards, Felix P.S. Anyway, considering the method I posted, you should always setup GRUB and BIOS passwords for all of your Dom0s. I once requested KVM access at my provider and ended up at the wrong server... Am 18.06.2010 15:03, schrieb Jonathan Tripathy: Hi Felix, I actually have that guy''s book who wrote that article - The book of Xen - very good book indeed! What I really wish to do, is provide a similar sort of thing to that SSH setup, except allow it to be accessed via a web browser. I have an idea where I can use ajaxterm and some PHP scripting. Once a user logs on with a username and password, I could tell php to start ajaxterm and piple xm console through it. This is what Slicehost does I think. The console would be protected with php sessions. But my main worry was whether or not the Dom0 could be compramised via the above method, but I don''t think that''s the case. Thanks Jonathan ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 13:50 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy: Hi Felix, Thanks for the email. >a simple init=/bin/bash added to the kernel command line allows resetting the root password... ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, if you can do that, it''s good. But you''ll always need some kind of access to the Dom0 to get the console data and to reboot / reset / rescue the VMs (whatever you want to offer to your customers). Regards, Felix Am 18.06.2010 15:17, schrieb Jonathan Tripathy:> Hi Felix, > > Probably the main reason why I want to use a web console is so that I > can run the web server on a different machine (Or maybe in a VM > connected to an isolated network). > > Thanks for the tip on the Grub password for the Dom0. That''s scary > about the KVM! > > Thanks > > Jonathan > > ------------------------------------------------------------------------ > *From:* Felix Kuperjans [mailto:felix@desaster-games.com] > *Sent:* Fri 18/06/2010 14:13 > *To:* Jonathan Tripathy > *Cc:* xen-users@lists.xensource.com > *Subject:* Re: [Xen-users] Web Console Access > > Hi Jonathan, > > the Dom0 cannot be compromised as long as your SSH or web-based > console does not have any security leaks. > PHP sessions are not as secure as SSH, but with SSL and suhosin > patched PHP considerably OK. > > As I said, I don''t use web-based consoles so I can''t help you there, > but I''d *really* consider whether it is a good thing to setup a > webserver on a Dom0 and it may be probably hard to do web-based > consoles without that. > > Regards, > Felix > > P.S. Anyway, considering the method I posted, you should always setup > GRUB and BIOS passwords for all of your Dom0s. I once requested KVM > access at my provider and ended up at the wrong server... > > Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >> Hi Felix, >> >> I actually have that guy''s book who wrote that article - The book of >> Xen - very good book indeed! >> >> What I really wish to do, is provide a similar sort of thing to that >> SSH setup, except allow it to be accessed via a web browser. I have >> an idea where I can use ajaxterm and some PHP scripting. Once a user >> logs on with a username and password, I could tell php to start >> ajaxterm and piple xm console through it. This is what Slicehost does >> I think. The console would be protected with php sessions. >> >> But my main worry was whether or not the Dom0 could be compramised >> via the above method, but I don''t think that''s the case. >> >> Thanks >> >> Jonathan >> ------------------------------------------------------------------------ >> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >> Kuperjans >> *Sent:* Fri 18/06/2010 13:50 >> *To:* xen-users@lists.xensource.com >> *Subject:* Re: [Xen-users] Web Console Access >> >> Hi Jonathan, >> >> this is a common way to reset lost / forgotton root passwords: >> >> You need: >> - Physical access to a machine (if you want to reset the password of >> the Dom0 or a native linux) or console access to a DomU >> - Access to the kernel command line, via lilo, grub or pygrub/pvgrub >> in XEN >> >> Then you do: >> - Modify the kernel command line, add the init=/bin/bash option, for >> example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash >> - You''ll directly end up in a root console without password or any >> services started after the kernel booted >> - enter those commands: >> mount -o remount,rw / >> passwd root >> <enter new password> >> exec /sbin/init >> >> The root password will then be the newly set one. >> >> DomUs generally are not vulnerable to this method, as long as the >> kernel command line is set in the domain configuration. But >> pygrub/pvgrub is a nice thing for hosting customers, because they can >> compile their own kernels, containing their preferred settings, >> modules and builtin functionality. Generally this problem is avoided >> by adding a password to grub, but some customers may forget that step. >> So physical access can always be a strong weapon, but it is necessary >> for repairing a machine or for some advanced setups (especially when >> setting up a firewall, one easily gets locked out of the server...). >> I think the best way is securing this access, by restricting virtual >> console access to highly encrypted and authenticated sessions (IMHO >> the best way is SSH here). >> >> I''d also think about customers forgetting to log out, because leaving >> xm console does *not* logout root inside the console. >> >> The tutorial I posted to your I/O question contains a SSH-based setup >> for xm console access with sudo, which may be nice to start with. I >> personally use an own wrapper inside a chroot jail, to provide the >> ability of entering commands like create / rescue / setup (rescue >> starts another domain configuration with NFS root + rescue-Kernel, >> setup starts a virtual Debian setup). It''s quite handy for VPS customers. >> >> Regards, >> Felix >> >> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>> >>> Hi Felix, >>> >>> Thanks for the email. >>> >>> >a simple init=/bin/bash added to the kernel command line allows >>> resetting the root password... >>> ok this worries me. Can you please explain this a little further? Do >>> you need to have access to the Dom0 to begin with? >>> >>> Thanks >>> >>> ------------------------------------------------------------------------ >>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>> Kuperjans >>> *Sent:* Fri 18/06/2010 12:54 >>> *To:* xen-users@lists.xensource.com >>> *Subject:* Re: [Xen-users] Web Console Access >>> >>> Hi Jonathan, >>> >>> do you definitely need a web console (so really browser-based) or >>> would you consider a SSH-based console? >>> >>> I personally prefer SSH because it is more secure, easier to set up >>> and it is somehow the default way of accessing remote consoles. You >>> can do a modified SSH setup that only allows access to the console, >>> or optionally, access to xm console, xm list, xm shutdown, xm create >>> but restricted to the own VM of your customer. With chroot-jails >>> etc., other commands cannot be executed. >>> SSH also has the advantage of good copy & paste of larger commands, >>> and the possibility to work with multiple client certificates and / >>> or passwords. Probably your administrative interface allows >>> uploading of multiple public keys, so that your customers can have >>> multiple adminsitrative accounts for the server (but only one can >>> access the console at a time). >>> >>> I''ve got no experiences with ajaxterm, but you should really control >>> its security: >>> Console access is quite useful for hackers, e.g. some customer may >>> forget to log out root or if you use pvgrub / pygrub, a simple >>> init=/bin/bash added to the kernel command line allows resetting the >>> root password... >>> So it must be a really secure application, not vulnerable to XSS, >>> SQL Injections, Connection hijacking, ... and SSL encrypted. >>> >>> Regards, >>> Felix Kuperjans >>> >>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>> Hi Everyone, >>>> >>>> Does anyone have any idea on how to give my customers a "web >>>> console" for their VMs? >>>> >>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can manually >>>> set up a remote session for them, by doing >>>> ajaxterm.py -c xm console <DOMNAME> >>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>> >>>> Thanks >>>> >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xensource.com >>>> http://lists.xensource.com/xen-users >>> >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Felix, What I was thinking of doing (And i''ll need to consult with my php/java folk here to get this working in a secure way), is to run Ajaxterm on the web server itself. When launch Ajaxterm, there is a -c option that allows you to specify a command. With an ssh key stored in the web server''s filesystem (Which only is allowed to preform global xm functions), I could do something like (The command would run locally on the web server): ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com -k /path/to/key xm console $vm_id Where $vm_id could be storaed in a database and would be the name of the DomU running What you think? ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 14:57 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, if you can do that, it''s good. But you''ll always need some kind of access to the Dom0 to get the console data and to reboot / reset / rescue the VMs (whatever you want to offer to your customers). Regards, Felix Am 18.06.2010 15:17, schrieb Jonathan Tripathy: Hi Felix, Probably the main reason why I want to use a web console is so that I can run the web server on a different machine (Or maybe in a VM connected to an isolated network). Thanks for the tip on the Grub password for the Dom0. That''s scary about the KVM! Thanks Jonathan ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 14:13 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, the Dom0 cannot be compromised as long as your SSH or web-based console does not have any security leaks. PHP sessions are not as secure as SSH, but with SSL and suhosin patched PHP considerably OK. As I said, I don''t use web-based consoles so I can''t help you there, but I''d *really* consider whether it is a good thing to setup a webserver on a Dom0 and it may be probably hard to do web-based consoles without that. Regards, Felix P.S. Anyway, considering the method I posted, you should always setup GRUB and BIOS passwords for all of your Dom0s. I once requested KVM access at my provider and ended up at the wrong server... Am 18.06.2010 15:03, schrieb Jonathan Tripathy: Hi Felix, I actually have that guy''s book who wrote that article - The book of Xen - very good book indeed! What I really wish to do, is provide a similar sort of thing to that SSH setup, except allow it to be accessed via a web browser. I have an idea where I can use ajaxterm and some PHP scripting. Once a user logs on with a username and password, I could tell php to start ajaxterm and piple xm console through it. This is what Slicehost does I think. The console would be protected with php sessions. But my main worry was whether or not the Dom0 could be compramised via the above method, but I don''t think that''s the case. Thanks Jonathan ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 13:50 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy: Hi Felix, Thanks for the email. >a simple init=/bin/bash added to the kernel command line allows resetting the root password... ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, I think this is a great idea: The Domain-0 has full SSH-security (can be limited to your webserver''s internal ip address for further security) and the webserver is not running on Dom0. You could combine this approaches: SSH on Dom0, with RSA authentification and (for example) sudo-wrapped xm console, accessed by your ajaxterm software. It would be even possible to provide both methods to your customers, if the SSH daemon is secured enough, or just allow that web console. When the web console is secure enough, this will not expose any security threats to your customers, and it would never be a threat to your Dom0s. You''ll need to ask the ajaxterm developers, I only know that many PHP session ids are *not* safely generated and ajax can even extend that problem (on the other hand, suhosin fixes that problem). SSH''s HMAC-method is more safe, but many applications rely on PHP''s safety (some of them without being hacked), so it would offer enough security if the application has no big security issues. Regards, Felix Am 18.06.2010 16:09, schrieb Jonathan Tripathy:> Hi Felix, > > What I was thinking of doing (And i''ll need to consult with my > php/java folk here to get this working in a secure way), is to run > Ajaxterm on the web server itself. When launch Ajaxterm, there is a -c > option that allows you to specify a command. With an ssh key stored in > the web server''s filesystem (Which only is allowed to preform global > xm functions), I could do something like (The command would run > locally on the web server): > > ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com > <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console $vm_id > > Where $vm_id could be storaed in a database and would be the name of > the DomU running > > What you think? > > ------------------------------------------------------------------------ > *From:* xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans > *Sent:* Fri 18/06/2010 14:57 > *To:* xen-users@lists.xensource.com > *Subject:* Re: [Xen-users] Web Console Access > > Hi Jonathan, > > if you can do that, it''s good. But you''ll always need some kind of > access to the Dom0 to get the console data and to reboot / reset / > rescue the VMs (whatever you want to offer to your customers). > > Regards, > Felix > > Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >> Hi Felix, >> >> Probably the main reason why I want to use a web console is so that I >> can run the web server on a different machine (Or maybe in a VM >> connected to an isolated network). >> >> Thanks for the tip on the Grub password for the Dom0. That''s scary >> about the KVM! >> >> Thanks >> >> Jonathan >> >> ------------------------------------------------------------------------ >> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >> *Sent:* Fri 18/06/2010 14:13 >> *To:* Jonathan Tripathy >> *Cc:* xen-users@lists.xensource.com >> *Subject:* Re: [Xen-users] Web Console Access >> >> Hi Jonathan, >> >> the Dom0 cannot be compromised as long as your SSH or web-based >> console does not have any security leaks. >> PHP sessions are not as secure as SSH, but with SSL and suhosin >> patched PHP considerably OK. >> >> As I said, I don''t use web-based consoles so I can''t help you there, >> but I''d *really* consider whether it is a good thing to setup a >> webserver on a Dom0 and it may be probably hard to do web-based >> consoles without that. >> >> Regards, >> Felix >> >> P.S. Anyway, considering the method I posted, you should always setup >> GRUB and BIOS passwords for all of your Dom0s. I once requested KVM >> access at my provider and ended up at the wrong server... >> >> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>> Hi Felix, >>> >>> I actually have that guy''s book who wrote that article - The book of >>> Xen - very good book indeed! >>> >>> What I really wish to do, is provide a similar sort of thing to that >>> SSH setup, except allow it to be accessed via a web browser. I have >>> an idea where I can use ajaxterm and some PHP scripting. Once a user >>> logs on with a username and password, I could tell php to start >>> ajaxterm and piple xm console through it. This is what Slicehost >>> does I think. The console would be protected with php sessions. >>> >>> But my main worry was whether or not the Dom0 could be compramised >>> via the above method, but I don''t think that''s the case. >>> >>> Thanks >>> >>> Jonathan >>> ------------------------------------------------------------------------ >>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>> Kuperjans >>> *Sent:* Fri 18/06/2010 13:50 >>> *To:* xen-users@lists.xensource.com >>> *Subject:* Re: [Xen-users] Web Console Access >>> >>> Hi Jonathan, >>> >>> this is a common way to reset lost / forgotton root passwords: >>> >>> You need: >>> - Physical access to a machine (if you want to reset the password of >>> the Dom0 or a native linux) or console access to a DomU >>> - Access to the kernel command line, via lilo, grub or pygrub/pvgrub >>> in XEN >>> >>> Then you do: >>> - Modify the kernel command line, add the init=/bin/bash option, for >>> example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash >>> - You''ll directly end up in a root console without password or any >>> services started after the kernel booted >>> - enter those commands: >>> mount -o remount,rw / >>> passwd root >>> <enter new password> >>> exec /sbin/init >>> >>> The root password will then be the newly set one. >>> >>> DomUs generally are not vulnerable to this method, as long as the >>> kernel command line is set in the domain configuration. But >>> pygrub/pvgrub is a nice thing for hosting customers, because they >>> can compile their own kernels, containing their preferred settings, >>> modules and builtin functionality. Generally this problem is avoided >>> by adding a password to grub, but some customers may forget that step. >>> So physical access can always be a strong weapon, but it is >>> necessary for repairing a machine or for some advanced setups >>> (especially when setting up a firewall, one easily gets locked out >>> of the server...). I think the best way is securing this access, by >>> restricting virtual console access to highly encrypted and >>> authenticated sessions (IMHO the best way is SSH here). >>> >>> I''d also think about customers forgetting to log out, because >>> leaving xm console does *not* logout root inside the console. >>> >>> The tutorial I posted to your I/O question contains a SSH-based >>> setup for xm console access with sudo, which may be nice to start >>> with. I personally use an own wrapper inside a chroot jail, to >>> provide the ability of entering commands like create / rescue / >>> setup (rescue starts another domain configuration with NFS root + >>> rescue-Kernel, setup starts a virtual Debian setup). It''s quite >>> handy for VPS customers. >>> >>> Regards, >>> Felix >>> >>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>> >>>> Hi Felix, >>>> >>>> Thanks for the email. >>>> >>>> >a simple init=/bin/bash added to the kernel command line allows >>>> resetting the root password... >>>> ok this worries me. Can you please explain this a little further? >>>> Do you need to have access to the Dom0 to begin with? >>>> >>>> Thanks >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>> Kuperjans >>>> *Sent:* Fri 18/06/2010 12:54 >>>> *To:* xen-users@lists.xensource.com >>>> *Subject:* Re: [Xen-users] Web Console Access >>>> >>>> Hi Jonathan, >>>> >>>> do you definitely need a web console (so really browser-based) or >>>> would you consider a SSH-based console? >>>> >>>> I personally prefer SSH because it is more secure, easier to set up >>>> and it is somehow the default way of accessing remote consoles. You >>>> can do a modified SSH setup that only allows access to the console, >>>> or optionally, access to xm console, xm list, xm shutdown, xm >>>> create but restricted to the own VM of your customer. With >>>> chroot-jails etc., other commands cannot be executed. >>>> SSH also has the advantage of good copy & paste of larger commands, >>>> and the possibility to work with multiple client certificates and / >>>> or passwords. Probably your administrative interface allows >>>> uploading of multiple public keys, so that your customers can have >>>> multiple adminsitrative accounts for the server (but only one can >>>> access the console at a time). >>>> >>>> I''ve got no experiences with ajaxterm, but you should really >>>> control its security: >>>> Console access is quite useful for hackers, e.g. some customer may >>>> forget to log out root or if you use pvgrub / pygrub, a simple >>>> init=/bin/bash added to the kernel command line allows resetting >>>> the root password... >>>> So it must be a really secure application, not vulnerable to XSS, >>>> SQL Injections, Connection hijacking, ... and SSL encrypted. >>>> >>>> Regards, >>>> Felix Kuperjans >>>> >>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>> Hi Everyone, >>>>> >>>>> Does anyone have any idea on how to give my customers a "web >>>>> console" for their VMs? >>>>> >>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can manually >>>>> set up a remote session for them, by doing >>>>> ajaxterm.py -c xm console <DOMNAME> >>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>> >>>>> Thanks >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-users mailing list >>>>> Xen-users@lists.xensource.com >>>>> http://lists.xensource.com/xen-users >>>> >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xensource.com >>>> http://lists.xensource.com/xen-users >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks Felix, Glad you like my idea. Since ajaxterm runs its own web server (and you can specify the port is listens on, which would be one per customer), I think it''s just a matter of using php to control access to this resource. Another, easier way, would be to just use Apache''s .htaccess stuff (No sessions required). Just protect one directory per user, and in each directory simply have an index.php that runs the correct ajaxterm command for the user. Then Apache could use it''s reverse proxy mechanism to give the user access to ajax term. The "logical" address of the ajax term would be a child of the inital htaccess protected directory. This isn''t as nice and doesn''t scale well, but I''m pretty sure it would work.. ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 15:25 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, I think this is a great idea: The Domain-0 has full SSH-security (can be limited to your webserver''s internal ip address for further security) and the webserver is not running on Dom0. You could combine this approaches: SSH on Dom0, with RSA authentification and (for example) sudo-wrapped xm console, accessed by your ajaxterm software. It would be even possible to provide both methods to your customers, if the SSH daemon is secured enough, or just allow that web console. When the web console is secure enough, this will not expose any security threats to your customers, and it would never be a threat to your Dom0s. You''ll need to ask the ajaxterm developers, I only know that many PHP session ids are *not* safely generated and ajax can even extend that problem (on the other hand, suhosin fixes that problem). SSH''s HMAC-method is more safe, but many applications rely on PHP''s safety (some of them without being hacked), so it would offer enough security if the application has no big security issues. Regards, Felix Am 18.06.2010 16:09, schrieb Jonathan Tripathy: Hi Felix, What I was thinking of doing (And i''ll need to consult with my php/java folk here to get this working in a secure way), is to run Ajaxterm on the web server itself. When launch Ajaxterm, there is a -c option that allows you to specify a command. With an ssh key stored in the web server''s filesystem (Which only is allowed to preform global xm functions), I could do something like (The command would run locally on the web server): ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com -k /path/to/key xm console $vm_id Where $vm_id could be storaed in a database and would be the name of the DomU running What you think? ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 14:57 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, if you can do that, it''s good. But you''ll always need some kind of access to the Dom0 to get the console data and to reboot / reset / rescue the VMs (whatever you want to offer to your customers). Regards, Felix Am 18.06.2010 15:17, schrieb Jonathan Tripathy: Hi Felix, Probably the main reason why I want to use a web console is so that I can run the web server on a different machine (Or maybe in a VM connected to an isolated network). Thanks for the tip on the Grub password for the Dom0. That''s scary about the KVM! Thanks Jonathan ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 14:13 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, the Dom0 cannot be compromised as long as your SSH or web-based console does not have any security leaks. PHP sessions are not as secure as SSH, but with SSL and suhosin patched PHP considerably OK. As I said, I don''t use web-based consoles so I can''t help you there, but I''d *really* consider whether it is a good thing to setup a webserver on a Dom0 and it may be probably hard to do web-based consoles without that. Regards, Felix P.S. Anyway, considering the method I posted, you should always setup GRUB and BIOS passwords for all of your Dom0s. I once requested KVM access at my provider and ended up at the wrong server... Am 18.06.2010 15:03, schrieb Jonathan Tripathy: Hi Felix, I actually have that guy''s book who wrote that article - The book of Xen - very good book indeed! What I really wish to do, is provide a similar sort of thing to that SSH setup, except allow it to be accessed via a web browser. I have an idea where I can use ajaxterm and some PHP scripting. Once a user logs on with a username and password, I could tell php to start ajaxterm and piple xm console through it. This is what Slicehost does I think. The console would be protected with php sessions. But my main worry was whether or not the Dom0 could be compramised via the above method, but I don''t think that''s the case. Thanks Jonathan ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 13:50 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy: Hi Felix, Thanks for the email. >a simple init=/bin/bash added to the kernel command line allows resetting the root password... ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
My main security concern would be rather: If I were your customer, I would want that my VM''s console is completely secured. But just relying on PHP sessions or HTTP-auth is not really secure, e.g.: http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html A hacker could abuse such insecure mechanisms of PHP to enter the session with a well-guessed session-id. PHP Auth resends all login credentials every time a request is made, and so there is no real session, which makes attacks sometimes easier. Of course, the security of those applications can be improved (especially with suhosin), but webservers and web-frontends are the primary hacking target (and very often subject to vulnerabilities). I wouldn''t doubt that it will *work* with that method, but having it in a secure way will be harder (but still possible). Probably you should consider using an own session mechanism, but this will require an advanced and security-aware PHP programmer. /dev/random (or if necessary /dev/urandom) should definitely be used for gaining the entropy for the session id and it should be long enough and further secured by ip address. And remember to do that all on a SSL-only connection, using that without SSL would allow anyone to do MITM attacks to capture the password / session id. Regards, Felix Am 18.06.2010 16:30, schrieb Jonathan Tripathy:> > Thanks Felix, > > Glad you like my idea. Since ajaxterm runs its own web server (and you > can specify the port is listens on, which would be one per customer), > I think it''s just a matter of using php to control access to this > resource. > > Another, easier way, would be to just use Apache''s .htaccess stuff (No > sessions required). Just protect one directory per user, and in each > directory simply have an index.php that runs the correct ajaxterm > command for the user. Then Apache could use it''s reverse proxy > mechanism to give the user access to ajax term. The "logical" address > of the ajax term would be a child of the inital htaccess protected > directory. This isn''t as nice and doesn''t scale well, but I''m pretty > sure it would work.. > > ------------------------------------------------------------------------ > *From:* Felix Kuperjans [mailto:felix@desaster-games.com] > *Sent:* Fri 18/06/2010 15:25 > *To:* Jonathan Tripathy > *Cc:* xen-users@lists.xensource.com > *Subject:* Re: [Xen-users] Web Console Access > > Hi Jonathan, > > I think this is a great idea: The Domain-0 has full SSH-security (can > be limited to your webserver''s internal ip address for further > security) and the webserver is not running on Dom0. > You could combine this approaches: > SSH on Dom0, with RSA authentification and (for example) sudo-wrapped > xm console, accessed by your ajaxterm software. It would be even > possible to provide both methods to your customers, if the SSH daemon > is secured enough, or just allow that web console. When the web > console is secure enough, this will not expose any security threats to > your customers, and it would never be a threat to your Dom0s. You''ll > need to ask the ajaxterm developers, I only know that many PHP session > ids are *not* safely generated and ajax can even extend that problem > (on the other hand, suhosin fixes that problem). SSH''s HMAC-method is > more safe, but many applications rely on PHP''s safety (some of them > without being hacked), so it would offer enough security if the > application has no big security issues. > > Regards, > Felix > > Am 18.06.2010 16:09, schrieb Jonathan Tripathy: >> Hi Felix, >> >> What I was thinking of doing (And i''ll need to consult with my >> php/java folk here to get this working in a secure way), is to run >> Ajaxterm on the web server itself. When launch Ajaxterm, there is a >> -c option that allows you to specify a command. With an ssh key >> stored in the web server''s filesystem (Which only is allowed to >> preform global xm functions), I could do something like (The command >> would run locally on the web server): >> >> ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com >> <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console $vm_id >> >> Where $vm_id could be storaed in a database and would be the name of >> the DomU running >> >> What you think? >> >> ------------------------------------------------------------------------ >> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >> Kuperjans >> *Sent:* Fri 18/06/2010 14:57 >> *To:* xen-users@lists.xensource.com >> *Subject:* Re: [Xen-users] Web Console Access >> >> Hi Jonathan, >> >> if you can do that, it''s good. But you''ll always need some kind of >> access to the Dom0 to get the console data and to reboot / reset / >> rescue the VMs (whatever you want to offer to your customers). >> >> Regards, >> Felix >> >> Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >>> Hi Felix, >>> >>> Probably the main reason why I want to use a web console is so that >>> I can run the web server on a different machine (Or maybe in a VM >>> connected to an isolated network). >>> >>> Thanks for the tip on the Grub password for the Dom0. That''s scary >>> about the KVM! >>> >>> Thanks >>> >>> Jonathan >>> >>> ------------------------------------------------------------------------ >>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>> *Sent:* Fri 18/06/2010 14:13 >>> *To:* Jonathan Tripathy >>> *Cc:* xen-users@lists.xensource.com >>> *Subject:* Re: [Xen-users] Web Console Access >>> >>> Hi Jonathan, >>> >>> the Dom0 cannot be compromised as long as your SSH or web-based >>> console does not have any security leaks. >>> PHP sessions are not as secure as SSH, but with SSL and suhosin >>> patched PHP considerably OK. >>> >>> As I said, I don''t use web-based consoles so I can''t help you there, >>> but I''d *really* consider whether it is a good thing to setup a >>> webserver on a Dom0 and it may be probably hard to do web-based >>> consoles without that. >>> >>> Regards, >>> Felix >>> >>> P.S. Anyway, considering the method I posted, you should always >>> setup GRUB and BIOS passwords for all of your Dom0s. I once >>> requested KVM access at my provider and ended up at the wrong server... >>> >>> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>>> Hi Felix, >>>> >>>> I actually have that guy''s book who wrote that article - The book >>>> of Xen - very good book indeed! >>>> >>>> What I really wish to do, is provide a similar sort of thing to >>>> that SSH setup, except allow it to be accessed via a web browser. I >>>> have an idea where I can use ajaxterm and some PHP scripting. Once >>>> a user logs on with a username and password, I could tell php to >>>> start ajaxterm and piple xm console through it. This is what >>>> Slicehost does I think. The console would be protected with php >>>> sessions. >>>> >>>> But my main worry was whether or not the Dom0 could be compramised >>>> via the above method, but I don''t think that''s the case. >>>> >>>> Thanks >>>> >>>> Jonathan >>>> ------------------------------------------------------------------------ >>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>> Kuperjans >>>> *Sent:* Fri 18/06/2010 13:50 >>>> *To:* xen-users@lists.xensource.com >>>> *Subject:* Re: [Xen-users] Web Console Access >>>> >>>> Hi Jonathan, >>>> >>>> this is a common way to reset lost / forgotton root passwords: >>>> >>>> You need: >>>> - Physical access to a machine (if you want to reset the password >>>> of the Dom0 or a native linux) or console access to a DomU >>>> - Access to the kernel command line, via lilo, grub or >>>> pygrub/pvgrub in XEN >>>> >>>> Then you do: >>>> - Modify the kernel command line, add the init=/bin/bash option, >>>> for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash >>>> - You''ll directly end up in a root console without password or any >>>> services started after the kernel booted >>>> - enter those commands: >>>> mount -o remount,rw / >>>> passwd root >>>> <enter new password> >>>> exec /sbin/init >>>> >>>> The root password will then be the newly set one. >>>> >>>> DomUs generally are not vulnerable to this method, as long as the >>>> kernel command line is set in the domain configuration. But >>>> pygrub/pvgrub is a nice thing for hosting customers, because they >>>> can compile their own kernels, containing their preferred settings, >>>> modules and builtin functionality. Generally this problem is >>>> avoided by adding a password to grub, but some customers may forget >>>> that step. >>>> So physical access can always be a strong weapon, but it is >>>> necessary for repairing a machine or for some advanced setups >>>> (especially when setting up a firewall, one easily gets locked out >>>> of the server...). I think the best way is securing this access, by >>>> restricting virtual console access to highly encrypted and >>>> authenticated sessions (IMHO the best way is SSH here). >>>> >>>> I''d also think about customers forgetting to log out, because >>>> leaving xm console does *not* logout root inside the console. >>>> >>>> The tutorial I posted to your I/O question contains a SSH-based >>>> setup for xm console access with sudo, which may be nice to start >>>> with. I personally use an own wrapper inside a chroot jail, to >>>> provide the ability of entering commands like create / rescue / >>>> setup (rescue starts another domain configuration with NFS root + >>>> rescue-Kernel, setup starts a virtual Debian setup). It''s quite >>>> handy for VPS customers. >>>> >>>> Regards, >>>> Felix >>>> >>>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>>> >>>>> Hi Felix, >>>>> >>>>> Thanks for the email. >>>>> >>>>> >a simple init=/bin/bash added to the kernel command line allows >>>>> resetting the root password... >>>>> ok this worries me. Can you please explain this a little further? >>>>> Do you need to have access to the Dom0 to begin with? >>>>> >>>>> Thanks >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>> Kuperjans >>>>> *Sent:* Fri 18/06/2010 12:54 >>>>> *To:* xen-users@lists.xensource.com >>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>> >>>>> Hi Jonathan, >>>>> >>>>> do you definitely need a web console (so really browser-based) or >>>>> would you consider a SSH-based console? >>>>> >>>>> I personally prefer SSH because it is more secure, easier to set >>>>> up and it is somehow the default way of accessing remote consoles. >>>>> You can do a modified SSH setup that only allows access to the >>>>> console, or optionally, access to xm console, xm list, xm >>>>> shutdown, xm create but restricted to the own VM of your customer. >>>>> With chroot-jails etc., other commands cannot be executed. >>>>> SSH also has the advantage of good copy & paste of larger >>>>> commands, and the possibility to work with multiple client >>>>> certificates and / or passwords. Probably your administrative >>>>> interface allows uploading of multiple public keys, so that your >>>>> customers can have multiple adminsitrative accounts for the server >>>>> (but only one can access the console at a time). >>>>> >>>>> I''ve got no experiences with ajaxterm, but you should really >>>>> control its security: >>>>> Console access is quite useful for hackers, e.g. some customer may >>>>> forget to log out root or if you use pvgrub / pygrub, a simple >>>>> init=/bin/bash added to the kernel command line allows resetting >>>>> the root password... >>>>> So it must be a really secure application, not vulnerable to XSS, >>>>> SQL Injections, Connection hijacking, ... and SSL encrypted. >>>>> >>>>> Regards, >>>>> Felix Kuperjans >>>>> >>>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>>> Hi Everyone, >>>>>> >>>>>> Does anyone have any idea on how to give my customers a "web >>>>>> console" for their VMs? >>>>>> >>>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can >>>>>> manually set up a remote session for them, by doing >>>>>> ajaxterm.py -c xm console <DOMNAME> >>>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-users mailing list >>>>>> Xen-users@lists.xensource.com >>>>>> http://lists.xensource.com/xen-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-users mailing list >>>>> Xen-users@lists.xensource.com >>>>> http://lists.xensource.com/xen-users >>> >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xensource.com >>> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks Felix. What you think of the Apache htaccess method? Thanks ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 15:54 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access My main security concern would be rather: If I were your customer, I would want that my VM''s console is completely secured. But just relying on PHP sessions or HTTP-auth is not really secure, e.g.: http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html A hacker could abuse such insecure mechanisms of PHP to enter the session with a well-guessed session-id. PHP Auth resends all login credentials every time a request is made, and so there is no real session, which makes attacks sometimes easier. Of course, the security of those applications can be improved (especially with suhosin), but webservers and web-frontends are the primary hacking target (and very often subject to vulnerabilities). I wouldn''t doubt that it will *work* with that method, but having it in a secure way will be harder (but still possible). Probably you should consider using an own session mechanism, but this will require an advanced and security-aware PHP programmer. /dev/random (or if necessary /dev/urandom) should definitely be used for gaining the entropy for the session id and it should be long enough and further secured by ip address. And remember to do that all on a SSL-only connection, using that without SSL would allow anyone to do MITM attacks to capture the password / session id. Regards, Felix Am 18.06.2010 16:30, schrieb Jonathan Tripathy: Thanks Felix, Glad you like my idea. Since ajaxterm runs its own web server (and you can specify the port is listens on, which would be one per customer), I think it''s just a matter of using php to control access to this resource. Another, easier way, would be to just use Apache''s .htaccess stuff (No sessions required). Just protect one directory per user, and in each directory simply have an index.php that runs the correct ajaxterm command for the user. Then Apache could use it''s reverse proxy mechanism to give the user access to ajax term. The "logical" address of the ajax term would be a child of the inital htaccess protected directory. This isn''t as nice and doesn''t scale well, but I''m pretty sure it would work.. ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 15:25 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, I think this is a great idea: The Domain-0 has full SSH-security (can be limited to your webserver''s internal ip address for further security) and the webserver is not running on Dom0. You could combine this approaches: SSH on Dom0, with RSA authentification and (for example) sudo-wrapped xm console, accessed by your ajaxterm software. It would be even possible to provide both methods to your customers, if the SSH daemon is secured enough, or just allow that web console. When the web console is secure enough, this will not expose any security threats to your customers, and it would never be a threat to your Dom0s. You''ll need to ask the ajaxterm developers, I only know that many PHP session ids are *not* safely generated and ajax can even extend that problem (on the other hand, suhosin fixes that problem). SSH''s HMAC-method is more safe, but many applications rely on PHP''s safety (some of them without being hacked), so it would offer enough security if the application has no big security issues. Regards, Felix Am 18.06.2010 16:09, schrieb Jonathan Tripathy: Hi Felix, What I was thinking of doing (And i''ll need to consult with my php/java folk here to get this working in a secure way), is to run Ajaxterm on the web server itself. When launch Ajaxterm, there is a -c option that allows you to specify a command. With an ssh key stored in the web server''s filesystem (Which only is allowed to preform global xm functions), I could do something like (The command would run locally on the web server): ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com -k /path/to/key xm console $vm_id Where $vm_id could be storaed in a database and would be the name of the DomU running What you think? ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 14:57 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, if you can do that, it''s good. But you''ll always need some kind of access to the Dom0 to get the console data and to reboot / reset / rescue the VMs (whatever you want to offer to your customers). Regards, Felix Am 18.06.2010 15:17, schrieb Jonathan Tripathy: Hi Felix, Probably the main reason why I want to use a web console is so that I can run the web server on a different machine (Or maybe in a VM connected to an isolated network). Thanks for the tip on the Grub password for the Dom0. That''s scary about the KVM! Thanks Jonathan ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 14:13 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, the Dom0 cannot be compromised as long as your SSH or web-based console does not have any security leaks. PHP sessions are not as secure as SSH, but with SSL and suhosin patched PHP considerably OK. As I said, I don''t use web-based consoles so I can''t help you there, but I''d *really* consider whether it is a good thing to setup a webserver on a Dom0 and it may be probably hard to do web-based consoles without that. Regards, Felix P.S. Anyway, considering the method I posted, you should always setup GRUB and BIOS passwords for all of your Dom0s. I once requested KVM access at my provider and ended up at the wrong server... Am 18.06.2010 15:03, schrieb Jonathan Tripathy: Hi Felix, I actually have that guy''s book who wrote that article - The book of Xen - very good book indeed! What I really wish to do, is provide a similar sort of thing to that SSH setup, except allow it to be accessed via a web browser. I have an idea where I can use ajaxterm and some PHP scripting. Once a user logs on with a username and password, I could tell php to start ajaxterm and piple xm console through it. This is what Slicehost does I think. The console would be protected with php sessions. But my main worry was whether or not the Dom0 could be compramised via the above method, but I don''t think that''s the case. Thanks Jonathan ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 13:50 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy: Hi Felix, Thanks for the email. >a simple init=/bin/bash added to the kernel command line allows resetting the root password... ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hm I don''t know of an actual hack when the session is SSL encrypted, but it''s not a good practise to send the login credentials every time although they are encrypted. Safe session ids, are better because there is one login with the password and the ''password'' for further requests is the session id (which must be at least as safe then, preferably even safer), combined with a three tries for the password mechanism or something similar. Best method are HMAC''s, but as far as I know, this is not available on PHP, but the default for SSH or OpenVPN connections. suhosin adds many security improvements to PHP (even to the default session mechanism) and I think it should be preferred over htaccess. Regards, Felix Am 18.06.2010 17:01, schrieb Jonathan Tripathy:> Thanks Felix. > > What you think of the Apache htaccess method? > > Thanks > > ------------------------------------------------------------------------ > *From:* Felix Kuperjans [mailto:felix@desaster-games.com] > *Sent:* Fri 18/06/2010 15:54 > *To:* Jonathan Tripathy > *Cc:* xen-users@lists.xensource.com > *Subject:* Re: [Xen-users] Web Console Access > > My main security concern would be rather: > If I were your customer, I would want that my VM''s console is > completely secured. But just relying on PHP sessions or HTTP-auth is > not really secure, e.g.: > > http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html > > A hacker could abuse such insecure mechanisms of PHP to enter the > session with a well-guessed session-id. PHP Auth resends all login > credentials every time a request is made, and so there is no real > session, which makes attacks sometimes easier. Of course, the security > of those applications can be improved (especially with suhosin), but > webservers and web-frontends are the primary hacking target (and very > often subject to vulnerabilities). > > I wouldn''t doubt that it will *work* with that method, but having it > in a secure way will be harder (but still possible). > > Probably you should consider using an own session mechanism, but this > will require an advanced and security-aware PHP programmer. > /dev/random (or if necessary /dev/urandom) should definitely be used > for gaining the entropy for the session id and it should be long > enough and further secured by ip address. And remember to do that all > on a SSL-only connection, using that without SSL would allow anyone to > do MITM attacks to capture the password / session id. > > Regards, > Felix > > Am 18.06.2010 16:30, schrieb Jonathan Tripathy: >> >> Thanks Felix, >> >> Glad you like my idea. Since ajaxterm runs its own web server (and >> you can specify the port is listens on, which would be one per >> customer), I think it''s just a matter of using php to control access >> to this resource. >> >> Another, easier way, would be to just use Apache''s .htaccess stuff >> (No sessions required). Just protect one directory per user, and in >> each directory simply have an index.php that runs the correct >> ajaxterm command for the user. Then Apache could use it''s reverse >> proxy mechanism to give the user access to ajax term. The "logical" >> address of the ajax term would be a child of the inital htaccess >> protected directory. This isn''t as nice and doesn''t scale well, but >> I''m pretty sure it would work.. >> >> ------------------------------------------------------------------------ >> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >> *Sent:* Fri 18/06/2010 15:25 >> *To:* Jonathan Tripathy >> *Cc:* xen-users@lists.xensource.com >> *Subject:* Re: [Xen-users] Web Console Access >> >> Hi Jonathan, >> >> I think this is a great idea: The Domain-0 has full SSH-security (can >> be limited to your webserver''s internal ip address for further >> security) and the webserver is not running on Dom0. >> You could combine this approaches: >> SSH on Dom0, with RSA authentification and (for example) sudo-wrapped >> xm console, accessed by your ajaxterm software. It would be even >> possible to provide both methods to your customers, if the SSH daemon >> is secured enough, or just allow that web console. When the web >> console is secure enough, this will not expose any security threats >> to your customers, and it would never be a threat to your Dom0s. >> You''ll need to ask the ajaxterm developers, I only know that many PHP >> session ids are *not* safely generated and ajax can even extend that >> problem (on the other hand, suhosin fixes that problem). SSH''s >> HMAC-method is more safe, but many applications rely on PHP''s safety >> (some of them without being hacked), so it would offer enough >> security if the application has no big security issues. >> >> Regards, >> Felix >> >> Am 18.06.2010 16:09, schrieb Jonathan Tripathy: >>> Hi Felix, >>> >>> What I was thinking of doing (And i''ll need to consult with my >>> php/java folk here to get this working in a secure way), is to run >>> Ajaxterm on the web server itself. When launch Ajaxterm, there is a >>> -c option that allows you to specify a command. With an ssh key >>> stored in the web server''s filesystem (Which only is allowed to >>> preform global xm functions), I could do something like (The command >>> would run locally on the web server): >>> >>> ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com >>> <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console $vm_id >>> >>> Where $vm_id could be storaed in a database and would be the name of >>> the DomU running >>> >>> What you think? >>> >>> ------------------------------------------------------------------------ >>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>> Kuperjans >>> *Sent:* Fri 18/06/2010 14:57 >>> *To:* xen-users@lists.xensource.com >>> *Subject:* Re: [Xen-users] Web Console Access >>> >>> Hi Jonathan, >>> >>> if you can do that, it''s good. But you''ll always need some kind of >>> access to the Dom0 to get the console data and to reboot / reset / >>> rescue the VMs (whatever you want to offer to your customers). >>> >>> Regards, >>> Felix >>> >>> Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >>>> Hi Felix, >>>> >>>> Probably the main reason why I want to use a web console is so that >>>> I can run the web server on a different machine (Or maybe in a VM >>>> connected to an isolated network). >>>> >>>> Thanks for the tip on the Grub password for the Dom0. That''s scary >>>> about the KVM! >>>> >>>> Thanks >>>> >>>> Jonathan >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>> *Sent:* Fri 18/06/2010 14:13 >>>> *To:* Jonathan Tripathy >>>> *Cc:* xen-users@lists.xensource.com >>>> *Subject:* Re: [Xen-users] Web Console Access >>>> >>>> Hi Jonathan, >>>> >>>> the Dom0 cannot be compromised as long as your SSH or web-based >>>> console does not have any security leaks. >>>> PHP sessions are not as secure as SSH, but with SSL and suhosin >>>> patched PHP considerably OK. >>>> >>>> As I said, I don''t use web-based consoles so I can''t help you >>>> there, but I''d *really* consider whether it is a good thing to >>>> setup a webserver on a Dom0 and it may be probably hard to do >>>> web-based consoles without that. >>>> >>>> Regards, >>>> Felix >>>> >>>> P.S. Anyway, considering the method I posted, you should always >>>> setup GRUB and BIOS passwords for all of your Dom0s. I once >>>> requested KVM access at my provider and ended up at the wrong server... >>>> >>>> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>>>> Hi Felix, >>>>> >>>>> I actually have that guy''s book who wrote that article - The book >>>>> of Xen - very good book indeed! >>>>> >>>>> What I really wish to do, is provide a similar sort of thing to >>>>> that SSH setup, except allow it to be accessed via a web browser. >>>>> I have an idea where I can use ajaxterm and some PHP scripting. >>>>> Once a user logs on with a username and password, I could tell php >>>>> to start ajaxterm and piple xm console through it. This is what >>>>> Slicehost does I think. The console would be protected with php >>>>> sessions. >>>>> >>>>> But my main worry was whether or not the Dom0 could be compramised >>>>> via the above method, but I don''t think that''s the case. >>>>> >>>>> Thanks >>>>> >>>>> Jonathan >>>>> ------------------------------------------------------------------------ >>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>> Kuperjans >>>>> *Sent:* Fri 18/06/2010 13:50 >>>>> *To:* xen-users@lists.xensource.com >>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>> >>>>> Hi Jonathan, >>>>> >>>>> this is a common way to reset lost / forgotton root passwords: >>>>> >>>>> You need: >>>>> - Physical access to a machine (if you want to reset the password >>>>> of the Dom0 or a native linux) or console access to a DomU >>>>> - Access to the kernel command line, via lilo, grub or >>>>> pygrub/pvgrub in XEN >>>>> >>>>> Then you do: >>>>> - Modify the kernel command line, add the init=/bin/bash option, >>>>> for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 >>>>> init=/bin/bash >>>>> - You''ll directly end up in a root console without password or any >>>>> services started after the kernel booted >>>>> - enter those commands: >>>>> mount -o remount,rw / >>>>> passwd root >>>>> <enter new password> >>>>> exec /sbin/init >>>>> >>>>> The root password will then be the newly set one. >>>>> >>>>> DomUs generally are not vulnerable to this method, as long as the >>>>> kernel command line is set in the domain configuration. But >>>>> pygrub/pvgrub is a nice thing for hosting customers, because they >>>>> can compile their own kernels, containing their preferred >>>>> settings, modules and builtin functionality. Generally this >>>>> problem is avoided by adding a password to grub, but some >>>>> customers may forget that step. >>>>> So physical access can always be a strong weapon, but it is >>>>> necessary for repairing a machine or for some advanced setups >>>>> (especially when setting up a firewall, one easily gets locked out >>>>> of the server...). I think the best way is securing this access, >>>>> by restricting virtual console access to highly encrypted and >>>>> authenticated sessions (IMHO the best way is SSH here). >>>>> >>>>> I''d also think about customers forgetting to log out, because >>>>> leaving xm console does *not* logout root inside the console. >>>>> >>>>> The tutorial I posted to your I/O question contains a SSH-based >>>>> setup for xm console access with sudo, which may be nice to start >>>>> with. I personally use an own wrapper inside a chroot jail, to >>>>> provide the ability of entering commands like create / rescue / >>>>> setup (rescue starts another domain configuration with NFS root + >>>>> rescue-Kernel, setup starts a virtual Debian setup). It''s quite >>>>> handy for VPS customers. >>>>> >>>>> Regards, >>>>> Felix >>>>> >>>>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>>>> >>>>>> Hi Felix, >>>>>> >>>>>> Thanks for the email. >>>>>> >>>>>> >a simple init=/bin/bash added to the kernel command line allows >>>>>> resetting the root password... >>>>>> ok this worries me. Can you please explain this a little further? >>>>>> Do you need to have access to the Dom0 to begin with? >>>>>> >>>>>> Thanks >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>>> Kuperjans >>>>>> *Sent:* Fri 18/06/2010 12:54 >>>>>> *To:* xen-users@lists.xensource.com >>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>> >>>>>> Hi Jonathan, >>>>>> >>>>>> do you definitely need a web console (so really browser-based) or >>>>>> would you consider a SSH-based console? >>>>>> >>>>>> I personally prefer SSH because it is more secure, easier to set >>>>>> up and it is somehow the default way of accessing remote >>>>>> consoles. You can do a modified SSH setup that only allows access >>>>>> to the console, or optionally, access to xm console, xm list, xm >>>>>> shutdown, xm create but restricted to the own VM of your >>>>>> customer. With chroot-jails etc., other commands cannot be executed. >>>>>> SSH also has the advantage of good copy & paste of larger >>>>>> commands, and the possibility to work with multiple client >>>>>> certificates and / or passwords. Probably your administrative >>>>>> interface allows uploading of multiple public keys, so that your >>>>>> customers can have multiple adminsitrative accounts for the >>>>>> server (but only one can access the console at a time). >>>>>> >>>>>> I''ve got no experiences with ajaxterm, but you should really >>>>>> control its security: >>>>>> Console access is quite useful for hackers, e.g. some customer >>>>>> may forget to log out root or if you use pvgrub / pygrub, a >>>>>> simple init=/bin/bash added to the kernel command line allows >>>>>> resetting the root password... >>>>>> So it must be a really secure application, not vulnerable to XSS, >>>>>> SQL Injections, Connection hijacking, ... and SSL encrypted. >>>>>> >>>>>> Regards, >>>>>> Felix Kuperjans >>>>>> >>>>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>>>> Hi Everyone, >>>>>>> >>>>>>> Does anyone have any idea on how to give my customers a "web >>>>>>> console" for their VMs? >>>>>>> >>>>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can >>>>>>> manually set up a remote session for them, by doing >>>>>>> ajaxterm.py -c xm console <DOMNAME> >>>>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xen-users mailing list >>>>>>> Xen-users@lists.xensource.com >>>>>>> http://lists.xensource.com/xen-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-users mailing list >>>>>> Xen-users@lists.xensource.com >>>>>> http://lists.xensource.com/xen-users >>>> >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xensource.com >>>> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thanks Felix, I know that Ubuntu Server installs php with Suhosin by default, so I should be good to go with that Thanks Jonny ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 16:11 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hm I don''t know of an actual hack when the session is SSL encrypted, but it''s not a good practise to send the login credentials every time although they are encrypted. Safe session ids, are better because there is one login with the password and the ''password'' for further requests is the session id (which must be at least as safe then, preferably even safer), combined with a three tries for the password mechanism or something similar. Best method are HMAC''s, but as far as I know, this is not available on PHP, but the default for SSH or OpenVPN connections. suhosin adds many security improvements to PHP (even to the default session mechanism) and I think it should be preferred over htaccess. Regards, Felix Am 18.06.2010 17:01, schrieb Jonathan Tripathy: Thanks Felix. What you think of the Apache htaccess method? Thanks ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 15:54 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access My main security concern would be rather: If I were your customer, I would want that my VM''s console is completely secured. But just relying on PHP sessions or HTTP-auth is not really secure, e.g.: http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html A hacker could abuse such insecure mechanisms of PHP to enter the session with a well-guessed session-id. PHP Auth resends all login credentials every time a request is made, and so there is no real session, which makes attacks sometimes easier. Of course, the security of those applications can be improved (especially with suhosin), but webservers and web-frontends are the primary hacking target (and very often subject to vulnerabilities). I wouldn''t doubt that it will *work* with that method, but having it in a secure way will be harder (but still possible). Probably you should consider using an own session mechanism, but this will require an advanced and security-aware PHP programmer. /dev/random (or if necessary /dev/urandom) should definitely be used for gaining the entropy for the session id and it should be long enough and further secured by ip address. And remember to do that all on a SSL-only connection, using that without SSL would allow anyone to do MITM attacks to capture the password / session id. Regards, Felix Am 18.06.2010 16:30, schrieb Jonathan Tripathy: Thanks Felix, Glad you like my idea. Since ajaxterm runs its own web server (and you can specify the port is listens on, which would be one per customer), I think it''s just a matter of using php to control access to this resource. Another, easier way, would be to just use Apache''s .htaccess stuff (No sessions required). Just protect one directory per user, and in each directory simply have an index.php that runs the correct ajaxterm command for the user. Then Apache could use it''s reverse proxy mechanism to give the user access to ajax term. The "logical" address of the ajax term would be a child of the inital htaccess protected directory. This isn''t as nice and doesn''t scale well, but I''m pretty sure it would work.. ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 15:25 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, I think this is a great idea: The Domain-0 has full SSH-security (can be limited to your webserver''s internal ip address for further security) and the webserver is not running on Dom0. You could combine this approaches: SSH on Dom0, with RSA authentification and (for example) sudo-wrapped xm console, accessed by your ajaxterm software. It would be even possible to provide both methods to your customers, if the SSH daemon is secured enough, or just allow that web console. When the web console is secure enough, this will not expose any security threats to your customers, and it would never be a threat to your Dom0s. You''ll need to ask the ajaxterm developers, I only know that many PHP session ids are *not* safely generated and ajax can even extend that problem (on the other hand, suhosin fixes that problem). SSH''s HMAC-method is more safe, but many applications rely on PHP''s safety (some of them without being hacked), so it would offer enough security if the application has no big security issues. Regards, Felix Am 18.06.2010 16:09, schrieb Jonathan Tripathy: Hi Felix, What I was thinking of doing (And i''ll need to consult with my php/java folk here to get this working in a secure way), is to run Ajaxterm on the web server itself. When launch Ajaxterm, there is a -c option that allows you to specify a command. With an ssh key stored in the web server''s filesystem (Which only is allowed to preform global xm functions), I could do something like (The command would run locally on the web server): ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com -k /path/to/key xm console $vm_id Where $vm_id could be storaed in a database and would be the name of the DomU running What you think? ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 14:57 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, if you can do that, it''s good. But you''ll always need some kind of access to the Dom0 to get the console data and to reboot / reset / rescue the VMs (whatever you want to offer to your customers). Regards, Felix Am 18.06.2010 15:17, schrieb Jonathan Tripathy: Hi Felix, Probably the main reason why I want to use a web console is so that I can run the web server on a different machine (Or maybe in a VM connected to an isolated network). Thanks for the tip on the Grub password for the Dom0. That''s scary about the KVM! Thanks Jonathan ________________________________ From: Felix Kuperjans [mailto:felix@desaster-games.com] Sent: Fri 18/06/2010 14:13 To: Jonathan Tripathy Cc: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, the Dom0 cannot be compromised as long as your SSH or web-based console does not have any security leaks. PHP sessions are not as secure as SSH, but with SSL and suhosin patched PHP considerably OK. As I said, I don''t use web-based consoles so I can''t help you there, but I''d *really* consider whether it is a good thing to setup a webserver on a Dom0 and it may be probably hard to do web-based consoles without that. Regards, Felix P.S. Anyway, considering the method I posted, you should always setup GRUB and BIOS passwords for all of your Dom0s. I once requested KVM access at my provider and ended up at the wrong server... Am 18.06.2010 15:03, schrieb Jonathan Tripathy: Hi Felix, I actually have that guy''s book who wrote that article - The book of Xen - very good book indeed! What I really wish to do, is provide a similar sort of thing to that SSH setup, except allow it to be accessed via a web browser. I have an idea where I can use ajaxterm and some PHP scripting. Once a user logs on with a username and password, I could tell php to start ajaxterm and piple xm console through it. This is what Slicehost does I think. The console would be protected with php sessions. But my main worry was whether or not the Dom0 could be compramised via the above method, but I don''t think that''s the case. Thanks Jonathan ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 13:50 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, this is a common way to reset lost / forgotton root passwords: You need: - Physical access to a machine (if you want to reset the password of the Dom0 or a native linux) or console access to a DomU - Access to the kernel command line, via lilo, grub or pygrub/pvgrub in XEN Then you do: - Modify the kernel command line, add the init=/bin/bash option, for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 init=/bin/bash - You''ll directly end up in a root console without password or any services started after the kernel booted - enter those commands: mount -o remount,rw / passwd root <enter new password> exec /sbin/init The root password will then be the newly set one. DomUs generally are not vulnerable to this method, as long as the kernel command line is set in the domain configuration. But pygrub/pvgrub is a nice thing for hosting customers, because they can compile their own kernels, containing their preferred settings, modules and builtin functionality. Generally this problem is avoided by adding a password to grub, but some customers may forget that step. So physical access can always be a strong weapon, but it is necessary for repairing a machine or for some advanced setups (especially when setting up a firewall, one easily gets locked out of the server...). I think the best way is securing this access, by restricting virtual console access to highly encrypted and authenticated sessions (IMHO the best way is SSH here). I''d also think about customers forgetting to log out, because leaving xm console does *not* logout root inside the console. The tutorial I posted to your I/O question contains a SSH-based setup for xm console access with sudo, which may be nice to start with. I personally use an own wrapper inside a chroot jail, to provide the ability of entering commands like create / rescue / setup (rescue starts another domain configuration with NFS root + rescue-Kernel, setup starts a virtual Debian setup). It''s quite handy for VPS customers. Regards, Felix Am 18.06.2010 14:26, schrieb Jonathan Tripathy: Hi Felix, Thanks for the email. >a simple init=/bin/bash added to the kernel command line allows resetting the root password... ok this worries me. Can you please explain this a little further? Do you need to have access to the Dom0 to begin with? Thanks ________________________________ From: xen-users-bounces@lists.xensource.com on behalf of Felix Kuperjans Sent: Fri 18/06/2010 12:54 To: xen-users@lists.xensource.com Subject: Re: [Xen-users] Web Console Access Hi Jonathan, do you definitely need a web console (so really browser-based) or would you consider a SSH-based console? I personally prefer SSH because it is more secure, easier to set up and it is somehow the default way of accessing remote consoles. You can do a modified SSH setup that only allows access to the console, or optionally, access to xm console, xm list, xm shutdown, xm create but restricted to the own VM of your customer. With chroot-jails etc., other commands cannot be executed. SSH also has the advantage of good copy & paste of larger commands, and the possibility to work with multiple client certificates and / or passwords. Probably your administrative interface allows uploading of multiple public keys, so that your customers can have multiple adminsitrative accounts for the server (but only one can access the console at a time). I''ve got no experiences with ajaxterm, but you should really control its security: Console access is quite useful for hackers, e.g. some customer may forget to log out root or if you use pvgrub / pygrub, a simple init=/bin/bash added to the kernel command line allows resetting the root password... So it must be a really secure application, not vulnerable to XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. Regards, Felix Kuperjans Am 18.06.2010 13:02, schrieb Jonathan Tripathy: Hi Everyone, Does anyone have any idea on how to give my customers a "web console" for their VMs? Using http://antony.lesuisse.org/software/ajaxterm/ I can manually set up a remote session for them, by doing ajaxterm.py -c xm console <DOMNAME> However is there any way to make this automatic? Maybe I could put it in the vif script? Thanks _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Felix, I have another idea to maybe make it easier to implement: Instead of running Ajaxterm locally on the web server, I could run it on the xen host itself. Inside the vif script, everytime the VM starts up, I could put in a line that starts ajaxterm and binds it to a port which is specific to that user. Then, I could use iptables to make sure that the only machine which has access to this port is the web server. Then on the web server, php could handle all the authentication, and then "proxy" the ajaxterm output from the xen host to the user. No ssh keys required! Pros: Easy to start/stop ajaxterm by using the vif scripts Easy to firewall (just use iptables) Cons: Lots of ajaxterms will be launched (1 per vm), so the xen host may not handle this very well The web server will need to use ssh anyway for startup/shutdown/restart of VMs What you think? Thanks On 18/06/10 16:11, Felix Kuperjans wrote:> Hm I don''t know of an actual hack when the session is SSL encrypted, > but it''s not a good practise to send the login credentials every time > although they are encrypted. > Safe session ids, are better because there is one login with the > password and the ''password'' for further requests is the session id > (which must be at least as safe then, preferably even safer), combined > with a three tries for the password mechanism or something similar. > Best method are HMAC''s, but as far as I know, this is not available on > PHP, but the default for SSH or OpenVPN connections. > > suhosin adds many security improvements to PHP (even to the default > session mechanism) and I think it should be preferred over htaccess. > > Regards, > Felix > > Am 18.06.2010 17:01, schrieb Jonathan Tripathy: >> Thanks Felix. >> What you think of the Apache htaccess method? >> Thanks >> >> ------------------------------------------------------------------------ >> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >> *Sent:* Fri 18/06/2010 15:54 >> *To:* Jonathan Tripathy >> *Cc:* xen-users@lists.xensource.com >> *Subject:* Re: [Xen-users] Web Console Access >> >> My main security concern would be rather: >> If I were your customer, I would want that my VM''s console is >> completely secured. But just relying on PHP sessions or HTTP-auth is >> not really secure, e.g.: >> >> http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html >> >> A hacker could abuse such insecure mechanisms of PHP to enter the >> session with a well-guessed session-id. PHP Auth resends all login >> credentials every time a request is made, and so there is no real >> session, which makes attacks sometimes easier. Of course, the >> security of those applications can be improved (especially with >> suhosin), but webservers and web-frontends are the primary hacking >> target (and very often subject to vulnerabilities). >> >> I wouldn''t doubt that it will *work* with that method, but having it >> in a secure way will be harder (but still possible). >> >> Probably you should consider using an own session mechanism, but this >> will require an advanced and security-aware PHP programmer. >> /dev/random (or if necessary /dev/urandom) should definitely be used >> for gaining the entropy for the session id and it should be long >> enough and further secured by ip address. And remember to do that all >> on a SSL-only connection, using that without SSL would allow anyone >> to do MITM attacks to capture the password / session id. >> >> Regards, >> Felix >> >> Am 18.06.2010 16:30, schrieb Jonathan Tripathy: >>> Thanks Felix, >>> Glad you like my idea. Since ajaxterm runs its own web server (and >>> you can specify the port is listens on, which would be one per >>> customer), I think it''s just a matter of using php to control access >>> to this resource. >>> Another, easier way, would be to just use Apache''s .htaccess stuff >>> (No sessions required). Just protect one directory per user, and in >>> each directory simply have an index.php that runs the correct >>> ajaxterm command for the user. Then Apache could use it''s reverse >>> proxy mechanism to give the user access to ajax term. The "logical" >>> address of the ajax term would be a child of the inital htaccess >>> protected directory. This isn''t as nice and doesn''t scale well, but >>> I''m pretty sure it would work.. >>> >>> ------------------------------------------------------------------------ >>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>> *Sent:* Fri 18/06/2010 15:25 >>> *To:* Jonathan Tripathy >>> *Cc:* xen-users@lists.xensource.com >>> *Subject:* Re: [Xen-users] Web Console Access >>> >>> Hi Jonathan, >>> >>> I think this is a great idea: The Domain-0 has full SSH-security >>> (can be limited to your webserver''s internal ip address for further >>> security) and the webserver is not running on Dom0. >>> You could combine this approaches: >>> SSH on Dom0, with RSA authentification and (for example) >>> sudo-wrapped xm console, accessed by your ajaxterm software. It >>> would be even possible to provide both methods to your customers, if >>> the SSH daemon is secured enough, or just allow that web console. >>> When the web console is secure enough, this will not expose any >>> security threats to your customers, and it would never be a threat >>> to your Dom0s. You''ll need to ask the ajaxterm developers, I only >>> know that many PHP session ids are *not* safely generated and ajax >>> can even extend that problem (on the other hand, suhosin fixes that >>> problem). SSH''s HMAC-method is more safe, but many applications rely >>> on PHP''s safety (some of them without being hacked), so it would >>> offer enough security if the application has no big security issues. >>> >>> Regards, >>> Felix >>> >>> Am 18.06.2010 16:09, schrieb Jonathan Tripathy: >>>> Hi Felix, >>>> What I was thinking of doing (And i''ll need to consult with my >>>> php/java folk here to get this working in a secure way), is to run >>>> Ajaxterm on the web server itself. When launch Ajaxterm, there is a >>>> -c option that allows you to specify a command. With an ssh key >>>> stored in the web server''s filesystem (Which only is allowed to >>>> preform global xm functions), I could do something like (The >>>> command would run locally on the web server): >>>> ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com >>>> <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console $vm_id >>>> Where $vm_id could be storaed in a database and would be the name >>>> of the DomU running >>>> What you think? >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>> Kuperjans >>>> *Sent:* Fri 18/06/2010 14:57 >>>> *To:* xen-users@lists.xensource.com >>>> *Subject:* Re: [Xen-users] Web Console Access >>>> >>>> Hi Jonathan, >>>> >>>> if you can do that, it''s good. But you''ll always need some kind of >>>> access to the Dom0 to get the console data and to reboot / reset / >>>> rescue the VMs (whatever you want to offer to your customers). >>>> >>>> Regards, >>>> Felix >>>> >>>> Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >>>>> Hi Felix, >>>>> Probably the main reason why I want to use a web console is so >>>>> that I can run the web server on a different machine (Or maybe in >>>>> a VM connected to an isolated network). >>>>> Thanks for the tip on the Grub password for the Dom0. That''s scary >>>>> about the KVM! >>>>> Thanks >>>>> Jonathan >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>> *Sent:* Fri 18/06/2010 14:13 >>>>> *To:* Jonathan Tripathy >>>>> *Cc:* xen-users@lists.xensource.com >>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>> >>>>> Hi Jonathan, >>>>> >>>>> the Dom0 cannot be compromised as long as your SSH or web-based >>>>> console does not have any security leaks. >>>>> PHP sessions are not as secure as SSH, but with SSL and suhosin >>>>> patched PHP considerably OK. >>>>> >>>>> As I said, I don''t use web-based consoles so I can''t help you >>>>> there, but I''d *really* consider whether it is a good thing to >>>>> setup a webserver on a Dom0 and it may be probably hard to do >>>>> web-based consoles without that. >>>>> >>>>> Regards, >>>>> Felix >>>>> >>>>> P.S. Anyway, considering the method I posted, you should always >>>>> setup GRUB and BIOS passwords for all of your Dom0s. I once >>>>> requested KVM access at my provider and ended up at the wrong >>>>> server... >>>>> >>>>> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>>>>> Hi Felix, >>>>>> I actually have that guy''s book who wrote that article - The book >>>>>> of Xen - very good book indeed! >>>>>> What I really wish to do, is provide a similar sort of thing to >>>>>> that SSH setup, except allow it to be accessed via a web browser. >>>>>> I have an idea where I can use ajaxterm and some PHP scripting. >>>>>> Once a user logs on with a username and password, I could tell >>>>>> php to start ajaxterm and piple xm console through it. This is >>>>>> what Slicehost does I think. The console would be protected with >>>>>> php sessions. >>>>>> But my main worry was whether or not the Dom0 could be >>>>>> compramised via the above method, but I don''t think that''s the case. >>>>>> Thanks >>>>>> Jonathan >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>>> Kuperjans >>>>>> *Sent:* Fri 18/06/2010 13:50 >>>>>> *To:* xen-users@lists.xensource.com >>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>> >>>>>> Hi Jonathan, >>>>>> >>>>>> this is a common way to reset lost / forgotton root passwords: >>>>>> >>>>>> You need: >>>>>> - Physical access to a machine (if you want to reset the password >>>>>> of the Dom0 or a native linux) or console access to a DomU >>>>>> - Access to the kernel command line, via lilo, grub or >>>>>> pygrub/pvgrub in XEN >>>>>> >>>>>> Then you do: >>>>>> - Modify the kernel command line, add the init=/bin/bash option, >>>>>> for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 >>>>>> init=/bin/bash >>>>>> - You''ll directly end up in a root console without password or >>>>>> any services started after the kernel booted >>>>>> - enter those commands: >>>>>> mount -o remount,rw / >>>>>> passwd root >>>>>> <enter new password> >>>>>> exec /sbin/init >>>>>> >>>>>> The root password will then be the newly set one. >>>>>> >>>>>> DomUs generally are not vulnerable to this method, as long as the >>>>>> kernel command line is set in the domain configuration. But >>>>>> pygrub/pvgrub is a nice thing for hosting customers, because they >>>>>> can compile their own kernels, containing their preferred >>>>>> settings, modules and builtin functionality. Generally this >>>>>> problem is avoided by adding a password to grub, but some >>>>>> customers may forget that step. >>>>>> So physical access can always be a strong weapon, but it is >>>>>> necessary for repairing a machine or for some advanced setups >>>>>> (especially when setting up a firewall, one easily gets locked >>>>>> out of the server...). I think the best way is securing this >>>>>> access, by restricting virtual console access to highly encrypted >>>>>> and authenticated sessions (IMHO the best way is SSH here). >>>>>> >>>>>> I''d also think about customers forgetting to log out, because >>>>>> leaving xm console does *not* logout root inside the console. >>>>>> >>>>>> The tutorial I posted to your I/O question contains a SSH-based >>>>>> setup for xm console access with sudo, which may be nice to start >>>>>> with. I personally use an own wrapper inside a chroot jail, to >>>>>> provide the ability of entering commands like create / rescue / >>>>>> setup (rescue starts another domain configuration with NFS root + >>>>>> rescue-Kernel, setup starts a virtual Debian setup). It''s quite >>>>>> handy for VPS customers. >>>>>> >>>>>> Regards, >>>>>> Felix >>>>>> >>>>>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>>>>> Hi Felix, >>>>>>> Thanks for the email. >>>>>>> >a simple init=/bin/bash added to the kernel command line allows >>>>>>> resetting the root password... >>>>>>> ok this worries me. Can you please explain this a little >>>>>>> further? Do you need to have access to the Dom0 to begin with? >>>>>>> Thanks >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>>>> Kuperjans >>>>>>> *Sent:* Fri 18/06/2010 12:54 >>>>>>> *To:* xen-users@lists.xensource.com >>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>> >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> do you definitely need a web console (so really browser-based) >>>>>>> or would you consider a SSH-based console? >>>>>>> >>>>>>> I personally prefer SSH because it is more secure, easier to set >>>>>>> up and it is somehow the default way of accessing remote >>>>>>> consoles. You can do a modified SSH setup that only allows >>>>>>> access to the console, or optionally, access to xm console, xm >>>>>>> list, xm shutdown, xm create but restricted to the own VM of >>>>>>> your customer. With chroot-jails etc., other commands cannot be >>>>>>> executed. >>>>>>> SSH also has the advantage of good copy & paste of larger >>>>>>> commands, and the possibility to work with multiple client >>>>>>> certificates and / or passwords. Probably your administrative >>>>>>> interface allows uploading of multiple public keys, so that your >>>>>>> customers can have multiple adminsitrative accounts for the >>>>>>> server (but only one can access the console at a time). >>>>>>> >>>>>>> I''ve got no experiences with ajaxterm, but you should really >>>>>>> control its security: >>>>>>> Console access is quite useful for hackers, e.g. some customer >>>>>>> may forget to log out root or if you use pvgrub / pygrub, a >>>>>>> simple init=/bin/bash added to the kernel command line allows >>>>>>> resetting the root password... >>>>>>> So it must be a really secure application, not vulnerable to >>>>>>> XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. >>>>>>> >>>>>>> Regards, >>>>>>> Felix Kuperjans >>>>>>> >>>>>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>>>>> Hi Everyone, >>>>>>>> Does anyone have any idea on how to give my customers a "web >>>>>>>> console" for their VMs? >>>>>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can >>>>>>>> manually set up a remote session for them, by doing >>>>>>>> ajaxterm.py -c xm console<DOMNAME> >>>>>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Xen-users mailing list >>>>>>>> Xen-users@lists.xensource.com >>>>>>>> http://lists.xensource.com/xen-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xen-users mailing list >>>>>>> Xen-users@lists.xensource.com >>>>>>> http://lists.xensource.com/xen-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-users mailing list >>>>> Xen-users@lists.xensource.com >>>>> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, I think this would increase the risk if ajaxterm would not be secure enough and you will need SSH anyway... I''ll have a look at ajaxterm now: (Note that I only read their website, did not test it locally) - Ajaxterm seems to contain an own little webserver, which is usually proxied through apache2 (or other Webservers) for SSL encryption and port access. I think you won''t be able to use PHP sessions here! Httpauth would be possible, indeed. - Many applications nowadays require UTF-8 locales (e.g. python3 AFAIK) to have their full functionality, but ajaxterm only handles latin1. As long as the language is English, most letters will have the same UTF-8 and latin1-codes, but it would not support some special characters in the terminal (even © would be a problem). - I''d say that the dom0 should only use SSH, but I''d really reconsider if you need a web console. SSH can be easily accessed with Windows, Linux and Mac and offers really secure encryption and authentication mechanisms. I don''t think that the ability to restrict the access to Dom0''s services (SSH / ajaxterm) with a firewall is a big pro: If the users get access via apache2 to Dom0''s ajaxterm or via ajaxterm on the webserver to Dom0''s SSH, exploits will be usable as well via that proxy (for example, worst case: xm console would have a bug that would allow command execution with xm''s rights (root!) within Domain-0 on a special key combination - it would work either way, but such severe bugs have never existed in the history of XEN). Try out some SSH-based setups, I personally prefer them to any web-based solution (restart / shutdown etc. can still be handled with a web-interface). If you like, I could help you with SSH configuration / hardening. Regards, Felix Am 19.06.2010 11:22, schrieb Jonathan Tripathy:> Hi Felix, > > I have another idea to maybe make it easier to implement: > > Instead of running Ajaxterm locally on the web server, I could run it > on the xen host itself. Inside the vif script, everytime the VM starts > up, I could put in a line that starts ajaxterm and binds it to a port > which is specific to that user. Then, I could use iptables to make > sure that the only machine which has access to this port is the web > server. > > Then on the web server, php could handle all the authentication, and > then "proxy" the ajaxterm output from the xen host to the user. No ssh > keys required! > > Pros: > Easy to start/stop ajaxterm by using the vif scripts > Easy to firewall (just use iptables) > > Cons: > Lots of ajaxterms will be launched (1 per vm), so the xen host may not > handle this very well > The web server will need to use ssh anyway for > startup/shutdown/restart of VMs > > What you think? > > Thanks > > > On 18/06/10 16:11, Felix Kuperjans wrote: >> Hm I don''t know of an actual hack when the session is SSL encrypted, >> but it''s not a good practise to send the login credentials every time >> although they are encrypted. >> Safe session ids, are better because there is one login with the >> password and the ''password'' for further requests is the session id >> (which must be at least as safe then, preferably even safer), >> combined with a three tries for the password mechanism or something >> similar. >> Best method are HMAC''s, but as far as I know, this is not available >> on PHP, but the default for SSH or OpenVPN connections. >> >> suhosin adds many security improvements to PHP (even to the default >> session mechanism) and I think it should be preferred over htaccess. >> >> Regards, >> Felix >> >> Am 18.06.2010 17:01, schrieb Jonathan Tripathy: >>> Thanks Felix. >>> >>> What you think of the Apache htaccess method? >>> >>> Thanks >>> >>> ------------------------------------------------------------------------ >>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>> *Sent:* Fri 18/06/2010 15:54 >>> *To:* Jonathan Tripathy >>> *Cc:* xen-users@lists.xensource.com >>> *Subject:* Re: [Xen-users] Web Console Access >>> >>> My main security concern would be rather: >>> If I were your customer, I would want that my VM''s console is >>> completely secured. But just relying on PHP sessions or HTTP-auth is >>> not really secure, e.g.: >>> >>> http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html >>> >>> A hacker could abuse such insecure mechanisms of PHP to enter the >>> session with a well-guessed session-id. PHP Auth resends all login >>> credentials every time a request is made, and so there is no real >>> session, which makes attacks sometimes easier. Of course, the >>> security of those applications can be improved (especially with >>> suhosin), but webservers and web-frontends are the primary hacking >>> target (and very often subject to vulnerabilities). >>> >>> I wouldn''t doubt that it will *work* with that method, but having it >>> in a secure way will be harder (but still possible). >>> >>> Probably you should consider using an own session mechanism, but >>> this will require an advanced and security-aware PHP programmer. >>> /dev/random (or if necessary /dev/urandom) should definitely be used >>> for gaining the entropy for the session id and it should be long >>> enough and further secured by ip address. And remember to do that >>> all on a SSL-only connection, using that without SSL would allow >>> anyone to do MITM attacks to capture the password / session id. >>> >>> Regards, >>> Felix >>> >>> Am 18.06.2010 16:30, schrieb Jonathan Tripathy: >>>> >>>> Thanks Felix, >>>> >>>> Glad you like my idea. Since ajaxterm runs its own web server (and >>>> you can specify the port is listens on, which would be one per >>>> customer), I think it''s just a matter of using php to control >>>> access to this resource. >>>> >>>> Another, easier way, would be to just use Apache''s .htaccess stuff >>>> (No sessions required). Just protect one directory per user, and in >>>> each directory simply have an index.php that runs the correct >>>> ajaxterm command for the user. Then Apache could use it''s reverse >>>> proxy mechanism to give the user access to ajax term. The "logical" >>>> address of the ajax term would be a child of the inital htaccess >>>> protected directory. This isn''t as nice and doesn''t scale well, but >>>> I''m pretty sure it would work.. >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>> *Sent:* Fri 18/06/2010 15:25 >>>> *To:* Jonathan Tripathy >>>> *Cc:* xen-users@lists.xensource.com >>>> *Subject:* Re: [Xen-users] Web Console Access >>>> >>>> Hi Jonathan, >>>> >>>> I think this is a great idea: The Domain-0 has full SSH-security >>>> (can be limited to your webserver''s internal ip address for further >>>> security) and the webserver is not running on Dom0. >>>> You could combine this approaches: >>>> SSH on Dom0, with RSA authentification and (for example) >>>> sudo-wrapped xm console, accessed by your ajaxterm software. It >>>> would be even possible to provide both methods to your customers, >>>> if the SSH daemon is secured enough, or just allow that web >>>> console. When the web console is secure enough, this will not >>>> expose any security threats to your customers, and it would never >>>> be a threat to your Dom0s. You''ll need to ask the ajaxterm >>>> developers, I only know that many PHP session ids are *not* safely >>>> generated and ajax can even extend that problem (on the other hand, >>>> suhosin fixes that problem). SSH''s HMAC-method is more safe, but >>>> many applications rely on PHP''s safety (some of them without being >>>> hacked), so it would offer enough security if the application has >>>> no big security issues. >>>> >>>> Regards, >>>> Felix >>>> >>>> Am 18.06.2010 16:09, schrieb Jonathan Tripathy: >>>>> Hi Felix, >>>>> >>>>> What I was thinking of doing (And i''ll need to consult with my >>>>> php/java folk here to get this working in a secure way), is to run >>>>> Ajaxterm on the web server itself. When launch Ajaxterm, there is >>>>> a -c option that allows you to specify a command. With an ssh key >>>>> stored in the web server''s filesystem (Which only is allowed to >>>>> preform global xm functions), I could do something like (The >>>>> command would run locally on the web server): >>>>> >>>>> ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com >>>>> <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console $vm_id >>>>> >>>>> Where $vm_id could be storaed in a database and would be the name >>>>> of the DomU running >>>>> >>>>> What you think? >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>> Kuperjans >>>>> *Sent:* Fri 18/06/2010 14:57 >>>>> *To:* xen-users@lists.xensource.com >>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>> >>>>> Hi Jonathan, >>>>> >>>>> if you can do that, it''s good. But you''ll always need some kind of >>>>> access to the Dom0 to get the console data and to reboot / reset / >>>>> rescue the VMs (whatever you want to offer to your customers). >>>>> >>>>> Regards, >>>>> Felix >>>>> >>>>> Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >>>>>> Hi Felix, >>>>>> >>>>>> Probably the main reason why I want to use a web console is so >>>>>> that I can run the web server on a different machine (Or maybe in >>>>>> a VM connected to an isolated network). >>>>>> >>>>>> Thanks for the tip on the Grub password for the Dom0. That''s >>>>>> scary about the KVM! >>>>>> >>>>>> Thanks >>>>>> >>>>>> Jonathan >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>>> *Sent:* Fri 18/06/2010 14:13 >>>>>> *To:* Jonathan Tripathy >>>>>> *Cc:* xen-users@lists.xensource.com >>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>> >>>>>> Hi Jonathan, >>>>>> >>>>>> the Dom0 cannot be compromised as long as your SSH or web-based >>>>>> console does not have any security leaks. >>>>>> PHP sessions are not as secure as SSH, but with SSL and suhosin >>>>>> patched PHP considerably OK. >>>>>> >>>>>> As I said, I don''t use web-based consoles so I can''t help you >>>>>> there, but I''d *really* consider whether it is a good thing to >>>>>> setup a webserver on a Dom0 and it may be probably hard to do >>>>>> web-based consoles without that. >>>>>> >>>>>> Regards, >>>>>> Felix >>>>>> >>>>>> P.S. Anyway, considering the method I posted, you should always >>>>>> setup GRUB and BIOS passwords for all of your Dom0s. I once >>>>>> requested KVM access at my provider and ended up at the wrong >>>>>> server... >>>>>> >>>>>> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>>>>>> Hi Felix, >>>>>>> >>>>>>> I actually have that guy''s book who wrote that article - The >>>>>>> book of Xen - very good book indeed! >>>>>>> >>>>>>> What I really wish to do, is provide a similar sort of thing to >>>>>>> that SSH setup, except allow it to be accessed via a web >>>>>>> browser. I have an idea where I can use ajaxterm and some PHP >>>>>>> scripting. Once a user logs on with a username and password, I >>>>>>> could tell php to start ajaxterm and piple xm console through >>>>>>> it. This is what Slicehost does I think. The console would be >>>>>>> protected with php sessions. >>>>>>> >>>>>>> But my main worry was whether or not the Dom0 could be >>>>>>> compramised via the above method, but I don''t think that''s the case. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Jonathan >>>>>>> ------------------------------------------------------------------------ >>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>>>> Kuperjans >>>>>>> *Sent:* Fri 18/06/2010 13:50 >>>>>>> *To:* xen-users@lists.xensource.com >>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>> >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> this is a common way to reset lost / forgotton root passwords: >>>>>>> >>>>>>> You need: >>>>>>> - Physical access to a machine (if you want to reset the >>>>>>> password of the Dom0 or a native linux) or console access to a DomU >>>>>>> - Access to the kernel command line, via lilo, grub or >>>>>>> pygrub/pvgrub in XEN >>>>>>> >>>>>>> Then you do: >>>>>>> - Modify the kernel command line, add the init=/bin/bash option, >>>>>>> for example: kernel /linux-2.6.32.15-xen root=/dev/xvda2 >>>>>>> init=/bin/bash >>>>>>> - You''ll directly end up in a root console without password or >>>>>>> any services started after the kernel booted >>>>>>> - enter those commands: >>>>>>> mount -o remount,rw / >>>>>>> passwd root >>>>>>> <enter new password> >>>>>>> exec /sbin/init >>>>>>> >>>>>>> The root password will then be the newly set one. >>>>>>> >>>>>>> DomUs generally are not vulnerable to this method, as long as >>>>>>> the kernel command line is set in the domain configuration. But >>>>>>> pygrub/pvgrub is a nice thing for hosting customers, because >>>>>>> they can compile their own kernels, containing their preferred >>>>>>> settings, modules and builtin functionality. Generally this >>>>>>> problem is avoided by adding a password to grub, but some >>>>>>> customers may forget that step. >>>>>>> So physical access can always be a strong weapon, but it is >>>>>>> necessary for repairing a machine or for some advanced setups >>>>>>> (especially when setting up a firewall, one easily gets locked >>>>>>> out of the server...). I think the best way is securing this >>>>>>> access, by restricting virtual console access to highly >>>>>>> encrypted and authenticated sessions (IMHO the best way is SSH >>>>>>> here). >>>>>>> >>>>>>> I''d also think about customers forgetting to log out, because >>>>>>> leaving xm console does *not* logout root inside the console. >>>>>>> >>>>>>> The tutorial I posted to your I/O question contains a SSH-based >>>>>>> setup for xm console access with sudo, which may be nice to >>>>>>> start with. I personally use an own wrapper inside a chroot >>>>>>> jail, to provide the ability of entering commands like create / >>>>>>> rescue / setup (rescue starts another domain configuration with >>>>>>> NFS root + rescue-Kernel, setup starts a virtual Debian setup). >>>>>>> It''s quite handy for VPS customers. >>>>>>> >>>>>>> Regards, >>>>>>> Felix >>>>>>> >>>>>>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>>>>>> >>>>>>>> Hi Felix, >>>>>>>> >>>>>>>> Thanks for the email. >>>>>>>> >>>>>>>> >a simple init=/bin/bash added to the kernel command line >>>>>>>> allows resetting the root password... >>>>>>>> ok this worries me. Can you please explain this a little >>>>>>>> further? Do you need to have access to the Dom0 to begin with? >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of >>>>>>>> Felix Kuperjans >>>>>>>> *Sent:* Fri 18/06/2010 12:54 >>>>>>>> *To:* xen-users@lists.xensource.com >>>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>>> >>>>>>>> Hi Jonathan, >>>>>>>> >>>>>>>> do you definitely need a web console (so really browser-based) >>>>>>>> or would you consider a SSH-based console? >>>>>>>> >>>>>>>> I personally prefer SSH because it is more secure, easier to >>>>>>>> set up and it is somehow the default way of accessing remote >>>>>>>> consoles. You can do a modified SSH setup that only allows >>>>>>>> access to the console, or optionally, access to xm console, xm >>>>>>>> list, xm shutdown, xm create but restricted to the own VM of >>>>>>>> your customer. With chroot-jails etc., other commands cannot be >>>>>>>> executed. >>>>>>>> SSH also has the advantage of good copy & paste of larger >>>>>>>> commands, and the possibility to work with multiple client >>>>>>>> certificates and / or passwords. Probably your administrative >>>>>>>> interface allows uploading of multiple public keys, so that >>>>>>>> your customers can have multiple adminsitrative accounts for >>>>>>>> the server (but only one can access the console at a time). >>>>>>>> >>>>>>>> I''ve got no experiences with ajaxterm, but you should really >>>>>>>> control its security: >>>>>>>> Console access is quite useful for hackers, e.g. some customer >>>>>>>> may forget to log out root or if you use pvgrub / pygrub, a >>>>>>>> simple init=/bin/bash added to the kernel command line allows >>>>>>>> resetting the root password... >>>>>>>> So it must be a really secure application, not vulnerable to >>>>>>>> XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Felix Kuperjans >>>>>>>> >>>>>>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>>>>>> Hi Everyone, >>>>>>>>> >>>>>>>>> Does anyone have any idea on how to give my customers a "web >>>>>>>>> console" for their VMs? >>>>>>>>> >>>>>>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can >>>>>>>>> manually set up a remote session for them, by doing >>>>>>>>> ajaxterm.py -c xm console <DOMNAME> >>>>>>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Xen-users mailing list >>>>>>>>> Xen-users@lists.xensource.com >>>>>>>>> http://lists.xensource.com/xen-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Xen-users mailing list >>>>>>>> Xen-users@lists.xensource.com >>>>>>>> http://lists.xensource.com/xen-users >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-users mailing list >>>>>> Xen-users@lists.xensource.com >>>>>> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Felix, I''m currently testing out my ajaxterm + ssh idea (with ajaxterm running on the webserver) and I''ve run into a small problem. When you do, for example ping xx.xx.xx.xx from with an xm console "session", CTRL-C doesn''t stop the pinging. Instead, it exits out of the ssh process. This happens regardless if I use ajaxterm or just do direct ssh. Any ideas? Many Thanks On 19/06/10 11:04, Felix Kuperjans wrote:> Hi Jonathan, > > I think this would increase the risk if ajaxterm would not be secure > enough and you will need SSH anyway... I''ll have a look at ajaxterm now: > > (Note that I only read their website, did not test it locally) > > - Ajaxterm seems to contain an own little webserver, which is usually > proxied through apache2 (or other Webservers) for SSL encryption and > port access. I think you won''t be able to use PHP sessions here! > Httpauth would be possible, indeed. > - Many applications nowadays require UTF-8 locales (e.g. python3 > AFAIK) to have their full functionality, but ajaxterm only handles > latin1. As long as the language is English, most letters will have the > same UTF-8 and latin1-codes, but it would not support some special > characters in the terminal (even © would be a problem). > - I''d say that the dom0 should only use SSH, but I''d really reconsider > if you need a web console. SSH can be easily accessed with Windows, > Linux and Mac and offers really secure encryption and authentication > mechanisms. > > I don''t think that the ability to restrict the access to Dom0''s > services (SSH / ajaxterm) with a firewall is a big pro: > If the users get access via apache2 to Dom0''s ajaxterm or via ajaxterm > on the webserver to Dom0''s SSH, exploits will be usable as well via > that proxy (for example, worst case: xm console would have a bug that > would allow command execution with xm''s rights (root!) within Domain-0 > on a special key combination - it would work either way, but such > severe bugs have never existed in the history of XEN). > > Try out some SSH-based setups, I personally prefer them to any > web-based solution (restart / shutdown etc. can still be handled with > a web-interface). If you like, I could help you with SSH configuration > / hardening. > > Regards, > Felix > > Am 19.06.2010 11:22, schrieb Jonathan Tripathy: >> Hi Felix, >> >> I have another idea to maybe make it easier to implement: >> >> Instead of running Ajaxterm locally on the web server, I could run it >> on the xen host itself. Inside the vif script, everytime the VM >> starts up, I could put in a line that starts ajaxterm and binds it to >> a port which is specific to that user. Then, I could use iptables to >> make sure that the only machine which has access to this port is the >> web server. >> >> Then on the web server, php could handle all the authentication, and >> then "proxy" the ajaxterm output from the xen host to the user. No >> ssh keys required! >> >> Pros: >> Easy to start/stop ajaxterm by using the vif scripts >> Easy to firewall (just use iptables) >> >> Cons: >> Lots of ajaxterms will be launched (1 per vm), so the xen host may >> not handle this very well >> The web server will need to use ssh anyway for >> startup/shutdown/restart of VMs >> >> What you think? >> >> Thanks >> >> >> On 18/06/10 16:11, Felix Kuperjans wrote: >>> Hm I don''t know of an actual hack when the session is SSL encrypted, >>> but it''s not a good practise to send the login credentials every >>> time although they are encrypted. >>> Safe session ids, are better because there is one login with the >>> password and the ''password'' for further requests is the session id >>> (which must be at least as safe then, preferably even safer), >>> combined with a three tries for the password mechanism or something >>> similar. >>> Best method are HMAC''s, but as far as I know, this is not available >>> on PHP, but the default for SSH or OpenVPN connections. >>> >>> suhosin adds many security improvements to PHP (even to the default >>> session mechanism) and I think it should be preferred over htaccess. >>> >>> Regards, >>> Felix >>> >>> Am 18.06.2010 17:01, schrieb Jonathan Tripathy: >>>> Thanks Felix. >>>> What you think of the Apache htaccess method? >>>> Thanks >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>> *Sent:* Fri 18/06/2010 15:54 >>>> *To:* Jonathan Tripathy >>>> *Cc:* xen-users@lists.xensource.com >>>> *Subject:* Re: [Xen-users] Web Console Access >>>> >>>> My main security concern would be rather: >>>> If I were your customer, I would want that my VM''s console is >>>> completely secured. But just relying on PHP sessions or HTTP-auth >>>> is not really secure, e.g.: >>>> >>>> http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html >>>> >>>> A hacker could abuse such insecure mechanisms of PHP to enter the >>>> session with a well-guessed session-id. PHP Auth resends all login >>>> credentials every time a request is made, and so there is no real >>>> session, which makes attacks sometimes easier. Of course, the >>>> security of those applications can be improved (especially with >>>> suhosin), but webservers and web-frontends are the primary hacking >>>> target (and very often subject to vulnerabilities). >>>> >>>> I wouldn''t doubt that it will *work* with that method, but having >>>> it in a secure way will be harder (but still possible). >>>> >>>> Probably you should consider using an own session mechanism, but >>>> this will require an advanced and security-aware PHP programmer. >>>> /dev/random (or if necessary /dev/urandom) should definitely be >>>> used for gaining the entropy for the session id and it should be >>>> long enough and further secured by ip address. And remember to do >>>> that all on a SSL-only connection, using that without SSL would >>>> allow anyone to do MITM attacks to capture the password / session id. >>>> >>>> Regards, >>>> Felix >>>> >>>> Am 18.06.2010 16:30, schrieb Jonathan Tripathy: >>>>> Thanks Felix, >>>>> Glad you like my idea. Since ajaxterm runs its own web server (and >>>>> you can specify the port is listens on, which would be one per >>>>> customer), I think it''s just a matter of using php to control >>>>> access to this resource. >>>>> Another, easier way, would be to just use Apache''s .htaccess stuff >>>>> (No sessions required). Just protect one directory per user, and >>>>> in each directory simply have an index.php that runs the correct >>>>> ajaxterm command for the user. Then Apache could use it''s reverse >>>>> proxy mechanism to give the user access to ajax term. The >>>>> "logical" address of the ajax term would be a child of the inital >>>>> htaccess protected directory. This isn''t as nice and doesn''t scale >>>>> well, but I''m pretty sure it would work.. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>> *Sent:* Fri 18/06/2010 15:25 >>>>> *To:* Jonathan Tripathy >>>>> *Cc:* xen-users@lists.xensource.com >>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>> >>>>> Hi Jonathan, >>>>> >>>>> I think this is a great idea: The Domain-0 has full SSH-security >>>>> (can be limited to your webserver''s internal ip address for >>>>> further security) and the webserver is not running on Dom0. >>>>> You could combine this approaches: >>>>> SSH on Dom0, with RSA authentification and (for example) >>>>> sudo-wrapped xm console, accessed by your ajaxterm software. It >>>>> would be even possible to provide both methods to your customers, >>>>> if the SSH daemon is secured enough, or just allow that web >>>>> console. When the web console is secure enough, this will not >>>>> expose any security threats to your customers, and it would never >>>>> be a threat to your Dom0s. You''ll need to ask the ajaxterm >>>>> developers, I only know that many PHP session ids are *not* safely >>>>> generated and ajax can even extend that problem (on the other >>>>> hand, suhosin fixes that problem). SSH''s HMAC-method is more safe, >>>>> but many applications rely on PHP''s safety (some of them without >>>>> being hacked), so it would offer enough security if the >>>>> application has no big security issues. >>>>> >>>>> Regards, >>>>> Felix >>>>> >>>>> Am 18.06.2010 16:09, schrieb Jonathan Tripathy: >>>>>> Hi Felix, >>>>>> What I was thinking of doing (And i''ll need to consult with my >>>>>> php/java folk here to get this working in a secure way), is to >>>>>> run Ajaxterm on the web server itself. When launch Ajaxterm, >>>>>> there is a -c option that allows you to specify a command. With >>>>>> an ssh key stored in the web server''s filesystem (Which only is >>>>>> allowed to preform global xm functions), I could do something >>>>>> like (The command would run locally on the web server): >>>>>> ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com >>>>>> <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console >>>>>> $vm_id >>>>>> Where $vm_id could be storaed in a database and would be the name >>>>>> of the DomU running >>>>>> What you think? >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>>> Kuperjans >>>>>> *Sent:* Fri 18/06/2010 14:57 >>>>>> *To:* xen-users@lists.xensource.com >>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>> >>>>>> Hi Jonathan, >>>>>> >>>>>> if you can do that, it''s good. But you''ll always need some kind >>>>>> of access to the Dom0 to get the console data and to reboot / >>>>>> reset / rescue the VMs (whatever you want to offer to your >>>>>> customers). >>>>>> >>>>>> Regards, >>>>>> Felix >>>>>> >>>>>> Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >>>>>>> Hi Felix, >>>>>>> Probably the main reason why I want to use a web console is so >>>>>>> that I can run the web server on a different machine (Or maybe >>>>>>> in a VM connected to an isolated network). >>>>>>> Thanks for the tip on the Grub password for the Dom0. That''s >>>>>>> scary about the KVM! >>>>>>> Thanks >>>>>>> Jonathan >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>>>> *Sent:* Fri 18/06/2010 14:13 >>>>>>> *To:* Jonathan Tripathy >>>>>>> *Cc:* xen-users@lists.xensource.com >>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>> >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> the Dom0 cannot be compromised as long as your SSH or web-based >>>>>>> console does not have any security leaks. >>>>>>> PHP sessions are not as secure as SSH, but with SSL and suhosin >>>>>>> patched PHP considerably OK. >>>>>>> >>>>>>> As I said, I don''t use web-based consoles so I can''t help you >>>>>>> there, but I''d *really* consider whether it is a good thing to >>>>>>> setup a webserver on a Dom0 and it may be probably hard to do >>>>>>> web-based consoles without that. >>>>>>> >>>>>>> Regards, >>>>>>> Felix >>>>>>> >>>>>>> P.S. Anyway, considering the method I posted, you should always >>>>>>> setup GRUB and BIOS passwords for all of your Dom0s. I once >>>>>>> requested KVM access at my provider and ended up at the wrong >>>>>>> server... >>>>>>> >>>>>>> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>>>>>>> Hi Felix, >>>>>>>> I actually have that guy''s book who wrote that article - The >>>>>>>> book of Xen - very good book indeed! >>>>>>>> What I really wish to do, is provide a similar sort of thing to >>>>>>>> that SSH setup, except allow it to be accessed via a web >>>>>>>> browser. I have an idea where I can use ajaxterm and some PHP >>>>>>>> scripting. Once a user logs on with a username and password, I >>>>>>>> could tell php to start ajaxterm and piple xm console through >>>>>>>> it. This is what Slicehost does I think. The console would be >>>>>>>> protected with php sessions. >>>>>>>> But my main worry was whether or not the Dom0 could be >>>>>>>> compramised via the above method, but I don''t think that''s the >>>>>>>> case. >>>>>>>> Thanks >>>>>>>> Jonathan >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of >>>>>>>> Felix Kuperjans >>>>>>>> *Sent:* Fri 18/06/2010 13:50 >>>>>>>> *To:* xen-users@lists.xensource.com >>>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>>> >>>>>>>> Hi Jonathan, >>>>>>>> >>>>>>>> this is a common way to reset lost / forgotton root passwords: >>>>>>>> >>>>>>>> You need: >>>>>>>> - Physical access to a machine (if you want to reset the >>>>>>>> password of the Dom0 or a native linux) or console access to a DomU >>>>>>>> - Access to the kernel command line, via lilo, grub or >>>>>>>> pygrub/pvgrub in XEN >>>>>>>> >>>>>>>> Then you do: >>>>>>>> - Modify the kernel command line, add the init=/bin/bash >>>>>>>> option, for example: kernel /linux-2.6.32.15-xen >>>>>>>> root=/dev/xvda2 init=/bin/bash >>>>>>>> - You''ll directly end up in a root console without password or >>>>>>>> any services started after the kernel booted >>>>>>>> - enter those commands: >>>>>>>> mount -o remount,rw / >>>>>>>> passwd root >>>>>>>> <enter new password> >>>>>>>> exec /sbin/init >>>>>>>> >>>>>>>> The root password will then be the newly set one. >>>>>>>> >>>>>>>> DomUs generally are not vulnerable to this method, as long as >>>>>>>> the kernel command line is set in the domain configuration. But >>>>>>>> pygrub/pvgrub is a nice thing for hosting customers, because >>>>>>>> they can compile their own kernels, containing their preferred >>>>>>>> settings, modules and builtin functionality. Generally this >>>>>>>> problem is avoided by adding a password to grub, but some >>>>>>>> customers may forget that step. >>>>>>>> So physical access can always be a strong weapon, but it is >>>>>>>> necessary for repairing a machine or for some advanced setups >>>>>>>> (especially when setting up a firewall, one easily gets locked >>>>>>>> out of the server...). I think the best way is securing this >>>>>>>> access, by restricting virtual console access to highly >>>>>>>> encrypted and authenticated sessions (IMHO the best way is SSH >>>>>>>> here). >>>>>>>> >>>>>>>> I''d also think about customers forgetting to log out, because >>>>>>>> leaving xm console does *not* logout root inside the console. >>>>>>>> >>>>>>>> The tutorial I posted to your I/O question contains a SSH-based >>>>>>>> setup for xm console access with sudo, which may be nice to >>>>>>>> start with. I personally use an own wrapper inside a chroot >>>>>>>> jail, to provide the ability of entering commands like create / >>>>>>>> rescue / setup (rescue starts another domain configuration with >>>>>>>> NFS root + rescue-Kernel, setup starts a virtual Debian setup). >>>>>>>> It''s quite handy for VPS customers. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Felix >>>>>>>> >>>>>>>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>>>>>>> Hi Felix, >>>>>>>>> Thanks for the email. >>>>>>>>> >a simple init=/bin/bash added to the kernel command line >>>>>>>>> allows resetting the root password... >>>>>>>>> ok this worries me. Can you please explain this a little >>>>>>>>> further? Do you need to have access to the Dom0 to begin with? >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of >>>>>>>>> Felix Kuperjans >>>>>>>>> *Sent:* Fri 18/06/2010 12:54 >>>>>>>>> *To:* xen-users@lists.xensource.com >>>>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>>>> >>>>>>>>> Hi Jonathan, >>>>>>>>> >>>>>>>>> do you definitely need a web console (so really browser-based) >>>>>>>>> or would you consider a SSH-based console? >>>>>>>>> >>>>>>>>> I personally prefer SSH because it is more secure, easier to >>>>>>>>> set up and it is somehow the default way of accessing remote >>>>>>>>> consoles. You can do a modified SSH setup that only allows >>>>>>>>> access to the console, or optionally, access to xm console, xm >>>>>>>>> list, xm shutdown, xm create but restricted to the own VM of >>>>>>>>> your customer. With chroot-jails etc., other commands cannot >>>>>>>>> be executed. >>>>>>>>> SSH also has the advantage of good copy & paste of larger >>>>>>>>> commands, and the possibility to work with multiple client >>>>>>>>> certificates and / or passwords. Probably your administrative >>>>>>>>> interface allows uploading of multiple public keys, so that >>>>>>>>> your customers can have multiple adminsitrative accounts for >>>>>>>>> the server (but only one can access the console at a time). >>>>>>>>> >>>>>>>>> I''ve got no experiences with ajaxterm, but you should really >>>>>>>>> control its security: >>>>>>>>> Console access is quite useful for hackers, e.g. some customer >>>>>>>>> may forget to log out root or if you use pvgrub / pygrub, a >>>>>>>>> simple init=/bin/bash added to the kernel command line allows >>>>>>>>> resetting the root password... >>>>>>>>> So it must be a really secure application, not vulnerable to >>>>>>>>> XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Felix Kuperjans >>>>>>>>> >>>>>>>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>>>>>>> Hi Everyone, >>>>>>>>>> Does anyone have any idea on how to give my customers a "web >>>>>>>>>> console" for their VMs? >>>>>>>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can >>>>>>>>>> manually set up a remote session for them, by doing >>>>>>>>>> ajaxterm.py -c xm console<DOMNAME> >>>>>>>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Xen-users mailing list >>>>>>>>>> Xen-users@lists.xensource.com >>>>>>>>>> http://lists.xensource.com/xen-users >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Xen-users mailing list >>>>>>>>> Xen-users@lists.xensource.com >>>>>>>>> http://lists.xensource.com/xen-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xen-users mailing list >>>>>>> Xen-users@lists.xensource.com >>>>>>> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Jonathan, this does not happen with my pure SSH setup, so this might have one of the following reasons: - Ajaxterm exits on Ctrl + C, you may be able to work around that if you start ajaxterm with nohup. - sudo exits on Ctrl + C, probably you should use another mechanism on the Dom0 (try that out by connecting directly to SSH with linux command-line client). Try out those solutions and report your experiences. Regards, Felix Am 19.06.2010 20:48, schrieb Jonathan Tripathy:> Hi Felix, > > I''m currently testing out my ajaxterm + ssh idea (with ajaxterm > running on the webserver) and I''ve run into a small problem. > > When you do, for example ping xx.xx.xx.xx from with an xm console > "session", CTRL-C doesn''t stop the pinging. Instead, it exits out of > the ssh process. This happens regardless if I use ajaxterm or just do > direct ssh. > > Any ideas? > > Many Thanks > > On 19/06/10 11:04, Felix Kuperjans wrote: >> Hi Jonathan, >> >> I think this would increase the risk if ajaxterm would not be secure >> enough and you will need SSH anyway... I''ll have a look at ajaxterm now: >> >> (Note that I only read their website, did not test it locally) >> >> - Ajaxterm seems to contain an own little webserver, which is usually >> proxied through apache2 (or other Webservers) for SSL encryption and >> port access. I think you won''t be able to use PHP sessions here! >> Httpauth would be possible, indeed. >> - Many applications nowadays require UTF-8 locales (e.g. python3 >> AFAIK) to have their full functionality, but ajaxterm only handles >> latin1. As long as the language is English, most letters will have >> the same UTF-8 and latin1-codes, but it would not support some >> special characters in the terminal (even © would be a problem). >> - I''d say that the dom0 should only use SSH, but I''d really >> reconsider if you need a web console. SSH can be easily accessed with >> Windows, Linux and Mac and offers really secure encryption and >> authentication mechanisms. >> >> I don''t think that the ability to restrict the access to Dom0''s >> services (SSH / ajaxterm) with a firewall is a big pro: >> If the users get access via apache2 to Dom0''s ajaxterm or via >> ajaxterm on the webserver to Dom0''s SSH, exploits will be usable as >> well via that proxy (for example, worst case: xm console would have a >> bug that would allow command execution with xm''s rights (root!) >> within Domain-0 on a special key combination - it would work either >> way, but such severe bugs have never existed in the history of XEN). >> >> Try out some SSH-based setups, I personally prefer them to any >> web-based solution (restart / shutdown etc. can still be handled with >> a web-interface). If you like, I could help you with SSH >> configuration / hardening. >> >> Regards, >> Felix >> >> Am 19.06.2010 11:22, schrieb Jonathan Tripathy: >>> Hi Felix, >>> >>> I have another idea to maybe make it easier to implement: >>> >>> Instead of running Ajaxterm locally on the web server, I could run >>> it on the xen host itself. Inside the vif script, everytime the VM >>> starts up, I could put in a line that starts ajaxterm and binds it >>> to a port which is specific to that user. Then, I could use iptables >>> to make sure that the only machine which has access to this port is >>> the web server. >>> >>> Then on the web server, php could handle all the authentication, and >>> then "proxy" the ajaxterm output from the xen host to the user. No >>> ssh keys required! >>> >>> Pros: >>> Easy to start/stop ajaxterm by using the vif scripts >>> Easy to firewall (just use iptables) >>> >>> Cons: >>> Lots of ajaxterms will be launched (1 per vm), so the xen host may >>> not handle this very well >>> The web server will need to use ssh anyway for >>> startup/shutdown/restart of VMs >>> >>> What you think? >>> >>> Thanks >>> >>> >>> On 18/06/10 16:11, Felix Kuperjans wrote: >>>> Hm I don''t know of an actual hack when the session is SSL >>>> encrypted, but it''s not a good practise to send the login >>>> credentials every time although they are encrypted. >>>> Safe session ids, are better because there is one login with the >>>> password and the ''password'' for further requests is the session id >>>> (which must be at least as safe then, preferably even safer), >>>> combined with a three tries for the password mechanism or something >>>> similar. >>>> Best method are HMAC''s, but as far as I know, this is not available >>>> on PHP, but the default for SSH or OpenVPN connections. >>>> >>>> suhosin adds many security improvements to PHP (even to the default >>>> session mechanism) and I think it should be preferred over htaccess. >>>> >>>> Regards, >>>> Felix >>>> >>>> Am 18.06.2010 17:01, schrieb Jonathan Tripathy: >>>>> Thanks Felix. >>>>> >>>>> What you think of the Apache htaccess method? >>>>> >>>>> Thanks >>>>> >>>>> ------------------------------------------------------------------------ >>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>> *Sent:* Fri 18/06/2010 15:54 >>>>> *To:* Jonathan Tripathy >>>>> *Cc:* xen-users@lists.xensource.com >>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>> >>>>> My main security concern would be rather: >>>>> If I were your customer, I would want that my VM''s console is >>>>> completely secured. But just relying on PHP sessions or HTTP-auth >>>>> is not really secure, e.g.: >>>>> >>>>> http://www.h-online.com/open/news/item/PHP-blunders-with-random-numbers-967525.html >>>>> >>>>> A hacker could abuse such insecure mechanisms of PHP to enter the >>>>> session with a well-guessed session-id. PHP Auth resends all login >>>>> credentials every time a request is made, and so there is no real >>>>> session, which makes attacks sometimes easier. Of course, the >>>>> security of those applications can be improved (especially with >>>>> suhosin), but webservers and web-frontends are the primary hacking >>>>> target (and very often subject to vulnerabilities). >>>>> >>>>> I wouldn''t doubt that it will *work* with that method, but having >>>>> it in a secure way will be harder (but still possible). >>>>> >>>>> Probably you should consider using an own session mechanism, but >>>>> this will require an advanced and security-aware PHP programmer. >>>>> /dev/random (or if necessary /dev/urandom) should definitely be >>>>> used for gaining the entropy for the session id and it should be >>>>> long enough and further secured by ip address. And remember to do >>>>> that all on a SSL-only connection, using that without SSL would >>>>> allow anyone to do MITM attacks to capture the password / session id. >>>>> >>>>> Regards, >>>>> Felix >>>>> >>>>> Am 18.06.2010 16:30, schrieb Jonathan Tripathy: >>>>>> >>>>>> Thanks Felix, >>>>>> >>>>>> Glad you like my idea. Since ajaxterm runs its own web server >>>>>> (and you can specify the port is listens on, which would be one >>>>>> per customer), I think it''s just a matter of using php to control >>>>>> access to this resource. >>>>>> >>>>>> Another, easier way, would be to just use Apache''s .htaccess >>>>>> stuff (No sessions required). Just protect one directory per >>>>>> user, and in each directory simply have an index.php that runs >>>>>> the correct ajaxterm command for the user. Then Apache could use >>>>>> it''s reverse proxy mechanism to give the user access to ajax >>>>>> term. The "logical" address of the ajax term would be a child of >>>>>> the inital htaccess protected directory. This isn''t as nice and >>>>>> doesn''t scale well, but I''m pretty sure it would work.. >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>>> *Sent:* Fri 18/06/2010 15:25 >>>>>> *To:* Jonathan Tripathy >>>>>> *Cc:* xen-users@lists.xensource.com >>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>> >>>>>> Hi Jonathan, >>>>>> >>>>>> I think this is a great idea: The Domain-0 has full SSH-security >>>>>> (can be limited to your webserver''s internal ip address for >>>>>> further security) and the webserver is not running on Dom0. >>>>>> You could combine this approaches: >>>>>> SSH on Dom0, with RSA authentification and (for example) >>>>>> sudo-wrapped xm console, accessed by your ajaxterm software. It >>>>>> would be even possible to provide both methods to your customers, >>>>>> if the SSH daemon is secured enough, or just allow that web >>>>>> console. When the web console is secure enough, this will not >>>>>> expose any security threats to your customers, and it would never >>>>>> be a threat to your Dom0s. You''ll need to ask the ajaxterm >>>>>> developers, I only know that many PHP session ids are *not* >>>>>> safely generated and ajax can even extend that problem (on the >>>>>> other hand, suhosin fixes that problem). SSH''s HMAC-method is >>>>>> more safe, but many applications rely on PHP''s safety (some of >>>>>> them without being hacked), so it would offer enough security if >>>>>> the application has no big security issues. >>>>>> >>>>>> Regards, >>>>>> Felix >>>>>> >>>>>> Am 18.06.2010 16:09, schrieb Jonathan Tripathy: >>>>>>> Hi Felix, >>>>>>> >>>>>>> What I was thinking of doing (And i''ll need to consult with my >>>>>>> php/java folk here to get this working in a secure way), is to >>>>>>> run Ajaxterm on the web server itself. When launch Ajaxterm, >>>>>>> there is a -c option that allows you to specify a command. With >>>>>>> an ssh key stored in the web server''s filesystem (Which only is >>>>>>> allowed to preform global xm functions), I could do something >>>>>>> like (The command would run locally on the web server): >>>>>>> >>>>>>> ./ajaxterm.py -c ssh xmuser@xenhost.mydomain.com >>>>>>> <mailto:xmuser@xenhost.mydomain.com> -k /path/to/key xm console >>>>>>> $vm_id >>>>>>> >>>>>>> Where $vm_id could be storaed in a database and would be the >>>>>>> name of the DomU running >>>>>>> >>>>>>> What you think? >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of Felix >>>>>>> Kuperjans >>>>>>> *Sent:* Fri 18/06/2010 14:57 >>>>>>> *To:* xen-users@lists.xensource.com >>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>> >>>>>>> Hi Jonathan, >>>>>>> >>>>>>> if you can do that, it''s good. But you''ll always need some kind >>>>>>> of access to the Dom0 to get the console data and to reboot / >>>>>>> reset / rescue the VMs (whatever you want to offer to your >>>>>>> customers). >>>>>>> >>>>>>> Regards, >>>>>>> Felix >>>>>>> >>>>>>> Am 18.06.2010 15:17, schrieb Jonathan Tripathy: >>>>>>>> Hi Felix, >>>>>>>> >>>>>>>> Probably the main reason why I want to use a web console is so >>>>>>>> that I can run the web server on a different machine (Or maybe >>>>>>>> in a VM connected to an isolated network). >>>>>>>> >>>>>>>> Thanks for the tip on the Grub password for the Dom0. That''s >>>>>>>> scary about the KVM! >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Jonathan >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> *From:* Felix Kuperjans [mailto:felix@desaster-games.com] >>>>>>>> *Sent:* Fri 18/06/2010 14:13 >>>>>>>> *To:* Jonathan Tripathy >>>>>>>> *Cc:* xen-users@lists.xensource.com >>>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>>> >>>>>>>> Hi Jonathan, >>>>>>>> >>>>>>>> the Dom0 cannot be compromised as long as your SSH or web-based >>>>>>>> console does not have any security leaks. >>>>>>>> PHP sessions are not as secure as SSH, but with SSL and suhosin >>>>>>>> patched PHP considerably OK. >>>>>>>> >>>>>>>> As I said, I don''t use web-based consoles so I can''t help you >>>>>>>> there, but I''d *really* consider whether it is a good thing to >>>>>>>> setup a webserver on a Dom0 and it may be probably hard to do >>>>>>>> web-based consoles without that. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Felix >>>>>>>> >>>>>>>> P.S. Anyway, considering the method I posted, you should always >>>>>>>> setup GRUB and BIOS passwords for all of your Dom0s. I once >>>>>>>> requested KVM access at my provider and ended up at the wrong >>>>>>>> server... >>>>>>>> >>>>>>>> Am 18.06.2010 15:03, schrieb Jonathan Tripathy: >>>>>>>>> Hi Felix, >>>>>>>>> >>>>>>>>> I actually have that guy''s book who wrote that article - The >>>>>>>>> book of Xen - very good book indeed! >>>>>>>>> >>>>>>>>> What I really wish to do, is provide a similar sort of thing >>>>>>>>> to that SSH setup, except allow it to be accessed via a web >>>>>>>>> browser. I have an idea where I can use ajaxterm and some PHP >>>>>>>>> scripting. Once a user logs on with a username and password, I >>>>>>>>> could tell php to start ajaxterm and piple xm console through >>>>>>>>> it. This is what Slicehost does I think. The console would be >>>>>>>>> protected with php sessions. >>>>>>>>> >>>>>>>>> But my main worry was whether or not the Dom0 could be >>>>>>>>> compramised via the above method, but I don''t think that''s the >>>>>>>>> case. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Jonathan >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of >>>>>>>>> Felix Kuperjans >>>>>>>>> *Sent:* Fri 18/06/2010 13:50 >>>>>>>>> *To:* xen-users@lists.xensource.com >>>>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>>>> >>>>>>>>> Hi Jonathan, >>>>>>>>> >>>>>>>>> this is a common way to reset lost / forgotton root passwords: >>>>>>>>> >>>>>>>>> You need: >>>>>>>>> - Physical access to a machine (if you want to reset the >>>>>>>>> password of the Dom0 or a native linux) or console access to a >>>>>>>>> DomU >>>>>>>>> - Access to the kernel command line, via lilo, grub or >>>>>>>>> pygrub/pvgrub in XEN >>>>>>>>> >>>>>>>>> Then you do: >>>>>>>>> - Modify the kernel command line, add the init=/bin/bash >>>>>>>>> option, for example: kernel /linux-2.6.32.15-xen >>>>>>>>> root=/dev/xvda2 init=/bin/bash >>>>>>>>> - You''ll directly end up in a root console without password or >>>>>>>>> any services started after the kernel booted >>>>>>>>> - enter those commands: >>>>>>>>> mount -o remount,rw / >>>>>>>>> passwd root >>>>>>>>> <enter new password> >>>>>>>>> exec /sbin/init >>>>>>>>> >>>>>>>>> The root password will then be the newly set one. >>>>>>>>> >>>>>>>>> DomUs generally are not vulnerable to this method, as long as >>>>>>>>> the kernel command line is set in the domain configuration. >>>>>>>>> But pygrub/pvgrub is a nice thing for hosting customers, >>>>>>>>> because they can compile their own kernels, containing their >>>>>>>>> preferred settings, modules and builtin functionality. >>>>>>>>> Generally this problem is avoided by adding a password to >>>>>>>>> grub, but some customers may forget that step. >>>>>>>>> So physical access can always be a strong weapon, but it is >>>>>>>>> necessary for repairing a machine or for some advanced setups >>>>>>>>> (especially when setting up a firewall, one easily gets locked >>>>>>>>> out of the server...). I think the best way is securing this >>>>>>>>> access, by restricting virtual console access to highly >>>>>>>>> encrypted and authenticated sessions (IMHO the best way is SSH >>>>>>>>> here). >>>>>>>>> >>>>>>>>> I''d also think about customers forgetting to log out, because >>>>>>>>> leaving xm console does *not* logout root inside the console. >>>>>>>>> >>>>>>>>> The tutorial I posted to your I/O question contains a >>>>>>>>> SSH-based setup for xm console access with sudo, which may be >>>>>>>>> nice to start with. I personally use an own wrapper inside a >>>>>>>>> chroot jail, to provide the ability of entering commands like >>>>>>>>> create / rescue / setup (rescue starts another domain >>>>>>>>> configuration with NFS root + rescue-Kernel, setup starts a >>>>>>>>> virtual Debian setup). It''s quite handy for VPS customers. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Felix >>>>>>>>> >>>>>>>>> Am 18.06.2010 14:26, schrieb Jonathan Tripathy: >>>>>>>>>> >>>>>>>>>> Hi Felix, >>>>>>>>>> >>>>>>>>>> Thanks for the email. >>>>>>>>>> >>>>>>>>>> >a simple init=/bin/bash added to the kernel command line >>>>>>>>>> allows resetting the root password... >>>>>>>>>> ok this worries me. Can you please explain this a little >>>>>>>>>> further? Do you need to have access to the Dom0 to begin with? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> *From:* xen-users-bounces@lists.xensource.com on behalf of >>>>>>>>>> Felix Kuperjans >>>>>>>>>> *Sent:* Fri 18/06/2010 12:54 >>>>>>>>>> *To:* xen-users@lists.xensource.com >>>>>>>>>> *Subject:* Re: [Xen-users] Web Console Access >>>>>>>>>> >>>>>>>>>> Hi Jonathan, >>>>>>>>>> >>>>>>>>>> do you definitely need a web console (so really >>>>>>>>>> browser-based) or would you consider a SSH-based console? >>>>>>>>>> >>>>>>>>>> I personally prefer SSH because it is more secure, easier to >>>>>>>>>> set up and it is somehow the default way of accessing remote >>>>>>>>>> consoles. You can do a modified SSH setup that only allows >>>>>>>>>> access to the console, or optionally, access to xm console, >>>>>>>>>> xm list, xm shutdown, xm create but restricted to the own VM >>>>>>>>>> of your customer. With chroot-jails etc., other commands >>>>>>>>>> cannot be executed. >>>>>>>>>> SSH also has the advantage of good copy & paste of larger >>>>>>>>>> commands, and the possibility to work with multiple client >>>>>>>>>> certificates and / or passwords. Probably your administrative >>>>>>>>>> interface allows uploading of multiple public keys, so that >>>>>>>>>> your customers can have multiple adminsitrative accounts for >>>>>>>>>> the server (but only one can access the console at a time). >>>>>>>>>> >>>>>>>>>> I''ve got no experiences with ajaxterm, but you should really >>>>>>>>>> control its security: >>>>>>>>>> Console access is quite useful for hackers, e.g. some >>>>>>>>>> customer may forget to log out root or if you use pvgrub / >>>>>>>>>> pygrub, a simple init=/bin/bash added to the kernel command >>>>>>>>>> line allows resetting the root password... >>>>>>>>>> So it must be a really secure application, not vulnerable to >>>>>>>>>> XSS, SQL Injections, Connection hijacking, ... and SSL encrypted. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Felix Kuperjans >>>>>>>>>> >>>>>>>>>> Am 18.06.2010 13:02, schrieb Jonathan Tripathy: >>>>>>>>>>> Hi Everyone, >>>>>>>>>>> >>>>>>>>>>> Does anyone have any idea on how to give my customers a "web >>>>>>>>>>> console" for their VMs? >>>>>>>>>>> >>>>>>>>>>> Using http://antony.lesuisse.org/software/ajaxterm/ I can >>>>>>>>>>> manually set up a remote session for them, by doing >>>>>>>>>>> ajaxterm.py -c xm console <DOMNAME> >>>>>>>>>>> However is there any way to make this automatic? Maybe I could put it in the vif script? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Xen-users mailing list >>>>>>>>>>> Xen-users@lists.xensource.com >>>>>>>>>>> http://lists.xensource.com/xen-users >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Xen-users mailing list >>>>>>>>>> Xen-users@lists.xensource.com >>>>>>>>>> http://lists.xensource.com/xen-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Xen-users mailing list >>>>>>>> Xen-users@lists.xensource.com >>>>>>>> http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Jun 19, 2010 at 2:52 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:> Instead of running Ajaxterm locally on the web server, I could run it on the > xen host itself. Inside the vif script, everytime the VM starts up, I could > put in a line that starts ajaxterm and binds it to a port which is specific > to that user.I am interested to know how you will do this.Or what you did to do so.I am aware of Ajaxterm and have used it on Debian there are similar things for Ubuntu. -- Tapas http://mightydreams.blogspot.com http://wiki.xensource.com/xenwiki/Xen_on_4_app_servers _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users