Chris Jean

Change Ubiquiti Access Point SSH Username, Password, and Keys

In an earlier article, I talked about how I recently set up a Ubiquiti access point (model UAP-AC-PRO-US). There are a variety of commands you can run directly on the access point by logging in via SSH. In order to do this, you may need to modify the login credentials. This article will show you how to make these changes.

Note that the access point must be adopted and provisioned by the UniFi controller before you can manage the SSH authentication credentials.

The username, password, and SSH keys can all be managed from the same place. To modify the credentials, do the following:

Log into the UniFi controller.
Go to Settings (the gear icon in the bottom-left of the page).
Go to the Site section (this is the default section you go to when going to the Settings page).
Make the desired changes in the “DEVICE AUTHENTICATION” section at the bottom of the page.
Click the “APPLY CHANGES” button.

After applying the changes, the adopted access points should automatically update with these new credentials. If you wait a minute or so and the new credentials do not work yet, you can force the changes onto an access point by doing the following:

Log into the UniFi controller.
Go to Devices (the nested circles icon towards the top-left of the page).
Click on the access point that needs updating. This will pop open a panel on the right side of the page.
Click the Config icon (it looks like a gear) at the top middle of the device’s panel.
Click “MANAGE DEVICE” in the device’s panel. Note: You may need to scroll to see this section.
Click the “Provision” button under the “Force provision” section.

After following these steps, the access point’s status will change to “PROVISIONING”. The changes should only take a few seconds to finish. Once the access point’s status changes back to “CONNECTED”, you should be able to SSH into the access point using the updated credentials.

Categories Tips 'n Tricks
Comments (3)

SSH Into Ubiquiti Access Point

I recently set up a Ubiquiti access point (model UAP-AC-PRO-US). Part of the process required me to log into the access point, but I could not find any connection details such as the port, username, or password. After a bit of digging, I figured it out.

Logging into AP before it is adopted

When your access point is new and hasn’t been connected to your UniFi controller yet, the default SSH credentials are:

Port: 22
Username: ubnt
Password: ubnt

You can find the IP address for the access point listed in the UniFi controller’s Devices page. In my case, the IP address was 10.0.0.103. To log in, I ran the following command from my terminal:

[chris@home ~]$ ssh ubnt@10.0.0.103
ubnt@10.0.0.103's password: ubnt

BusyBox v1.25.1 () built-in shell (ash)


  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2019
 |   |  |   |  \  ||  \   |  |   Ubiquiti Networks, Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com/

      Welcome to UniFi UAP-AC-Pro-Gen2!

UBNT-BZ.v4.0.21#

Logging into AP after it is adopted

If the access point is already adopted and provisioned, the UniFi controller changed the SSH login credentials for it. If your UniFi controller already manages other access points, the new access point’s SSH credentials are changed to the same credentials. If this is the first access point added to the UniFi controller, the new username is admin and the password was randomized.

If you need to change the SSH login credentials for the access point, please read this article.

To find the IP address for your access point, log into your UniFi controller and go to the Devices page. Assuming that the access point’s IP is 192.168.1.5, the username is admin, and the password is password (please do not use this as your password), you can SSH into the access point with a command such as the following:

[chris@home ~]$ ssh admin@192.168.1.5
ubnt@192.168.1.5's password: password

BusyBox v1.25.1 () built-in shell (ash)


  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2019
 |   |  |   |  \  ||  \   |  |   Ubiquiti Networks, Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com/

      Welcome to UniFi UAP-AC-Pro-Gen2!

UBNT-BZ.v4.0.21#

Fix “no matching MAC found”

Your system’s SSH client might have restrictions that prevent the commands above from working properly. For example, you might run into the following issue:

[chris@home ~]$ ssh ubnt@10.0.0.103
Unable to negotiate with 10.0.0.103 port 22: no matching MAC found. Their offer: hmac-sha1,hmac-md5
[chris@home ~]$

This can be fixed by supplying an additional option to the ssh command as shown below.

[chris@home ~]$ ssh -o MACs=hmac-sha1,hmac-md5 ubnt@10.0.0.103
ubnt@10.0.0.103's password: ubnt


BusyBox v1.25.1 () built-in shell (ash)


  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2019
 |   |  |   |  \  ||  \   |  |   Ubiquiti Networks, Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com/

      Welcome to UniFi UAP-AC-Pro-Gen2!

UBNT-BZ.v4.0.21#

Categories Tips 'n Tricks
Comments (2)

Finding and Purging Unpurged Packages on Ubuntu

When you remove a package (such as sudo apt remove php5.5-cgi), all files added by the package will be deleted except for user configuration files that were modified. When you purge a package (such as sudo apt purge php5.5-cgi), all the package files, including modified configuration files, are deleted. After a few years, your Ubuntu installation may start to accumulate old packages that were removed but not purged. Fortunately, it is easy to find those unpurged packages and purge them.

The dpkg command can provide us with a list of removed, unpurged packages:

[chris@home ~]$ dpkg --list | grep ^rc
rc  php5.5-cgi       5.5.38-4+deb.sury.org~xenial+1  amd64  server-side, HTML-embedded scripting language (CGI binary)
rc  php5.5-cli       5.5.38-4+deb.sury.org~xenial+1  amd64  command-line interpreter for the PHP scripting language
rc  php5.5-common    5.5.38-4+deb.sury.org~xenial+1  amd64  documentation, examples and common module for PHP
rc  php5.5-json      5.5.38-4+deb.sury.org~xenial+1  amd64  JSON module for PHP
rc  php5.5-opcache   5.5.38-4+deb.sury.org~xenial+1  amd64  Zend OpCache module for PHP
rc  php5.5-readline  5.5.38-4+deb.sury.org~xenial+1  amd64  readline module for PHP
[chris@home ~]$

The dpkg command is Ubuntu’s package manager. The apt, aptitude, apt-get, and other apt-* commands are simply wrappers around dpkg. Calling dpkg --list creates a listing of all the packages on the system. Filtering the output by piping it through grep ^rc results in only showing the removed but unpurged packages (the ^rc pattern means that only lines beginning with “rc” should be output). The “r” in “rc” means that the package was removed while the “c” means that the config files remain.

We can use awk to get a listing of just the package names:

[chris@home ~]$ dpkg --list | grep ^rc | awk '{ print $2; }'
php5.5-cgi
php5.5-cli
php5.5-common
php5.5-json
php5.5-opcache
php5.5-readline
[chris@home ~]$

The awk command processes and manipulates string. By default, when awk reads each line of input, it will separate the input into a series of fields separated by runs of whitespace. You can refer to a specific field by using $NUMBER. In this instance, we tell it to print the second field by using { print $2; }. This results in a listing of just the package names.

Now that we have our names, we just need to purge each one:

[chris@home ~]$ sudo apt purge `dpkg --list | grep ^rc | awk '{ print $2; }'`
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  php5.5-cgi* php5.5-cli* php5.5-common* php5.5-json* php5.5-opcache* php5.5-readline*
0 upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 432300 files and directories currently installed.)
Removing php5.5-cgi (5.5.38-4+deb.sury.org~xenial+1) ...
Purging configuration files for php5.5-cgi (5.5.38-4+deb.sury.org~xenial+1) ...
dpkg: warning: while removing php5.5-cgi, directory '/etc/php/5.5/cgi/conf.d' not empty so not removed
Removing php5.5-cli (5.5.38-4+deb.sury.org~xenial+1) ...
Purging configuration files for php5.5-cli (5.5.38-4+deb.sury.org~xenial+1) ...
dpkg: warning: while removing php5.5-cli, directory '/etc/php/5.5/cli/conf.d' not empty so not removed
Removing php5.5-common (5.5.38-4+deb.sury.org~xenial+1) ...
Purging configuration files for php5.5-common (5.5.38-4+deb.sury.org~xenial+1) ...
dpkg: warning: while removing php5.5-common, directory '/etc/php/5.5/mods-available' not empty so not removed
Removing php5.5-json (5.5.38-4+deb.sury.org~xenial+1) ...
Purging configuration files for php5.5-json (5.5.38-4+deb.sury.org~xenial+1) ...
Removing php5.5-opcache (5.5.38-4+deb.sury.org~xenial+1) ...
Purging configuration files for php5.5-opcache (5.5.38-4+deb.sury.org~xenial+1) ...
Removing php5.5-readline (5.5.38-4+deb.sury.org~xenial+1) ...
Purging configuration files for php5.5-readline (5.5.38-4+deb.sury.org~xenial+1) ...
[gaarai@samus ~]$

By surrounding command to get the listing of packages with backticks (`), the output of that entire command can be used as an argument for another command. In this case, the output is used to tell the apt command to purge the packages.

Note the warnings stating that specific directories were not removed. I checked each of these directories, found that there were empty, and removed them manually.

Categories Uncategorized
Comments (1)

What is some.address.it.wont.ever.reach@lookup.and.try.to.find.this.host.name

Did you just receive some mail notifications saying that mail could not be delivered to some.address.it.wont.ever.reach@lookup.and.try.to.find.this.host.name? Fear not. This isn’t some kind of weird hack or compromise of your system. In all likelihood, someone just compiled PHP on the server.

PHP’s unit test to confirm that bug 72463 remains fixed makes two mail() calls that try to send mail to that address. The email address was specifically chosen to ensure that it would not refer to a real email address while still remaining a valid email address, thus the reason for the mail handler on the server sending the error stating that the mail could not be sent.

So, there’s no problem. It’s just PHP’s unit tests doing their job when someone runs make test.

Categories Random Ramblings
Comments (0)

Quickly clear Postfix’s mail queue

I recently did some work on an Ubuntu server with a compromised PHP site that was sending out massive amounts of spam email messages. After removing the offending scripts, I needed to clear out the mail queue to ensure that the server was not attempting to send backlogged spam messages.

The server in question is running Postfix as the MTA (Mail Transfer Agent) rather than Sendmail. Fortunately, clearing the entire queue was as easy as running the following:

[user@server ~]$ sudo postsuper -d ALL
postsuper: Deleted: 69967 messages
[user@server ~]$

If your server runs Sendmail, you will have to manually clear the mail queue by removing all the files at /var/spool/mqueue/. For example:

[user@server ~]$ sudo rm -f /var/spool/mqueue/*
[user@server ~]$

Categories Linux, Tips 'n Tricks
Comments (0)

Fix Bitbucket API “project Select a valid choice. That choice is not one of the available choices” Error

I rely on Bitbucket’s API heavily to manage repositories at iThemes. Recently, some of the API calls started to fail and returned nonsensical error messages.

When making a PUT request to the /1.0/repositories/TEAM/SLUG endpoint, I received an error response with a status code of 400 and the following message:

<ul class="errorlist"><li>project<ul class="errorlist"><li>Select a valid choice. That choice is not one of the available choices.</li></ul></li></ul>

This message makes no sense as the documentation for that endpoint has no mention of a parameter named project.

Going directly to bitbucket.org and trying to create a new repository there revealed that a new, required Project input is now on the form. This explains where the error message is coming from. It looks as though they added the new parameter to the repositories, made it mandatory, and updated the API endpoint to reflect this new mandatory parameter, but failed to update the documentation or to have any backwards-compatible support.

I found that supplying the project parameter with a value of PROJ (the default value in the form) got rid of the error message.

Categories Tips 'n Tricks
Comments (0)

Customize Ubuntu Unity’s Time & Date Indicator

Ubuntu’s time and date indicator in Unity is a bit blah for my tastes. With the default settings on my system, it currently says “7:39 AM”. That’s accurate, but it could be much more helpful.

You can load up the Time & Date application from the dash, click the Clock tab, and customize the appearance a bit. However, the options offered in the application are very limited compared to what the indicator is capable of supporting. Sure, you can change it to the following with a few checkboxes “Thu Mar 26 2015 7:39:11 AM” or toggle it to a 24-hour time, but it really doesn’t look that nice to me.

Fortunately, the indicator can be set to a custom mode which supports all the options offered by the strftime function.

To set up your custom indicator, first make sure that you have the clock indicator enabled:

[chris@work ~]$ gsettings set com.canonical.indicator.datetime show-clock true

Next, set the indicator to use the custom format:

[chris@work ~]$ gsettings set com.canonical.indicator.datetime time-format custom

Finally, set your indicator format:

[chris@work ~]$ gsettings set com.canonical.indicator.datetime custom-time-format "%A, %B %e  %l:%M %P"

This changes my indicator to say “Thursday, March 26 7:40 am”.

The different options that can be used in the format string can be found on the strftime function’s man page.

Categories Linux, Tips 'n Tricks
Comments (1)

Fix “lxc_container: cgmanager.c: cgm_attach: 1291 Failed to get cgroup for controller all”

I’ve been tinkering around with LXC containers on my Ubuntu systems. While setting up my user for unprivileged usage, I ran into the following problem:

[chris@server ~]$ lxc-attach -n u1
lxc_container: cgmanager.c: cgm_attach: 1291 Failed to get cgroup for controller all
lxc_container: attach.c: lxc_attach: 847 error communicating with child process
[chris@server ~]$

After a bit of tinkering around, I found that there is a bug that is causing this issue. Adding the LXC daily build PPA and updating fixed the issue for me. I did this as follows:

[chris@server ~]$ sudo apt-add-repository ppa:ubuntu-lxc/daily
 Those are daily builds of the master branch of git://github.com/lxc/lxc for all supported versions of Ubuntu.

Required or recommended dependencies are also backported from current Ubuntu and included in this PPA to provide an identical LXC experience on all supported Ubuntu releases.
 More info: https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/daily
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpovs0swu3/secring.gpg' created
gpg: keyring `/tmp/tmpovs0swu3/pubring.gpg' created
gpg: requesting key 7635B973 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpovs0swu3/trustdb.gpg: trustdb created
gpg: key 7635B973: public key "Launchpad PPA for Ubuntu LXC team" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
[chris@server ~]$ sudo aptitude update && sudo aptitude full-upgrade -y
...
The following NEW packages will be installed:
  lxcfs{a}
The following packages will be upgraded:
  liblxc1 lxc lxc-templates python3-lxc
4 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 794 kB of archives. After unpacking 12.3 kB will be used.
Writing extended state information...
...
Building tag database...
[chris@server ~]$ lxc-attach -n u1
root@u1:/# exit

Hopefully this fix will make it out to the default repos soon, as I don’t typically like to use daily repos if I can avoid them.

Categories Linux, Tips 'n Tricks
Comments (0)

Ubuntu SSH Fix for “Agent admitted failure to sign using the key”

For the past few weeks I’ve had problems logging into servers using my SSH keys from Ubuntu desktops. The following would happen each time:

[chris@work ~]$ ssh server
Agent admitted failure to sign using the key.
Permission denied (publickey).
[chris@work ~]$

Oddly, this only happened from my Ubuntu desktop systems. My Ubuntu servers had no issue connecting.

After some digging, I found out that issues with the gnome-keyring were at fault. gnome-keyring doesn’t always handle specific formats of SSH keys correctly. Unfortunately, gnome-keyring was trying to handle all SSH key usage, preventing the keys from working.

If you are having this issue, you can confirm that gnome-keyring is at fault on your system by added SSH_AUTH_SOCK=0 in front of the ssh command as follows:

[chris@work ~]$ SSH_AUTH_SOCK=0 ssh server
Welcome to Ubuntu 14.10 (GNU/Linux 3.13.0-37-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

0 packages can be updated.
0 updates are security updates.

Last login: Wed Mar 11 11:49:50 2015 from host
[chris@work ~]$

If the connection works, then you likely have the same problem that I had. If the connection does not work, please read the Fixing other sources of agent failure section below for further ideas to fix your problem.

Fixing gnome-keyring interference

In order to fix the gnome-keyring interference, the “SSH Key Agent” will have to be disabled from the startup applications. In Unity’s dash, search for “startup” and select “Startup Applications”. This lists the programs that automatically run when your user logs in.

If you see “SSH Key Agent”, uncheck the box and reboot. After you log back in, your ssh connections should work normally.

If you do not see “SSH Key Agent”, you are reading this before the update has been released for your version of Ubuntu. You will first have to update your system to install pre-release updates. To do this, open up Unity’s dash, search for “software”, and select “Software & Updates”. Select the “Updates” tab. Enable the “Pre-released updates” option, provide your user password if requested, and click the “Close” button. If a dialog pops up saying “the information about available software is out-of-date”, click the “Reload” button and wait for the update to finish. Open up Unity’s dash, search for “software” again, and select “Software Updater”. Confirm any dialogs and provide your password if requested. This will install the updates that you just made available. After this is done, reboot your system.

After the reboot, open Unity’s dash, search for “startup” and select “Startup Applications”. Uncheck the option for “SSH Key Agent” and reboot. After you log back in, your ssh connections should work normally.

Note: Details about this bug and the update allowing for disabling the “SSH Key Agent” can be found in Bug #1387303 in Ubuntu’s bug tracker.

Fixing other sources of agent failure

If using SSH_AUTH_SOCK=0 in front of the ssh command does not fix your issue, your system could either not have an SSH agent available that provides the keys to the ssh process or the agent is not loaded with your keys.

The most simple thing to check is if running ssh-add can fix the issue. For example:

[chris@work ~]$ ssh-add
Identity added: /home/chris/.ssh/id_rsa (/home/chris/.ssh/id_rsa)
[chris@work ~]$

This means that your SSH agent was running, but it did not have your keys loaded. After this, see if you are now able to login successfully.

Another possibility is the following:

[chris@work ~]$ ssh-add
Could not open a connection to your authentication agent.
[chris@work ~]$

This means that you do not have an SSH agent running. To fix this, do the following:

[chris@work ~]$ eval "$(ssh-agent -s)"
Agent pid 9267
[chris@work ~]$ ssh-add
Identity added: /home/chris/.ssh/id_rsa (/home/chris/.ssh/id_rsa)
[chris@work ~]$

After this, you should be able to ssh into servers that you have valid keys for.

If you see the following:

[chris@work ~]$ ssh server
Permission denied (publickey).
[chris@work ~]$

This means that your keys have loaded, but your keys are not authorized to access the server.

Categories Linux, Tips 'n Tricks
Comments (17)

Restart the Network in Ubuntu from SSH

I recently set up an IPv6 interface on a remote Ubuntu server. In order to finish this change, I needed to restart the interface. A while back, I would have used sudo service networking restart, but that doesn’t work very well any more:

[chris@server ~]$ sudo service networking restart
stop: Job failed while stopping
start: Job is already running: networking
[chris@server ~]$

After doing some more reading, I found that restarting the networking service can have some bad side effects in Ubuntu, so they more or less prevented this from working. The correct way is to manually bring the interface that needs to be restarted down and back up.

The interface that I’m working with is named eth0. Your interface could be named eth1, em1, or many other names. So, when following my examples, make sure to replace eth0 with the name of your interface.

If the /etc/network/interfaces file was updated when making your network changes, you can run the following to run a basic syntax check on the file. It won’t tell you if you made a mistake on the IP address or other configuration details specific to your network setup, but it can catch simple syntax errors.

[chris@server ~]$ sudo ifup -n eth0
ifup: interface eth0 already configured
[chris@server ~]$

The -n tells ifup to not actually take any actions, thus allowing for a quick syntax check of the /etc/network/interfaces file. The “interface eth0 already configured” message indicates that no configuration issues were found. The following shows what happens when a configuration error was found.

[chris@server ~]$ sudo ifup -n eth0
/etc/network/interfaces:20: unknown address type
ifup: couldn't read interfaces file "/etc/network/interfaces"
[chris@server ~]$

This indicates that a problem was found on line 20 of the configuration file. In this specific instance, I accidentally put “int6” instead of “inet6”.

Now that we know that the config file doesn’t have any syntax issues, the following one-liner takes the eth0 interface down and then back up:

[chris@server ~]$ sudo ifdown eth0 && sudo ifup eth0
Waiting for DAD... Done
[chris@server ~]$

And with that, the interface now has the new config.

Categories Linux, Tips 'n Tricks
Comments (0)