Host management encompasses several technologies:
Cockpit is a remote host management system for Linux hosts, allowing management through a web portal hosted locally on the Linux host via a lightweight web server. As such, and like all remote management systems, enabling Cockpit carries inherit risks since this technology allows anyone with knowledge of system access to issue any command to the host. Cockpit is capable of managing system services, viewing all running processes, running commands (even as root), and more.
dnf install -y cockpit
systemctl enable --now cockpit.socket
firewall-cmd --add-service=cockpit --permanent
firewall-cmd --reloadapt install -y cockpit
systemctl enable --now cockpit
ufw allow 9090
ufw allow 80Alpine does not have direct support for Cockpit. They suggest Alpine Configuration Framework (ACF)
pacman -Syu cockpitCockpit supports passing your local user session login details to the remote host, through the web browser session. This can be helpful if your local host and the remote host are both joined to the same domain, and you are logged in to your local host with your domain credentials. In this situation your domain user session details (kerberos ticket) will be passed through the web browser to the remote host and you’ll be logged in to the remote host under your domain user account, automatically.
However, this automatic login behavior can be problematic if your local user account does not have administrative permission on the remote host, yet your intend is to log in to the remote host as the administrator. The workaround is to log off of Cockpit after the automatic login so that you can login under your admin account. rather frustrating
Unfortunately Cockpit does not provide configuration options for this behavior, so to modify Cockpit’s automatic login we must change Cockpit’s source HTML.
The auto login feature (and other advanced features of the login page) are coded as JavaScript functions at the top of the HTML file. There are some good comments in this section, so I eventually found the function responsible for the auto login: function I. Unfortunately, deleting or commenting out I breaks the login page pretty badly. I found that it really must be left in place, but that I could achieve the desired effect by altering the call for function I (happens in the code block just before the function I definition). function q seems to be related to login functions, and based on my trial-and-error experience, it is the magic function to replace I with.
Edit the login HTML page file with:
vi /usr/share/cockpit/static/login.min.htmlSearch for function I, as your reference point, by typing /function I then press [enter]. Use n to find the next instance of the search term (p would find the previous). In the code block just before function I (commented with /*Try automatic/kerberos authentication*/) you’ll see the following originals - replace these lines with the new lines as indicated:
| Original | New |
|---|---|
| } else if (o) { | } else if (o) { |
| q(i); | q(i); |
| } else { | } else { |
| I(); | q(i);//I(); |
| } | } |
So now, in either case q runs and I never will. Now the login page will never try to autologin using the local session kerberos ticket. Now we need to restart the Cockpit service:
systemctl restart cockpitFrom my expeditions into the internet I’ve found that there is much confusion around Secure Copy (SCP) and related protocols like Secure File Transfer Protocol (SFTP). There are plenty of forum posts and search queries of the type “Which is more secure, SCP or SFTP?” The short answer is: SFTP is preferred, though SCP can be fine. Sounds like there is more to it? Well there is, and to understand the answer better let’s first touch on how files were transferred through the early internet.
When computer networking and the internet were young there was little to no focus on, and no need for, robust security. Therefore commands like rcp and ftp were just fine, even though they are woefully insecure by today’s standards. The habits that users formed using these commands were difficult to banish. Today we must worry about (and write extensive articles about) which command is the most secure, lest we ever forget the lesson of putting security second.
In the late 1990s security was eventually added to the older network file transfer commands - new scp and sftp commands were created. These commands rely on SSH connections for security, but otherwise utilize the original protocols to be effective. While these commands continue to be maintained through the OpenSSH package, it’s doubly true that the commands are based on much older commands and that both incorporate SSH. Therefore, as far as the security of the connection is concerned: SCP and SFTP are equally secure.
But they were all of them deceived, for another command was made…
…but seriously, another variation of secure FTP service was made, FTP over SSL. It’s fine choice for those who want to use it, though an argument can be made that SFTP is superior in environments that are already capable of SSH. FTPS requires the use of ports 989 and 990, and must have an X.509 certificate (from a public certificate authority). Meanwhile SFTP uses your existing port 22 (because it runs over SSH’s port) and utilizes SSH’s configured certification method. Adding FTPS to your environment that already has SSH configured means extra work configuring firewalls and certification, when you could just piggyback on SSH.
Some may know of yet another command, sshfs. This command is for connecting to a remote host’s file system using SSH, allowing you to create a mount point or “mapping” to access the remote file system locally. In actuality sshfs runs over SFTP, so the security of the command and other considerations are the same as those for SFTP.
No surprise, this recommendation comes with a slight caveat. Before OpenSSH version 9 scp was still based on the original rcp command, which had some limitations I’ll discuss below, but which ultimately meant that scp was not as performant for some operations and had many vulnerabilities that couldn’t be mitigated without breaking command functionality. The caveat is that in OpenSSH version 9 a change was made to completely retool scp so that it now uses sftp in the backend. So now, scp is sftp, and this concludes the argument over which is better.
But why was old scp abandonded? Though the underlying SSH connection was just as secure in scp as it was insftp there were other flaws that could be exploited maliciously. Typically only by authorized users though.
In one scenario an
scpconnection would request a file from a remote host, but would not check the filename of the file returned by the remote host, which would seescpaccept any file from the remote host.scpwas later fixed to check the filenames of the files it would receive, but at that time OpenSSH noted thatscpwas “outdated, inflexible and not readily fixed”.
In another scenario, requesting a filename that includes single quotes and a section in backticks would result in the ability to execute arbitrary code included within the backtick section on the remote host.
So, in short, OpenSSH understood the codebase of sftp to be more robust and wished to support it over the work required to fix scp (which would also likely break it).
Since I prefer to run Windows as my everyday driver, and management host, I’ve certainly needed SCP-like functionality between my Windows environment and my Unix-like servers from time to time. What to do since SSH has historically been Unix-only? Well, ever since Windows 10 version 1809/Windows Server 2019, Windows has included support for OpenSSH (including SSH, SCP, and SFTP). Therefore, you can initiate an ‘ssh’, ‘scp’, or ‘sftp’ session directly from Powershell (or Command Prompt, should you choose).
However my preferred utility for managing SCP connections from my Windows host is WinSCP. This GUI utility provides excellent file transfer management, over an SCP or SFTP connection (and some others too). The software also provides an SSH client direct from the GUI. It uses the features of SSH and your chosen protocol to show directory listings in the GUI, and can also keep directories automatically synced while the connection is active. Connection properties can also be saved so that remote hosts can be revisited quickly in future.
And lest we forget, there is also rsync, which is an extremely capable tool, though somewhat to it’s own detriment. Many users complain that Rsync’s options are too complex for daily use, requiring such a verbose command specification that issuing an rsync command with sane behavior constraints may require up to 6 or more command line switches. Most are appreciative of the simpler command syntax of ‘scp’ and even ‘sftp’ for daily use, over that of rsync.
I leaned a lot from the following articles as I researched for this summary: