Archive for the ‘Cygwin’ Category

sshd service stopped, exist status 255

Friday, April 20th, 2018

I had one server with an sshd service which would terminate right after starting.

The event log would have the following error:

The description for Event ID 0 from source sshd cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

sshd: PID 9960: `sshd' service stopped, exit status: 255

Not too helpful of a message.

I decided to re-run the setup with an elevated Cygwin terminal.

ssh-host-config

*** Info: Generating missing SSH host keys
*** Query: Overwrite existing /etc/ssh_config file? (yes/no) yes
*** Info: Creating default /etc/ssh_config file
*** Query: Overwrite existing /etc/sshd_config file? (yes/no) yes
*** Info: Creating default /etc/sshd_config file

*** Info: StrictModes is set to 'yes' by default.
*** Info: This is the recommended setting, but it requires that the POSIX
*** Info: permissions of the user's home directory, the user's .ssh
*** Info: directory, and the user's ssh key files are tight so that
*** Info: only the user has write permissions.
*** Info: On the other hand, StrictModes don't work well with default
*** Info: Windows permissions of a home directory mounted with the
*** Info: 'noacl' option, and they don't work at all if the home
*** Info: directory is on a FAT or FAT32 partition.
*** Query: Should StrictModes be used? (yes/no) yes

*** Info: Privilege separation is set to 'sandbox' by default since
*** Info: OpenSSH 6.1. This is unsupported by Cygwin and has to be set
*** Info: to 'yes' or 'no'.
*** Info: However, using privilege separation requires a non-privileged account
*** Info: called 'sshd'.
*** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep.
*** Query: Should privilege separation be used? (yes/no) yes
*** Info: Note that creating a new user requires that the current account have
*** Info: Administrator privileges. Should this script attempt to create a
*** Query: new local account 'sshd'? (yes/no) no
*** ERROR: Couldn't create user 'sshd'!
*** ERROR: Privilege separation set to 'no' again!
*** ERROR: Check your /etc/sshd_config file!
*** Info: Updating /etc/sshd_config file

*** Info: Sshd service is already installed.




*** Warning: Host configuration exited with 1 errors or warnings!
*** Warning: Make sure that all problems reported are fixed,
*** Warning: then re-run ssh-host-config.

After that.  The service stayed up.

Make sure you verify the access.  This particular server had sshd configured for one login and of course I didn’t have the password.

 

 

Advertisement

Scriptblock doesn’t work with variables.

Friday, October 10th, 2014

Powershell is a fun experience which I wish I had started awhile ago.  It’s features seem endless and it greatly eases system management.

The recent scare over Shellshock caused us to evaluate our Cygwin installations.  We didn’t know the exact number of installations and the version of Bash in use.

The question of the number of Cygwin installations was easy to solve. A script to review the organization units and scan each computer for Cygwin.

After a list was generated; a script was written and three results files were created: Found, System Down, and Not Found.

Cygwin due to it’s open source nature does not follow Microsoft design standards.  It has it’s own way of doing things. Good for the user but not always good for system management purposes.

I didn’t find a “Quick and Dirty” way to get the version number of the Bash executable.   Nothing in the registry and file information lacked details.

Redhat (we use them for support) advised using the “–version” option to identify the version.  A rather tedious task if done through remote desktop or nagging the users to send the information.

What would be nice if there was way to run a command remote and get the information.

Powershell has a nice option called “invoke-command.” It’s a one use option for such things.

The command is rather simply to use:

Invoke-Command -scriptblock { c:\cygwin\bin\bash –version }  -computername <hostname>

This gave the following output:

GNU bash, version 4.1.15(1)-release (i686-pc-cygwin)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

A little too much detail for a version number.  This was quickly addressed by using Select-String command.

Invoke-Command -scriptblock { c:\cygwin\bin\bash –version }  -computername <hostname> | Select-String -pattern “GNU bash, version”

This in turn gave:

GNU bash, version 4.1.15(1)-release (i686-pc-cygwin)

This was usable.  It also helped with simple errors.  If you don’t get the expected result, add an error message. This became evident when trying to run the command on Windows 2003 which lacked Powershell 2.0 and systems which did not have remote management configured.

Invoke-Command is great.  It gave me the information I needed without visiting each system.

I wrote a script and quickly found two problems:

  1. There are flavors of Cygwin and unless there was a conscious effort during install; you could end up with different directories (ie: C:\cygwin, C:\cygwin64, C:\rhcygwin).
  2. Running the command for several systems.  Invoke-Command can take up to five systems.  Great for a small number but not so great when you have hundreads or more.

Both of these issues required the use of variables and it was quickly discovered that -scriptblock option couldn’t use variables. For example:  $cygwinPath\bash.exe –version resulted as \bash.exe –version

The dynamic nature of scanning several computers was not something the command could do.  Rather then use another approach; I looked around the Net and found there was a way to use dynamic scriptblocks by using the NewScriptBlock command.

A quick change:

$scriptblock = $ExecutionContent.InvokeCommand.NewScriptBlock( “$cygwinPath\bash.exe –version”)
$versionResult = Invoke-Command -scriptblock $scriptblock -computername $server | Select-String -pattern “GNU bash, version”

This gave the needed results and we had an understanding of the work needed to be done.

If you would like to read more about Invoke-Command, Ed Wilson did a nice little writeup on his blog.

What is my version of cygwin?

Wednesday, June 18th, 2014

Cygwin is a *nix-like interface for windows.  Like all applications, it has versions and sometimes that can be an issue.

There is the command:

cygcheck -srv

But, there is a great deal of information so you would have to use grep to get what you need.

A quick and simple approach would be the old trusty “uname” command.

 ~
$ uname -srv
CYGWIN_NT-6.1-WOW64 1.8.3(0.237/5/3) 2011-03-30 12:12

 ~
$ uname -r
1.8.3(0.237/5/3)

Now if only I could convince some people you don’t have to stay at a version forever. 😉