[Short Tip] Exit bad/broken/locked ssh sessions

Sometimes it happens that SSH connections lock up. For example due to weird SSH server configuration or bad connectivity on your side, suddenly your SSH connection is broken. You cannot send any more comments via the SSH connection. The terminal just doesn’t react.

And that includes the typical exit commands: Ctrl+z or Ctrl+d are not working anymore. So you are only left with the choice to close the terminal – right? In fact, no, you can just exist the SSH session.

The trick is:
Enter+~+.

Why does this work? Because it is one of the defined escape sequences:

The supported escapes (assuming the default ‘~’) are:
~.Disconnect.
~^Z Background ssh.
~# List forwarded connections.
~& Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate.
[…]

https://man.openbsd.org/ssh#EXIT_STATUS

To many of you this is probably nothing new – but I never knew that, even after years of using SSH on a daily base, so I had the urge to share this.

Advertisements

[Howto] Using include directive with ssh client configuration

A SSH client configuration makes accessing servers much easier and more convenient. Until recently the configuration was done in one single file which could be problematic. But newer versions support includes to read configuration from multiple places.

SSH is the default way to access servers remotely – Linux and other UNIX systems, and since recently Windows as well.

One feature of the OpenSSH client is to configure often used parameters for SSH connections in a central config file, ~/.ssh/config. This comes in especially handy when multiple remote servers require different parameters: varying ports, other user names, different SSH keys, and so on. It also provides the possibility to define aliases for host names to avoid the necessity to type in the FQDN each time. Since such a configuration is directly read by the SSH client other tools wich are using the SSH client in the background – like Ansible – can benefit from the configuration as well.

A typical configuration of such a config file can look like this:

Host webapp
    HostName webapp.example.com
    User mycorporatelogin
    IdentityFile ~/.ssh/id_corporate
    IdentitiesOnly yes
Host github
    HostName github.com
    User mygithublogin
    IdentityFile ~/.ssh/id_ed25519
Host gitlab
    HostName gitlab.corporate.com
    User mycorporatelogin
    IdentityFile ~/.ssh/id_corporate
Host myserver
    HostName myserver.example.net
    Port 1234
    User myuser
    IdentityFile ~/.ssh/id_ed25519
Host aws-dev
    HostName 12.24.33.66
    User ec2-user
    IdentityFile ~/.ssh/aws.pem
    IdentitiesOnly yes
    StrictHostKeyChecking no
Host azure-prod
    HostName 4.81.234.19
    User azure-prod
    IdentityFile ~/.ssh/azure_ed25519

While this is very handy and helps a lot to maintain sanity even with very different and strange SSH configurations, a single huge file is hard to manage.

Cloud environments for example change constantly, so it makes sense to update/rebuild the configuration regularly. There are scripts out there, but they either just overwrite existing configuration, or do entirely work on an extra file which is referenced in each SSH client call with ssh -F .ssh/aws-config, or they require to mark sections in the .ssh/config like "### AZURE-SSH-CONFIG BEGIN ###". All attempts are either clumsy or error prone.

Another use case is where parts of the SSH configuration is managed by configuration management systems or by software packages for example by a company – again that requires changes to a single file and might alter or remove existing configuration for your others services and servers. After all, it is not uncommon to use your more-or-less private Github account for your company work so that you have mixed entries in your .ssh/config.

The underneath problem of managing more complex software configurations in single files is not unique to OpenSSH, but more or less common across many software stacks which are configured in text files. Recently it became more and more common to write software in a way that configuration is not read as a single file, but that all files from a certain directory are read in. Examples for this include:

  • sudo with the directory /etc/sudoers.d/
  • Apache with /etc/httpd/conf.d
  • Nginx with /etc/nginx/conf.d/
  • Systemd with /etc/systemd/system.conf.d/*
  • and so on…

Initially such an approach was not possible with the SSH client configuration in OpenSSH but there was a bug reported even including a patch quite some years ago. Luckily, almost three years ago OpenSSH version 7.3 was released and that version did come with the solution:

* ssh(1): Add an Include directive for ssh_config(5) files.


https://www.openssh.com/txt/release-7.3

So now it is possible to add one or even multiple files and directories from where additional configuration can be loaded.

Include

Include the specified configuration file(s). Multiple pathnames may be specified and each pathname may contain glob(7) wildcards and, for user configurations, shell-like `~’ references to user home directories. Files without absolute paths are assumed to be in ~/.ssh if included in a user configuration file or /etc/ssh if included from the system configuration file. Include directive may appear inside a Match or Host block to perform conditional inclusion.

https://www.freebsd.org/cgi/man.cgi?ssh_config(5)

The following .ssh/config file defines a sub-directory from where additional configuration can be read in:

$ cat ~/.ssh/config 
Include ~/.ssh/conf.d/*

Underneath ~/.ssh/conf.d there can be additional files, each containing one or more host definitions:

$ ls ~/.ssh/conf.d/
corporate.conf
github.conf
myserver.conf
aws.conf
azure.conf
$ cat ~/.ssh/conf.d/aws.conf
Host aws-dev
    HostName 12.24.33.66
    User ec2-user
    IdentityFile ~/.ssh/aws.pem
    IdentitiesOnly yes
    StrictHostKeyChecking no

This feature made managing SSH configuration for me much easier, and I only have few use cases and mainly require it to keep a simple overview over things. For more flexible (aka cloud based) setups this is crucial and can make things way easier.

Note that the additional config files should only contain host definitions! General SSH configuration should be inside ~/.ssh/config and should be before the include directive: any configuration provided after a “Host” keyword is interpreted as part of that exact host definition – until the next host block or until the next “Match” keyword.

[Howto] Adding SSH keys to Ansible Tower via tower-cli [Update]

Ansible Logo

The tool tower-cli is often used to pre-configure Ansible Tower in a scripted way. It provides a convenient way to boot-strap a Tower configuration. But adding SSH keys as machine credentials is far from easy.

Boot-strapping Ansible Tower can become necessary for testing and QA environments where the same setup is created and destroyed multiple times. Other use cases are when multiple Tower installations need to be configured in the same way or share at least a larger part of the configuration.

One of the necessary tasks in such setups is to create machine credentials in Ansible Tower so that Ansible is able to connect properly to a target machine. In a Linux environment, this is often done via SSH keys.

However, tower-cli calls the Tower API in the background – and JSON POST data need to be in one line. But SSH keys come in multiple lines, so providing the file via a $(cat ssh_file) does not work:

tower-cli credential create --name "Example Credentials" \
                     --organization "Default" --credential-type "Machine" \
                     --inputs="{\"username\":\"ansible\",\"ssh_key_data\":\"$(cat .ssh/id_rsa)\",\"become_method\":\"sudo\"}"

Multiple workarounds can be found on the net, like manually editing the file to remove the new lines or creating a dedicated variables file containing the SSH key. There is even a bug report discussing that.

But for my use case I needed to read an existing SSH file directly, and did not want to add another manual step or create an additional variables file. The trick is a rather complex piece of SED:

$(sed -E ':a;N;$!ba;s/\r{0,1}\n/\\n/g' /home/ansible/.ssh/id_rsa)

This basically reads in the entire file (instead of just line by line), removes the new lines and replaces them with \n. To be precise:

  • we first create a label "a"
  • append the next line to the pattern space ("N")
  • find out if this is the last line or not ("$!"), and if not
  • branch back to label a ("ba")
  • after that, we search for the new lines ("\r{0,1}")
  • and replace them with the string for a new line, "\n"

Note that this needs to be accompanied with proper line endings and quotation marks. The full call of tower-cli with the sed command inside is:

tower-cli credential create --name "Example Credentials" \
                     --organization "Default" --credential-type "Machine" \
                     --inputs="{\"username\":\"ansible\",\"ssh_key_data\":\"$(sed -E ':a;N;$!ba;s/\r{0,1}\n/\\n/g' /home/ansible/.ssh/id_rsa)\n\",\"become_method\":\"sudo\"}"

Note all the escaped quotations marks.

Update

Another way to add the keys is to provide yaml in the shell command:

tower-cli credential create --name "Example Credentials" \
                     --organization "Default" --credential-type "Machine" \
                     --inputs='username: ansible
become_method: sudo
ssh_key_data: |
'"$(sed 's/^/    /' /home/ansible/.ssh/id_rsa)"

This method is appealing since the corresponding sed call is a little bit easier to understand. But make sure to indent the variables exactly like shown above.

Thanks to the @ericzolf of the Red Hat Automation Community of Practice hinting me to that solution. If you are interested in the Red Hat Communities of Practice, you can read more about them in the blog “Communities of practice: Straight from the open source”.

[Howto] Vagrant: libvirt, (Multi-)Multi-Machine, Ansible and Puppet

Jean Victor Balin - CubesVagrant is a tool to create and configure virtual development environments. As a wrapper around common virtual machine solutions it helps bringing up and disposing a virtual machine in a glimpse. I played around with it – and, well, got a bit carried away…

What all the fuzz is about… – Vagrant Basics

Simply said, Vagrant is nothing more than a wrapper around your average virtualization solution. While it was mainly developed for VirtualBox these days it also supports libvirt/kvm, Amazon, VMWare and others. The aim is to have one single description file to bring up and tear down an entire virtual machine with simple commands. That way each developer or tester can use the same description file and thus the same environment – Vagrant wants to fight the “works on my machine” excuse. Also, since bringing up and disposing images is a matter of seconds all testing and development can be done against clean environments.

Another big feature is that Vagrant seamlessly integrates with configuration management systems like Puppet, Chef, Ansible and others. Thus the deployment of the virtual development machines can be done with the same configuration scripts you use for your production environment.

The Vagrant VMs are always spawned from a base image, which is again derived from a so called “box”. There are many of these boxes freely available on the internet. Most of them have the same features: only basic packages installed plus Puppet, Chef and similar clients, a user vagrant with the password vagrant, sudo rights and an insecure ssh public key in .ssh/authorized_keys.

Why? – The motivation

The question quickly arises why anyone should use Vagrant. After all, virsh already is a proper abstraction layer for qemu and kvm and provides quite some functionality. The rest can be done manually or by helper scripts: bringing up a VM, installing configuration management, throwing machines away, bringing new ones up, etc.

However, Vagrant is much simpler than virsh, and also offers a simple but kind of sane configuration file for it. And its easier to use Vagrant which is continuously improved than developing and maintaining your own set of scripts.

There are of course other solutions – Docker is rather often mentioned in this regard. I have not really looked at Docker or other alternatives in detail, so I won’t do a comparison right now. Maybe I will find time in the future to really dive into Docker and then compare them – if possible at all.

Can we start now? – Basic usage

Vagrant was originally developed around VirtualBox. Since I am used to libvirt i decided to test Vagrant on libvirt. James has written an incredible helpful howto describing what to do and where users should be careful.

The general steps are on Fedora (and similar on other machines like Debian, etc.):

  • get a recent Vagrant rpm and install it
  • throw in some dependencies for later: libvirt-devel, libxslt-devel, libxml2-devel, virsh, qemu-img
  • call vagrant and install a plugin to convert VirtualBox images to libvirt ones: vagrant plugin install vagrant-mutate
  • get the first Vagrant box: vagrant box add precise32 http://files.vagrantup.com/precise32.box – the default example, it a VirtualBox image
  • transform it to a VMDK2 image, because Fedora’s qemu right now cannot handle VMDK3 images: wget https://raw.github.com/erik-smit/one-liners/master/qemu-img.vmdk3.hack.sh, chmod u+x qemu-img.vmdk3.hack.sh, ./qemu-img.vmdk3.hack.sh ~/.vagrant.d/boxes/precise32/virtualbox/box-disk1.vmdk
  • mutate the VirtualBox image to libvirt: vagrant mutate precise32 libvirt
  • initiate a Vagrant project: vagrant init precise32, as you see the Vagrant configuration file called Vagrantfile is created
  • launch your first Vagrant box: vagrant up

And you are done! You’ve created your first VM with Vagrant. You can get access via vagrant ssh:

$ vagrant ssh
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic-pae i686)

 * Documentation:  https://help.ubuntu.com/
Welcome to your Vagrant-built virtual machine.
Last login: Fri Sep 14 06:22:31 2012 from 10.0.2.2
vagrant@precise32:~$

The command drops to a normal shell on the machine as the user “vagrant”.

And now comes the beauty of vagrant: with a single vagrant destroy you can get rid of the entire VM including the wasted space. If you want to try it again: vagrant up, box goes up, vagrant destroy, box goes down. Box goes up, Box goes down. Box goes up, box goes down.

Each time all modifications to the VM are lost, thus you can ensure all your changes in configuration management and development work against a clean environment. And it only takes half a minute to bring up the machine!

By the way, before you get too experimental: your current working directory is exported as a NFS share. Thus exchanging files between the machines is rather easy. But it also means that you should not try rm -rf / on a Vagrant machine.

Got problems? – Troubleshooting

What, already? Well… In that case, launch virt-manager and look at the machine. After all, Vagrant is just a wrapper!

For example if DHCP failed or NFS timed out it might be that there are problems with the firewall rules of the host machine. The way to allow the proper connections for recent Fedora versions is explained in Vagrant issue #2447. Basically, the Vagrant libvirt network bridge should be assigned to the internal zone, and services like NFS, DHCP, mountd and rpc for both TCP and UDP should be added there.

Also, if the request for the user password comes up all the time to secure only authorized access to the virtual machine management, PolicyKit rules can permanently provide proper rights. James’ blog post mentioned above explains the details.

And in case each machine gets two adapters with two IP addresses… well, that happened to me as well, and so far I have no solution. I am happy for any help regarding that topic.

Storage! – Where to put the images and boxes

Running virtual machines eats your storage. Usually, the boxes are managed in ~/.vagrant.d/boxes, while the actual VM templates and the machines themselves are stored in the default storage of the default virtual machine provider. In this case that is the default storage of libvirt.

It makes sense to dedicate an extra storage pool like an extra partition to Vagrant. That can be achieved by creating a storage pool in libvirt and telling Vagrant in the Vagrantfile about it. The “provider” section is the right place for that:

# Provider-specific configuration
config.vm.provider :libvirt do |libvirt|
    libvirt.driver = "qemu"
    libvirt.connect_via_ssh = false
    libvirt.storage_pool_name = "vm-images"
end

Providers are Vagrants name for virtual environments like VirtualBox, libvirt and so on. In this example the provider libvirt is ensured in case other providers are installed on the host as well. Also , the storage pool name is given, “vm-images”.

We want more! – Getting other boxes

In the above example an Ubuntu Precise machine was used. But it might rather well be that someone would like to use other operating systems or versions as a base. Quite some are listed at vagrantbox.es. Also, the Puppet project provides some useful boxes, even “clean” ones without any further additions installed.

However, using boxes from others is of course a security risk. But there is a way to build boxes yourself. I found James’ Makefile very handy: It uses virt-builder from the libguestfs project to build a CentOS 6 machine. Of course, using images from libguestfs only reduces your security risk, best would be to build your own images from scratch.

I built my CentOS 6 images using the above mentioned Makefile with two smaller adjustments to avoid problems with SSH fingerprints an for a better Ansible integration.

One, one-two, one-two-three! – Multi machines

Vagrant makes fun already – but things get more interesting with the possibility to start more than one machine. The Vagrant Documentation about multi-machines shows how further machines can be added – and named – in the Vagrantfile:

  config.vm.define "staging" do |staging|
    staging.vm.network private_network, ip: "192.168.121.101"
  end

  config.vm.define "prod" do |prod|
    prod.vm.network private_network, ip: "192.168.121.111"
  end

In this example two machines are now available: one named “staging” and one called “prod”, both with different IP addresses. Now all the Vagrant commands like up and ssh need the name of the machine to know on which machine they should act: vagrant up staging, vagrant ssh staging and vagrant destroy staging.

If no machine name is given, the task like up and destroy is run on all machine at the same time, in parallel. That can lead to problems like frozen machines, for unknown reasons. In such cases a workaround is to start the machines with the option --no-parallel.

Do you YAML? – Defining machines in external files

Being excited by the simplicity of Vagrant I got playful – and decided that specifying machines in the Vagrantfile is not very handy. Also, since I have no idea of Ruby and I am bound to make errors when I have to alter the file often. Thus I decided to specify machines in a YAML file, including name and IP. I picked YAML because I know it from Hiera/Puppet, Ansible and others. The file looks like the following:

---
- name: prod
  ip: 192.168.121.101
  environment: prod
- name: staging
  ip: 192.168.121.102
  environment: staging

This must be read into Vagrant – and luckily the entire script to read in these YAML data can be placed in the Vagrantfile itself:

  require 'yaml'
  servers = YAML.load_file('servers.yaml')

  servers.each do |servers|
      config.vm.define servers["name"] do |serv|
          serv.vm.network "private_network", ip: servers["ip"]
      end 
  end 

That’s it already. Now Vagrant can run as many machines as are specified in the YAML file.

Multi multi multi – Specifying multi-machines with different boxes

But that wasn’t enough – I work in two worlds, Debian/Ubuntu and Fedora/CentOS, and thus needed to be able to spawn VMs of CentOS and Ubuntu images. Thus I added the box name to the YAML file: “centos64” is the base box for a recent CentOS, and “saucy64” the base box for the last Ubuntu release.

- name: cstaging
  box: centos64
  ip: 192.168.121.102
- name: ustaging
  box: saucy64
  ip: 192.168.121.150

The names need to be different so that Vagrant can differentiate between the machines. In the above outlined example the names are prefixed with “u” for the Ubuntu machines and “c” for the CentOS machines.

The sourc ecode to read in the details in the Vagrantfile are:

  servers.each do |servers|
      config.vm.define servers["name"] do |serv|
          serv.vm.box = servers["box"]
          serv.vm.network "private_network", ip: servers["ip"]
      end 
  end

Do what I want! – Configuration management

As mentioned in the beginning, the real strength of Vagrant shines when it comes to integrating configuration management: Imagine a setup where all the developers work on the main Gits of the configuration management and the application only. And when they want to see if their changes work, they just fire up Vagrant: upon vagrant up development a new VM is deployed, all configurations and the application code from the stage “development” are pulled and installed automatically, and the developer just checks if everything is alright. Afterwards, the developer destroys the VM, and pushes the just tested changes to the staging repo.

To make that come true we need to integrate configuration management with Vagrant. By the way: Vagrant speaks about “provisioning” here not the best naming, but you got to live with it. Anyway, as mentioned there are multiple was to integrate configuration management. Puppet alone can be run by puppet apply or in terms of a real Puppet client, and the multiple configuration management systems can be even combined and run after each other. Here I will only shed some light on integrating either Ansible or Puppet Apply.

The decision which machine is to be managed by which solution will – of course – be done in the YAML file:

- name: cclean
  box: centos64
  ip: 192.168.121.102
  prov: ansible
  environment: staging
- name: uclean
  box: saucy64
  ip: 192.168.121.150
  prov: puppet
  environment: common

The CentOS machines will be managed by Ansible, the Ubuntu ones by Puppet. Also, please note that additional variables for stages are defined which might come in handy later on.

Simple and fast – integrating Ansible

I like Ansible. It’s really fast and easy to deploy. The same is true for its integration with Vagrant:

  servers.each do |servers|
      config.vm.define servers["name"] do |serv|
          serv.vm.box = servers["box"]
          serv.vm.network "private_network", ip: servers["ip"]
          if servers["prov"] == "ansible"
              serv.vm.provision "ansible" do |ansible|
                  ansible.playbook = "ansible/playbook.yaml"
              end 
          end 
      end 
  end

A subdirectory called “ansible” contains the playbook which is needed by Ansible. And, well, that’s it. The Vagrant Ansible documentation covers some more options like additional variables which can set. These come in handy when you need to differentiate between various environments like staging and production.

But in general, you can now write your playbook as you like and see how Ansible works its way. It is automatically launched after the NFS share was made ready.

Big and heavy – Puppet

Compared to Ansible, Puppet is rather heavy, and not that quick&dirty. Thus, the integration with Vagrant is a bit more difficult. But in general it is what anyone would expect of a Puppet server: a Hiera configuration, a modules directory and a basic Puppet manifest file to start with. The integration with Vagrant is done entirely in the Vagrantfile, and is shown below together with the the already above mentioned configuration:

  servers.each do |servers|
      config.vm.define servers["name"] do |serv|
          serv.vm.box = servers["box"]
          serv.vm.network "private_network", ip: servers["ip"]
          if servers["prov"] == "ansible"
              serv.vm.provision "ansible" do |ansible|
                  ansible.playbook = "ansible/playbook.yaml"
              end 
          elsif servers["prov"] == "puppet"
              serv.vm.provision :puppet do |puppet|
                  puppet.manifest_file  = "site.pp"
                  puppet.manifests_path = "puppet/manifests"
                  puppet.module_path = "puppet/modules"
                  puppet.hiera_config_path = "puppet/hiera.yaml"
                  puppet.working_directory = "/vagrant/puppet"
                  puppet.facter = { 
                      "environment" => servers["environment"]
                  }   
              end 
          end 
      end 
  end

In the example above an environment variable is provided to the Puppet Apply routine in form of a facter variable. Also, please note that a working directory has to be given so that all necessary files like the hieradata store can be found by Puppet. The rest is, however, pure Puppet: getting proper modules, setting up a well designed hierarchy with Hiera, etc.

Sooo…. What now? – Conclusion

Well… in the beginning I just wanted to understand what Vagrant exactly does and how and if it can help me. After getting this far I can say it will help me a lot in the future: creating and dumping virtual machines was never so quick and easy.

With the option of integrating configuration provisioning methods it can really change the way people develop code in business environments like for customers at my work at credativ. Often enough customers are simply too busy to bring up a VM because it takes too much time and is too tedious even with predefined scripts. They end up developing on their own machine, and later on run into problems with the further development. At such points Vagrant’s ease and simplicity can be incredible helpful to test configuration management recipes or development code. It could greatly ease the pain of providing an automated QA workflow where the QA testers get their own disposable VMs which are automatically brought up with the current testing stage.

But even for smaller setups like “personal” development Vagrant can really make things easier: as mentioned in the beginning, many people use virtualization in ways more or less similar to Vagrant. But keeping together personal scripts to bring up and destroy machines is a tedious work. Vagrant makes it quicker, simpler, and thus more reliable. Only for one-time tasks where for example I would need to create an entire new box in Vagrant I might still use virt-manager.

Of course, some bits are still missing. For example the provisioning done by YAML file could be improved so that Ansible, Puppet and all the others could share a single server configuration base with Vagrant. And as mentioned above, a comparison with other solutions would be nice as well.

But so far Vagrant has proven itself: Whenever I need to repeatedly test some configuration or integration I will use Vagrant. And I am already looking forward to all the shiny things which I can test now just a bit easier.

[Short Tip] Use SSH agent forwarding on remote servers

920839987_135ba34fff
When you administrate machines it sometimes makes sense to forward your SSH agent information from your client A to the server B. Using agent forwarding you can use the authentication keys from client A on server B to for example properly authenticate on server C – without the need to copy your private SSH key to server B. One common example in my case is that I sometimes need to access Gitolite/Github repositories on server B but I do not want to copy my SSH key there.

Keep in mind that you previously have to add the wanted SSH key on client A via ssh-add!

$ ssh-add -c
Identity added: /home/liquidat/.ssh/id_rsa (/home/liquidat/.ssh/id_rsa)
The user must confirm each use of the key
$ ssh -A server_b.example.net
liquidat@server_b.example.net's password: 
Last login: Fri May 24 17:11:17 2013 from somewhereovertherainbow.example.com
$ ssh git@git.example.com info
hello liquidat, this is git@git.example.com running gitolite3 3.5.1-1.el6 on git 1.7.1

[...]

(Thanks to Evgeni for reminding me of the ‘-c’ flag.)

Short Tip: Check configured virtual hosts in Apache

920839987_135ba34fff
Whenever you have to debug virtual host setups in Apache, checking the actual running virtual host configuration is a good first step. This can be done with the -S option used on the Apache binary: It lists all running virtual hosts and performs a syntax check.

On Fedora, RHEL, CentOS the Apache binary can be found on /usr/sbin/httpd:

# /usr/sbin/httpd -S
VirtualHost configuration:                                                        
1.2.3.4:80      me.example.net (/etc/httpd/conf.d/me.conf:5)
2.3.4.5:80      others.example.net (/etc/httpd/conf.d/others.conf:1)
2.3.4.5:443     others.example.net (/etc/httpd/conf.d/others.conf:38)
Syntax OK

On Debian systems the call is almost the same, you just have to source the environment variables upfront, and the binary has a different name for historical reasons:

# source /etc/apache2/envvars
# /usr/sbin/apache2 -S
VirtualHost configuration:                                                        
1.2.3.4:80      me.example.net (/etc/apache2/sites-enabled/me.conf:5)
2.3.4.5:80      others.example.net (/etc/apache2/sites-enabled/others.conf:1)
2.3.4.5:443     others.example.net (/etc/apache2/sites-enabled/others.conf:38)
Syntax OK

you might run into an error about user names, in such cases it is helpful to call upfront.

[Short Tip] Generate SSH fingerprints

920839987_135ba34fff
Whenever you open a ssh connection to your server from a new computer, you should will be shown the ssh fingerprint of the machine to verify if you are really connecting the machine you are aiming for. Thus you should have the the SSH key fingerprint at hand. The fingerprint can be easily calculated directly on the server with a single command:

# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
2048 07:86:16:03:b0:75:7e:74:be:49:77:86:3b:cb:92:a9 /etc/ssh/ssh_host_rsa_key.pub