Cloudron Forum

@robi said in SSH Key?:

Have you used the same key pair elsewhere?

In every one of the multitude of attempts to get this straight, I have generated a set of completely unique and new key-pairs, even rotating between different formats and implementations of the cryptography used by ssh sessions (RSA, PEM, OpenSSH, ECDSA, etc.). Nothing seems to be sticking.

@BrutalBirdie said in SSH Key?:

I just did a fresh setup and could not reproduce your issue.

I thank you for taking your time to try that out and see if you could replicate the problem. I have done a reinstall as well - just to see if I had borked something in the first installation - but I'm still encountering the same issues. I wish that I could spy over your shoulder or something while you perform a working setup, to see where I am going wrong. I have consulted with the docs that you've linked to, and I am still unsure of what the exact cause of the problem is.

Anyway, thank you all for the time you have dedicated to this matter. I wish that I could simply mark this problem as SOLVED, but the actual takeaway here - is that I had to implement the HTTP transfer methodology, even though it is less secure and is discouraged as a solution. If I DO MANGE to figure it out, then I will update this thread accordingly so that others are not left wondering about this as well.

I see, however in that case:

SSH does not always pick up the correct keyfile automatically for a domain

I am certain, that have the correct private key-file for the ssh session on my client-side - and I only have one key stored in my /app/data/ssh/authorized_keys file, which is stored in a single line entry as depicted below:

ssh-rsa $+|20Ng-|<3Y...etc.

I also have an identical file named id_rsa.pub in the very same directory. When using the corresponding id_rsa private key from my home computer in order to login, it rejects the keypair.

I am curious if there are any further steps that I might be able to take on the server-side of things!? Thank you for your responsiveness, availability, and willingness to help me with this @nebulon - I both hope and trust that we can get it sorted out!

Ahh, I think that I may have possibly misinterpreted your comment!

Is the key picked up automatically for the remote by ssh on your machine?

The client/local side of things is (I believe) able to engage in an attempted handshake with the host/server - but the authentication is rejected when the private key is loaded from my home computer ssh session. I get an error that states "Authentication rejected"

I've been trying to find a logfile on my server/host, but been unable to locate a history of login attempts. Still unsure about how to proceed...

Well, so this is where things get Docker-container style weird: my ~ (home) directory has a "Read-only file system" and I am unable to edit any of the files - even when logged in as root - in that directory (or any other standard-issue, conventional Linux folder). On that note; I have tried to edit my /etc/ssh/ssh_config file as well (which I thought would be the obvious solution to this problem) but that yields the same non-writable issue.

Hey there Cloudron folks - with a special tip of the hat to those of you are on the Staff and Developer teams!

I am having a world of trouble getting the SSH key authentication to work on a brand-new Github Pages installation. I'm familiar enough with the usage of RSA key pairs and the SSH protocol - so I feel that it shouldn't be as difficult as it has been. I wasn't sure if it was better for me to open up a new thread, or just add on to this somewhat dated post - but this is the exact same subject, so here it is:

I have made several attempts at this - whereby I'm generating both the public and private ssh keys via two different methods. I have run the ssh-keygen command on the host docker/machine and added the public key to /app/data/ssh/authorized_keys - as well as using a third party app to generate the keys from my client machine. After both attempts at generating these keys, I have uploaded the public key to the location specified with the file-browser method, as well as cat > appending it to the file through the CLI/terminal.

I have also looked at the owner and group of the authorized_keys file and experimented with assigning the user and group as root:root, versus git:git. Rebooting the docker app after making these changes has also not helped in any way. Alas, nothing that I have been trying has worked so far, and I am seeking some sort of resolution or solution to this issue. Any help would be greatly appreciated.

Ahh yes! That makes perfect sense @nebulon ... and I feel rather silly for not taking that into consideration. It should have been the first place that I looked - because indeed the subdomains rocket-chat, and mastodon were pointing to the old server still. Therefore, there is nothing more to be assessed or figured out here, because you have helped me to solve the problem. I am taking the old server offline, and setting up the apps within the new host environment - as it seems this was much ado about nothing!

I have recently become a Cloudron user, and I am quite impressed with what it can do, but I have gotten myself into a bit of a bind. I am in the middle of migrating my services from my old LAMP server onto this decidedly more powerful platform. The problem which I am currently dealing with though, is that I had previously linked an earlier incarnation of this very server to my Cloudron account and installed a couple of apps (Rocket Chat, and Mastodon) into that administrative user-panel environment.

After messing around a bit with the free version of the Cloudron software, I decided to enroll into the subscription/paid-user plan. When doing so, I was having some problems getting things to run smoothly, so I (perhaps foolishly) unlinked/disconnected my server's registration from the Cloudron.io management environment. I was then able to get things up and running again with a fully functional version of the server-administration software installed onto what I thought was a new and fresh instance - however, it still has those two apps which I had installed earlier on it.

This would be just fine, if they were shown as available and detected by the my.website.tld Cloudron control panel, so that I could properly manage and access the behind-the-scenes infrastructure at play - but they seem to be running as fully functional (yet ghosted) processes which I cannot track down on my server. Now when I visit rocket-chat.some-website.tld or mastodon.different-website.tld - these apps are shown as running and available - but I cannot stop them from gobbling up my server resources or control them in any way. I am hoping that someone can explain how to stop these two Docker instances which I have accidentally left running and installed from a previous Cloudron operating environment, and remove them from the server... so that I can then have full control within the new administrative interface.

I have done some searching and analysis of the following directories through the SSH command line interface: /var/lib/docker/ and /home/yellowtent/appsdata/ but it is not very effective, since everything is Docker-style obfuscated by whatever virtualization magic is at play. So if I could go ahead and sum this all up into two succinct questions just one simple question, then it would look like such:

1. Is there a way to locate old orphaned apps from a previously installed Cloudron environment, so that they can be uninstalled and removed?
   2. On the occasion that I need to reimage my server from scratch, in order to zero things out to fresh-start, can I then backup, and reinstall my currently installed Cloudron apps onto the newly formatted machine?

I look forward to hearing back from someone who has perhaps dealt with something like this before, or from somebody who knows how to address this situation and fix whatever I have accidentally misconfigured.

I appreciate the time and attention you have devoted to this matter.

Gratefully,

Info-Tech.guru

EDIT: I just noticed how insanely simple it is to implement, and restore backups within the Cloudron user interface. This is really cool! I am hoping that I don't have to go to such extremes though.

Hey this is actually pretty funny - because I managed to solve the problem just NOW, around the very time that my post was approved for submission and viewing by the forum community!

I am going to leave the post up as an active contribution until someone suggest or requests that I close it down, on the occasion that it serves as useful for someone else who finds themselves in a similar predicament.

The way that I solved the problem, is that I manually uninstalled nginx, nodejs, and any of the remaining docker artifacts which were leftover from the failed Cloudron installation (by running # sudo apt purge 'package-name'... - and then I simply reran the installer script. Somehow, entirely unbeknownst to me, it worked just fine this time... however every other attempt that I embarked upon failed. In this case, the standard CLI complaint which is issued as a warning that states "it is suggested that you install on fresh OS" (or whatever it says) was best left ignored, and attempting the installation a second time over on top of a failed initial installation run-through was the way to do it.

Anyhow, thanks for coming to my TED talk, and next time I hope that my audience doesn't fall asleep due to boredom!

A warm and hearty hello to the developers, users, and support-personnel at the Cloudron.io organization!

I am excited to get onboard with using the powerful tools which the Cloudron system provides for sysadmins, and happy to see what I can do with it. I have already gotten an instance of the software successfully up and running on a server, which is simply the free version. I am hoping to perform an altogether separate installation onto a more powerful server, and then migrate my data to the newer machine. Additionally, I will hopefully be upgrading to the paid version which provides the additional functionality. The first server upon which I was able to set up and run a test-drive of the administrator's software was running Ubuntu 20.04 within a DigitalOcean VPS.

The problem that I am now encountering, is one where I am trying to get Cloudron installed onto a COMPELTELY fresh and untouched version of Ubuntu 22.04. I have tried several times to run the installer but it still throws back the error Failed to install cloudron. See /var/log/cloudron-setup.log for details - despite multiple attempts with slight variances in the settings.

As far as the very slight changes which I've implemented: I have already tried to run # sudo apt update - as well as the more thorough # sudo apt update && sudo apt upgrade -y && sudo apt dist-upgrade -y ... however, the install script ALSO stalls and fails when I run the following suggested configuration commands as the very FIRST command-line inputs:

wget https://cloudron.io/cloudron-setup
chmod +x ./cloudron-setup
./cloudron-setup --setup-token suP3r-F@ncY_T0keN

I tailed the log file within a separate terminal window, in order to keep an eye on things, and didn't notice any errors or problems until I encountered this as the very final entry within the /var/log/cloudron-setup.log file:

2023-07-19T17:55:46 ==> installer: installing/updating docker

This is all rather confusing and disappointing to me - as I am following the instructions to a T, and I am unsure of how to proceed. I have thoroughly searched through the support forums here for assistance and troubleshooting with similar issues, and I have tried to implement some of the solutions which were suggested within those threads. Although I have encountered a couple of similar queries for help - I haven't yet noticed anyone with an identical issue.

For what it is worth, I am glad that I have already managed to get a running and successfully installed version of Cloudron configured as a test-driver - because if this problem which I am trying to solve were encountered on my preliminary installation attempt, I would be considerably less eager to become further involved with this software. For a little bit more information in that regards: I have unlinked the other instance of Cloudron from my account, so that it is no longer connected to my membership within this website, since I figured it would be best to exhaust all possible points of conflict. I also tried to generate several additional and unique tokens when running and rerunning my installation attempts.

Anyhow, I figure that this is a rather exhaustive and detailed testimonial to my problems which I have encountered with the installation and configuration of a fresh Ubuntu 22.04 server - and in order to avoid burdening y'all with too much unnecessary information or senseless blabber, I will hereby sign off - while hoping for a bit of feedback and some guidance or pointing-in-the-right-direction upon the path of sysadmin trials and tribulations.

Gratefully - yet perplexedly,
Info-Tech.guru