SSH Key?

[girish]

@Lanhild if you are in the market, then https://git.cloudron.io/cloudron/githubpages-app has to be adapted to run a SSH server and accept keys (maybe /app/data/ssh_keys or something?).

[Lanhild]

@girish might take a look someday

[Info-Tech.guru]

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.

[nebulon]

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

You can explicitly configure that in ~/.ssh/config (linux at least, no clue about other OSs). For example:

....
Host ssh.gitlab.gnome.org
    IdentityFile ~/.ssh/id_rsa_mykey
    IdentitiesOnly yes
....

[Info-Tech.guru]

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.

[Info-Tech.guru]

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...

[nebulon]

Yes I was referring to your client (laptop) side of things. SSH does not always pick up the correct keyfile automatically for a domain, basically what you would provide with -i in ssh.

[Info-Tech.guru]

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!

[robi]

@Info-Tech.guru have you repeated the setup with the demo server by installing the same app there and configuring it?

Have you used the same key pair elsewhere?

[BrutalBirdie]

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

Web Terminal of the ghp (github page app)

curl -s https://github.com/brutalbirdie.keys > /app/data/ssh/authorized_keys

Localhost:

cd tmp
mkdir ghpt
cd ghpt
touch index.html
echo '<h1>FooBar</h1>' > index.html
git init
git remote add page ssh://git@ghp.cloudron.dev:29418/app/data/repo.git
git add .
git commit -m "WIP"
git push
curl -s https://ghp.cloudron.dev
<h1>FooBar</h1>

Maybe somewhere you missed a step or something
https://docs.cloudron.io/apps/githubpages/

[Info-Tech.guru]

@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.