xen-users
RE: [Xen-users] Web Console Access
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@xxxxxxxxxxxxxxxxxx] Sent: Fri 18/06/2010
14:13 To: Jonathan Tripathy Cc:
xen-users@xxxxxxxxxxxxxxxxxxx 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
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
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access,
Jonathan Tripathy <=
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
- RE: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Jonathan Tripathy
- Re: [Xen-users] Web Console Access, Felix Kuperjans
|
|
|