Resetting root password: Difference between revisions
Strugglers (talk | contribs) No edit summary |
(Add a category.) |
||
| Line 197: | Line 197: | ||
==Boot with <tt>init=/bin/sh</tt>== | ==Boot with <tt>init=/bin/sh</tt>== | ||
It should be possible to edit your kernel command line in pyGRUB to add <tt>init=/bin/sh</tt>. This would boot directly to a root shell where you would be able to reset the root password. However pyGRUB is quite fiddly to use and you only have a few seconds to interrupt the boot process, so the above method is probably easier. | It should be possible to edit your kernel command line in pyGRUB to add <tt>init=/bin/sh</tt>. This would boot directly to a root shell where you would be able to reset the root password. However pyGRUB is quite fiddly to use and you only have a few seconds to interrupt the boot process, so the above method is probably easier. | ||
[[Category:BitFolk]] | |||
Revision as of 09:00, 23 October 2010
How to reset your root password.
Let's say you've been a bit silly and misplaced your root password for your VPS, and have no means to log in to it. There's a variety of ways you can get yourself out of this predicament without having support do it for you.
Via rescue VPS
There's a rescue environment which all customers can boot into. It runs from RAM and gives you access to your block devices. It's easy to reset your password this way, or fix a lot of other things.
Access to the rescue VPS
The rescue VPS is accessed via the Xen Shell. So:
$ ssh username@username.console.bitfolk.com Password: xen-shell v1.48bitfolk1 - type 'help' for help. xen-shell> help xen-shell v1.48bitfolk1 The following commands are available within this shell: boot Boot your VPS. console Gain access to your VPS via the serial console. destroy Immediately destroy your running VPS - dangerous! exit Exit this shell. help Show general, or command-specific, help information. reboot Reboot your VPS. rescue Boot into the rescue environment. shutdown Shut down your VPS. status Show the status of your VPS. uptime Show the uptime information of the host and guest systems. version Show the version of this shell, and of Xen. xfer Show data transfer stats. For command-specific help run "help command". xen-shell>
Only one VPS instance can be run at once
The rescue VPS can only be booted when your real VPS is not running, so if it is you'll have to shut it down:
xen-shell> shutdown Shutting down instance: username Domain username terminated All domains terminated
Boot rescue VPS
xen-shell> rescue
Booting rescue instance: username
Using config file "/etc/xen/username.rescue.conf".
Started domain username
Linux version 2.6.18-6-xen-686 (Debian 2.6.18.dfsg.1-26etch2) (dannf@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Sat Feb 20 01:44:14 UTC 2010
[...]
Resetting root password to random value:
New root password: ioYooTei
Creating SSH2 RSA key; this may take some time ...
Creating SSH2 DSA key; this may take some time ...
Restarting OpenBSD Secure Shell server: sshd.
Starting OpenBSD Secure Shell server: sshd.
Running local boot scripts (/etc/rc.local).
BitFolk Rescue Environment
This virtual machine is running read-only over NFS with a unionfs ramdisk to
allow changes. This means:
- anything you write to its filesystem will not survive a reboot
- you only have about half your RAM size as writable space
If you need to write more, you are going to have to mount your VPS's normal
filesystems to do it on. Your block devices should available for mounting; see
/proc/partitions.
The root password has been randomly-generated (see above); be careful what you
do with it as networking is now active and sshd is running.
rescue login:
Log in to rescue VPS
As the above message suggests, the running VPS has a randomly-generated root password (ioYooTei in this case). This is not the root password of your VPS - this isn't your VPS. Networking is also enabled, so you could SSH in as root with that password if you like. At this point you're already at the console prompt though, so may as well log in there.
rescue login: root Password: rescue:~#
Your block devices
The rescue VPS has access to your block device(s), but doesn't run from them. You can see what's accessible:
rescue:~# cat /proc/partitions major minor #blocks name 202 0 10485760 xvda
and mount that somewhere:
rescue:~# mkdir /tmp/xvda
rescue:~# mount -v /dev/xvda /tmp/xvda
mount: you didn't specify a filesystem type for /dev/xvda
I will try type ext3
kjournald starting. Commit interval 5 seconds
EXT3 FS on xvda, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
/dev/xvda on /tmp/xvda type ext3 (rw)
Reset root password
Now that your VPS's filesystem is mounted you can try to fix whatever is broken. In this case that's resetting your root password:
rescue:~# chroot /tmp/xvda /bin/bash root@rescue:/# uname -a Linux rescue 2.6.18-6-xen-686 #1 SMP Sat Feb 20 01:44:14 UTC 2010 i686 GNU/Linux root@rescue:/# passwd root Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully root@rescue:/# exit rescue:~#
Boot back to your real VPS
Again, only one instance of your VPS can run at once, so you need to halt (shutdown -h) the rescue VPS and boot your own as normal. Hopefully it's fixed now.
rescue:~# halt
Broadcast message from root@rescue (tty1) (Thu Oct 21 19:14:16 2010):
The system is going down for system halt NOW!
INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal
Stopping OpenBSD Secure Shell server: sshd.
Saving the system clock..
Hardware Clock updated to Thu Oct 21 19:14:17 UTC 2010.
Stopping kernel log daemon: klogd.
Stopping system log daemon: syslogd.
Asking all remaining processes to terminate...done.
Killing all remaining processes...done.
Saving random seed...done.
Unmounting remote and non-toplevel virtual filesystems...done.
Deconfiguring network interfaces...done.
Cleaning up ifupdown....
Will now unmount temporary filesystems:umount: /UNIONFS: device is busy
umount: /UNIONFS: device is busy
tmpfs umounted
failed!
Will now deactivate swap:.
Mounting root filesystem read-only...Warning! dirs delete and imap options to remount are ignored
done.
Will now halt.
xenbus_dev_shutdown: device/console/0: Unknown != Connected, skipping
System halted.
xen-shell> boot
Booting instance: username
Using config file "/etc/xen/username.conf".
pyGRUB version 0.6
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x Ubuntu 10.04.1 LTS, kernel 2.6.32-24-generic-pae x
[...]
Started domain username
[ 0.000000] Reserving virtual address space above 0xf5800000
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.32-24-generic-pae (buildd@palmer) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #43-Ubuntu SMP Thu Sep 16 15:30:27 UTC 2010 (Ubuntu 2.6.32-24.43-generic-pae 2.6.32.15+drm33.5)
[...]
Ubuntu 10.04.1 LTS username hvc0
username login: root
Password:
Last login: Tue May 4 16:55:05 UTC 2010 on hvc0
Linux username 2.6.32-24-generic-pae #43-Ubuntu SMP Thu Sep 16 15:30:27 UTC 2010 i686 GNU/Linux
Ubuntu 10.04.1 LTS
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/
root@username:~#
Success!
Boot with init=/bin/sh
It should be possible to edit your kernel command line in pyGRUB to add init=/bin/sh. This would boot directly to a root shell where you would be able to reset the root password. However pyGRUB is quite fiddly to use and you only have a few seconds to interrupt the boot process, so the above method is probably easier.