Tuesday, June 19, 2018

Horizon View Dell OpenManage manual install via esxcli

If you have Dell OpenManage vib and wish to install it via the shell, you'll see something like this on various sites and blogs:

esxcli software vib install -d OM-Srv....zip  
in some older articles you'll see --depot instead of -d as well

It is quite fussy about paths, it won't work even if you're in the directory containing the zip file, you still need to reference the full path. I had a 4 hosts to run this on so I copied from shared vSAN data store to /tmp and ran it on each as so:

esxcli software vib install -d=/tmp/OM-SrvAdmin-Dell-Web-9.1.0-2757.VIB-ESX65i_A00

Note I've added in an equals sign. I suggest putting a space before OM and hitting tab, as it won't otherwise autocomplete which is annoying. Then delete the space after using ctrl and left cursor to jump back quickly.

Hope this saves somebody a few mins of messing. There is a method for adding all of this into vCenter as a converged package but it's a licenced paid extra from Dell. There's also a graphical method of doing this via Update Manager in ESXi using an online pull method from http://vmwaredepot.dell.com/  which probably scales better but it may force automatic maintenance mode where that isn't strictly required to install this vib.

Tuesday, March 08, 2016

Bad usernames

There are a lot (a LOT!) of articles about bad and weak passwords. What about weak usernames?

I have a server with public facing sshd (stuck on standard port 22). Running this gives a rough idea of what default usernames are to avoid:

lastb -w | awk -F " " '{print $1}' | sort -n | uniq -c  | sort -n -r | more
     39 admin     29 oracle     21 test      9 user      9 postgres      8 guest      8 git      8 a      7 nagios      4 ubuntu      4 ftpuser      3 redmine      3 office      3 developer      3 b      3 alias      3 ADMIN      2 zhangyan      2 www      2 vyatta      2 ucpss      2 ubnt      2 tomcat      2 teamspeak3      2 teamspeak      2 steam

What else can be done besides passwordless ssh key only encryption for access? Well limiting exposure with fail2ban slows down any possibility of brute forcing and whitelisting by geo-locating IP addresses may help too: http://www.axllent.org/docs/view/ssh-geoip/
And of course only open the ports needed via firewall etc.

Wednesday, February 24, 2016

Mosh and SSH

I recently gave mosh a try. I'd read a bit about how useful it can be with unreliable connections and queuing commands and maintaining a local echo to screen as you type avoiding lag - all good stuff.

However using GNU screen (or tmux) solves a lot of the problems with reconnecting so I just never bothered. I was also under the impression that mosh and ssh were mutually exclusive when in fact they both work together. I was  concerned that installing mosh might break or hamper an exiting reliable ssh service. Well so far I've installed it on several systems and it's has no negative effects on sshd. And that's the point of this post. I could not find that information written anywhere on the web.

That's not to say it's been perfect. It is possible to orphan a mosh session to which you cannot reattach. That is a bit annoying if rare. It doesn't aid scp and  sftp transfers in terms of resumes. But that limitation doesn't bother me. Also there is no mosh support in putty (nor is there likely to be!) or its forks such as kitty which is disappointing if you use any windows systems. There are some mosh clients for windows but they're crippled versions of free or commercial packages or buggy cygwin hacks. Not against payware - there just isn't one around I like the look of.

On mobile platforms however, JuiceSSH implements mosh admirably. Highly recommended on the Android platform.

Mosh monitors active ssh connections on a high port so port 22 or equivalent isn't enough. It requires upd on an additional high port (~60001) to be opened on firewall etc. 

Tuesday, January 12, 2016

Filtering out old results from google search

For searching technical information, often it's the case that results older than a year may as well be in a glass case in a museum. If like me you're sick of scrolling through old results and various mouse clicks to set a suitable filter - append this to your search result:


Ideally the "m" for month can be replaced with a year "y" or even "h" for hour.
It would be better if there was a quickly typed search operator for this. But there isn't. There is a date range filter but it requires dates in Julian Calendar format - yuck.

Tuesday, April 21, 2015

Monitoring users ssh tunnels (port forwarding)

I hope this aids others faced with the same issue. The problem was as follows. We have have a number of remote users to a Linux system who need to access resources on some machines on a private network range. There are a number of solutions that could be employed such as VPN but for a variety of reasons we have decided to use ssh.

The tunneling works fine via the allocated ssh server. It is quite secure in that all users are given private keys and password access is disabled along with fail2ban. And from a usage perspective it has proven very robust. But this is all on the basis that your users are trusted. Ours are to a point, but we still need some more visibility and accountability.

Whilst sshd does log connections and you can increase that verbosity up to debug level in sshd_config, it still will not make a record anywhere of tunnels created. In short sshd only allows you disable or enable port forwarding globally or per user. We still need more!

One option is to manually patch ssh:

An alternative quick and dirty solution is what I've gone with. I've put a cron running a variant of this (also pipped into another grep to limit to specific username groups) every minute which feeds that into a log file in /var/log. In turn this is rotated daily and compressed.

lsof -i -n | egrep '\'

Something perhaps like this in a script:
date | tr '\n' ' '; lsof -i -n | egrep '\' | grep -v 22; printf '\n'

insert the date, trim newline characters, get rid of ordinary port 22 notices as they're already catered for in auth.log. You may need to alter slightly to suit your needs.

In crontab -e you can do something like:

*/1 * * * * /sbin/showtunnels.sh >> /var/log/sshd_tunnels

1 minute might be to verbose or insufficient depending on your system. Ideally it would be useful to report only the changes every minute rather than keep reporting the same tunnels still being open but that is another days work. This is very much a work in progress!