It seems VMware has removed the GUI for the disk shrink feature in VMware Tools, but the good news is it's still available from the console.
The following command will shrink the disk image for drive C:
C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe disk shrink c:\
When changing your password on a samba (Linux) server, the tokens a Windows machine holds get invalidated, yet Windows does not automatically prompt for new credentials. Instead, it consistently says "access denied" when trying to access a previously available share, say, \\myfineserver\share
If you previously mapped this drive, disconnecting is trivial in explorer, but if you browsed the network to access this drive, it's not that straight forward.
There is a solution, however, which is roughly equivalent to nuking the site from orbit. Running the following commands will clear all current network credentials:
net use * /del /yes net use /persistent:no
The simplest way I've found so far:
Edit /etc/xdg/lxsession/LXDE/autostart to append:
@xset -s off
@xset s noblank
- Download Cygwin (http://www.cygwin.com/)
- Install Cygwin, selecting the autossh package.
- Start the Cygwin shell (Start -> Programs -> Cygwin).
- Generate a public/private key pair.
- At the command line, run: ssh-keygen
- Accept the default file locations
- Use an empty passphrase
- Copy your newly-created public key to the SSH server.
- scp .ssh/id_rsa.pub firstname.lastname@example.org:id_rsa.pub
- Add your public key to your list of authorized keys on the server.
- Login to your SSH server.
- mkdir .ssh
- cat id_rsa.pub >> .ssh/authorized_keys
- Test your key.
- Logout of your SSH sever.
- Login to your SSH server again. This time, your key will be used for authentication and you won't be challenged for your login credentials. If you are not logged in automatically, review the previous steps. Or contact your server administrator.
- Logout of your SSH server.
- Exit of the Cygwin shell.
- Install autossh as a Windows service.
- Now back in Windows, open a new command Window (Start -> Run -> cmd).
- cd C:\cygwin\bin
- cygrunsrv -I AutoSSH -p /usr/bin/autossh -a "-M 20000 -L localaddress:port:serveraddress:port email@example.com" -e AUTOSSH_NTSERVICE=yes
- Tweak Windows service settings.
- Open the Services management console (Administrative Tools -> Services).
- Edit the properties of the AutoSSH service.
- In the "Log On" tab, select the "This account" radio button and set the service to run as your current user.
- Start the service.
- Test your tunnels.
- Consider making a scheduled task to start the service every hour or so, in case autossh goes boom.
On this thin client I've set up, I wanted pulseaudio to run before logging in, and not have any specific users on the machine. System mode was called for.
On Wheezy, pulseaudio is by default configured for per-user sessions. To remedy this, edit /etc/default/pulseaudio, putting PULSEAUDIO_SYSTEM_START=1
Then, edit /etc/pulse/system.pa - this is the file that configures the server when system mode is used, as opposed to /etc/pulse/default.pa. At the end of said file, I added two lines and some comments:
### Enable TCP and CLI load-module module-native-protocol-tcp port=1500 auth-anonymous=1 load-module module-cli-protocol-unix
Please keep in mind that the above tcp line allows access from any host. This is a potential security problem. I restrict access using shorewall and iptables, but an alternative would be the auth-ip-acl option with a list of approved IP's. More here. Restart pulseaudio:
/etc/init.d/pulseaudio start /etc/init.d/pulseaudio restart
The above restart includes "start", because pulseaudio's default script does not start it on "restart" unless it's not already running. Stupid.
Because pulseaudio now runs as the "pulse" user, commands like pacmd are a pain to use. However, as we made sure to load module-cli-protocol-unix above, they are actually usable, you just have to run them as the "pulse" user, and point it at the correct directory.
sudo PULSE_RUNTIME_PATH=/var/run/pulse -u pulse pacmd
To get access to playing sound, you now need to run anything as "pulse"... or you can simply use the TCP socket you made. Edit /etc/pulse/client.conf and set "default-server" to "localhost:1500" or similar:
default-server = localhost:1500
Now set up SSH port forwarding for port 1500, or whichever port you used above, with something like autossh and public key logins, and you've got remote sound playing over an encrypted tunnel. Neat.
Remember to set the default-server for client computers as well.
On my Debian KVM hosts, and on the firewalls that guard them, I noticed that every two minutes, plus a couple seconds or so each time, I'd see blocked IGMP packages from 0.0.0.0 to 126.96.36.199. Googling around, I found this post, explaining that it's the multicast_snooping option for bridge-utils that's causing it. Being KVM hosts, they are indeed configured with bridges.
I added the following line to my Bash startup scripts in /etc/rc.local, and the issue is now gone:
( shopt -s nullglob; for ms in /sys/devices/virtual/net/br*/bridge/multicast_snooping; do echo -n 0 >"$ms"; done )
In short, it runs a subshell, sets the nullglob option to prevent running on a file with an asterisk in the name if no bridges were found, then puts a 0 into all found multicast_snooping configuration files. Problem solved!
Note: If you use virtual interfaces, those are in /sys/devices/virtual/net/virbr and require the same treatment.
Programs like virt-manager and gedit commonly use dbus. Dbus running will prevent a clean exit of ssh -X, making it hang on exit until you press ctrl+c or kill dbus manually.
To avoid having to kill dbus manually, let's kill it automatically
Now, normally if I want to run virt-manager (or anything else graphical) on a remote machine with X forwarding, I'd use a command like
ssh -X root@remote-server virt-manager
Instead, I want to use dbus' ability to output sh-compatible commands to set invironment variables and kill the PID I get from that before exiting, like so:
ssh -X root@remote-server 'eval $(dbus-launch --close-stderr --sh-syntax); virt-manager --no-fork; kill -TERM $DBUS_SESSION_BUS_PID'
Problem solved! The remote shell (bash) now starts dbus manually instead of letting virt-manager do it, waits for virt-manager to exit (--no-fork), then kills dbus and exits.
On a single user desktop, you might want to run cygwin sshd autostarted as a specific user, without privilege separation. Here's a short reference:
- Disable UAC
- Open a Cygwin terminal
- Select "no" on privilege separation
- Enter nothing, , as the value of CYGWIN for the daemon
- Select "yes" to use a different username than cyg_server
- Enter your username, twice
- Enter your password, twice
- Edit (with your favorite editor) /etc/sshd_config
- Edit the UsePrivilegeSeparation line to say "UsePrivilegeSeparation no" (why the hell didn't step 4 do this?)
- Go to the windows firewall settings (just type "firewall" into the start menu search - look under "settings")
- Go to "advanced settings"
- Go to "Inbound rules"
- Add a new rule
- Select "Port"
- Select "TCP" and enter "22" as the specific local port
- Select "Allow the connection"
- Select when to apply the rule (default all cases)
- Give it a name, like "SSH"
If you later change your password, you will have to start "services.msc", find the Cygwin ssh service and change your credentials on it as well.
After IE6, usernames and passwords in URL's are no longer enabled by default in Internet Explorer, the reasoning being that saving usernames and passwords in the browser history and referral headers is a very, very bad idea. Still, it's sometimes needed, especially when dealing with old IP cameras, which is when I last bumped into this issue.
If you're not sure what I'm on about, I'm referring to links like these: http://user:firstname.lastname@example.org/
To re-enable this feature:
- Open RegEdit (Start->Run->"regedit")
- Navigate to [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE].
- Create two new REG_DWORD values, set to 0, named "iexplore.exe" and "explorer.exe"
While public and private keys with decent pass-phrases are an excellent way of logging in securely to a remote system, it's sometimes simply not feasible. Your Android device which normally does the job for you is out of battery, you are in a remote country with only a wired connection in a shady Internet café, or - <diety> forbid - your laptop was stolen while logged in and you desperately need to get on that system right now.
Anyway, one-time passwords, implemented as "opie" in earlier Debian versions, are now available as "otpw". These allow you to generate securely stored single-use passwords that are safe to use "in the field", and even have counter-measures to attacks like a keylogger opening several SSH connections to your host, trying to guess the last character of the one-time password before you type it.
The following guide will disable the use of ordinary passwords, keeping public/private key login enabled, followed by otpw if no key is provided. Thus, you can log in with your key if you have one, without being asked for a one-time password, but if you don't provide one you get the password prompt.
To install this beauty, we need the pam module and the client program:
apt-get install libpam-otpw otpw-bin
Next, we need to configure /etc/pam.d/sshd to use the newly installed module. For my setup, I want to disable normal passwords, so I comment out the common-auth line, then add otpw.
# Standard Un*x authentication. #@include common-auth #OTPW auth required pam_otpw.so session optional pam_otpw.so
/etc/ssh/sshd_config needs some changes too. These are the relevant lines:
ChallengeResponseAuthentication yes PasswordAuthentication no PubkeyAuthentication yes UsePrivilegeSeparation yes
The only really important line is the ChallengeResponseAuthentication one, which is what we'll be using for otpw. Public keys and privilege separation are normally enabled by default, and as I mentioned I wanted to disable PasswordAuthentication, which covers the use of normal account passwords.
Because we changed the config, we need to restart sshd:
# /etc/init.d/ssh restart
Time to generate some one-time passwords:
$ otpw-gen --help One-Time Password Generator v 1.2 -- Markus Kuhn otpw-gen [options] | lpr Options: -h <int> number of output lines (default 60) -w <int> max width of output lines (default 79) -s <int> number of output pages (default 1) -e <int> minimum entropy of each one-time password [bits] (low security: <30, default: 48, high security: >60) -p0 passwords from modified base64 encoding (default) -p1 passwords from English 4-letter words -f <filename> destination file for hashes (default: ~/.otpw) -d output debugging information $ otpw-gen -h 20 -e 48 -p1 Generating random seed ... If your paper password list is stolen, the thief should not gain access to your account with this information alone. Therefore, you need to memorize and enter below a prefix password. You will have to enter that each time directly before entering the one-time password (on the same line). When you log in, a 3-digit password number will be displayed. It identifies the one-time password on your list that you have to append to the prefix password. If another login to your account is in progress at the same time, several password numbers may be shown and all corresponding passwords have to be appended after the prefix password. Best generate a new password list when you have used up half of the old one. Enter new prefix password: Reenter prefix password: Creating '~/.otpw'. Generating new one-time passwords ... OTPW list generated 2013-01-24 23:17 on slave 000 csce stub neat rope down 016 keep ness mine mock bile 001 pubs ever judo pert kemp 017 blip stan nana file shaw 002 ecsc bone hare hiss make 018 serb ills swam torn rump 003 page type owen dark lent 019 avid bran avid amps lair 004 unto hype fits bets loco 020 putt rout disc gogh bile 005 kits hard sums lime sore 021 hand rash rigs eels vain 006 foci path call spat tins 022 ship what loos chin pine 007 vote sold book gait name 023 yolk mont pubs main kilt 008 band cone draw mats fact 024 para must mala curd tire 009 oboe mill hair chad mont 025 pope slid olds ores dive 010 maps head frog eden teal 026 bony leas bcci jerk need 011 chas memo ives duck revd 027 womb pahl bird ruby naff 012 graf gosh rays roar pour 028 obey bear iona area gain 013 slab sons damn dell pass 029 sort jazz sega rigs onus 014 erik rags tact roar rags 030 lost lump cubs seat film 015 bees aces thee pump kant 031 aura road funk laid hibs !!! REMEMBER: Enter the PREFIX PASSWORD first !!!
Now you should be good to go. The next time you connect, you'll be asked for one, or three, one-time passwords. Three passwords are requested when multiple logins happen simultaneously and other potentially suspicious situations. See /usr/share/doc/otpw-bin/otpw.html for details.
REMEMBER: The password you typed as your "prefix password" has to be entered before the password otpw asks for. If my prefix password was "hello", and the application asked for password 031, I'd enter "helloauraroadfunklaidhibs". Spaces can be typed if you want, but they are ignored.
This is what a typical login looks like for me.
$ ssh home.sweet.home -l bolt Password 026: <This would be hellobonyleasbccijerkneed if my prefix password was still "hello"> Linux home.sweet.home 3.2.0-4-686-pae ..........
That's about it. Remember there is no reason your prefix password needs to match your actual password on that system. They have no relation. It is a good idea to choose a different prefix password, especially if you happen to have "sudo" installed and set up for your user, so you're not typing a password that can potentially make you root to log in from a shady web café. Someone just might take over your machine.
There is, at the time of writing, a bug in Debian Wheezy preventing the "session optional pam_otpw.so" line from displaying a count of your remaining one-time passwords upon a successful login. Until that is resolved, you might want to add the small snippet Wolfgang Kroener posted on the bug to your login scripts.