~sircmpwn/sr.ht-discuss

9 2

gitsrht-keys failing?

Details
Message ID
<20190919162420.GA1145080@michaels.world>
DKIM signature
pass
Download raw message
Hiya,
I've been working on my git.sr.ht on my server, and when cloning a repository over ssh, I get the following output:

fatal: unrecognized command '/usr/bin/gitsrht-shell '1' 'lilmike' '<key>''
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

It looks to me like the whole thing inside the main quotes is getting run as a command, which of course does not exist. Any thoughts?
-Michael.
Details
Message ID
<BX44A9B2YKYL.3UEQRQHDURGBM@homura>
In-Reply-To
<20190919162420.GA1145080@michaels.world> (view parent)
DKIM signature
pass
Download raw message
Can we see your sshd_config and the git.sr.ht::dispatch section of your
config.ini?
Details
Message ID
<20190919170059.GA1154520@michaels.world>
In-Reply-To
<BX44A9B2YKYL.3UEQRQHDURGBM@homura> (view parent)
DKIM signature
pass
Download raw message
Here you go:

sshd-config:
#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# for sr.ht services
AuthorizedKeysCommand=/usr/bin/gitsrht-dispatch "%u" "%h" "%t" "%k"
AuthorizedKeysCommandUser=root
PermitUserEnvironment SRHT_*

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no # pam does that
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem      sftp    /usr/lib/ssh/sftp-server
Subsystem      sftp    internal-sftp

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

Match Group web
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
PasswordAuthentication yes


And config.ini:
[git.sr.ht::dispatch]
#
# The authorized keys hook uses this to dispatch to various handlers
# The format is a program to exec into as the key, and the user to match as the
# value. When someone tries to log in as this user, this program is executed
# and is expected to omit an AuthorizedKeys file.
#
# Uncomment the relevant lines to enable the various sr.ht dispatchers.
/usr/bin/gitsrht-keys=git:git
#/usr/bin/man-srht-keys=man:man



On Thu, Sep 19, 2019 at 12:24:58PM -0400, Drew DeVault wrote:
>Can we see your sshd_config and the git.sr.ht::dispatch section of your
>config.ini?
Details
Message ID
<BX452HR2B3XM.1HWOG3YZJNXTA@homura>
In-Reply-To
<20190919170059.GA1154520@michaels.world> (view parent)
DKIM signature
pass
Download raw message
That looks right. I'm not sure what the issue is.
Details
Message ID
<20190919175904.GA1168805@michaels.world>
In-Reply-To
<BX452HR2B3XM.1HWOG3YZJNXTA@homura> (view parent)
DKIM signature
pass
Download raw message
I've been playing around with running gitsrht-dispatch manually to see what the output is, and am running into a few issues.
I'm having trouble figuring out what to put for the "%k" part. Is that the base64 stuff in id_rsa (private key) without (or with?) the --- begin ssh private key --- etc? Also, is the %t token ssh-rsa, or something else?
When I run it manually I get a traceback about user not being defined, I assume because i'm passing invalid data so meta.sr.ht isn't responding with expected output or something.
-Michael.






On Thu, Sep 19, 2019 at 01:01:51PM -0400, Drew DeVault wrote:
>That looks right. I'm not sure what the issue is.
Details
Message ID
<BX46C1A6FP62.3AHJ6LS05XU61@homura>
In-Reply-To
<20190919175904.GA1168805@michaels.world> (view parent)
DKIM signature
pass
Download raw message
It's supposed to be the base64-encoded public key. Can we see that
traceback?
Details
Message ID
<20190919180848.GA1171293@michaels.world>
In-Reply-To
<BX46C1A6FP62.3AHJ6LS05XU61@homura> (view parent)
DKIM signature
pass
Download raw message
Hi,
I actually got it to output something other than a traceback (by looking at the logs which had exactly what I needed). However, it looks like the output is not proper output, as when putting it in an authorized-keys file on a different user, it fails to authenticate. When I add the public key for said key instead of the seemingly base64 encoded version, it works. Could that be the issue?
-Michael.




On Thu, Sep 19, 2019 at 02:01:20PM -0400, Drew DeVault wrote:
>It's supposed to be the base64-encoded public key. Can we see that
>traceback?
Details
Message ID
<BX46JDOT09ND.3UAE9M1D9EVTL@homura>
In-Reply-To
<20190919180848.GA1171293@michaels.world> (view parent)
DKIM signature
pass
Download raw message
It could be. It's hard to debug by proxy.
Details
Message ID
<20190919181848.GA1174354@michaels.world>
In-Reply-To
<BX46JDOT09ND.3UAE9M1D9EVTL@homura> (view parent)
DKIM signature
pass
Download raw message
Hi,
Actually I messed up. The keys I was using on ssh and the key given to sr.ht were mismatched. Now when I put the proper info into the command I get output that, when added to my authorized_keys file, actually runs gitsrht-shell. I'm not really sure what's going on here.




On Thu, Sep 19, 2019 at 02:10:55PM -0400, Drew DeVault wrote:
>It could be. It's hard to debug by proxy.
Details
Message ID
<20190919182219.GA1175557@michaels.world>
In-Reply-To
<BX46JDOT09ND.3UAE9M1D9EVTL@homura> (view parent)
DKIM signature
pass
Download raw message
Success!
It looks like the shell for git was set to /usr/bin/git-shell, so the command was passed from sshd to that, not to bash, and git-shell clearly does not expect that.
-Michael.




On Thu, Sep 19, 2019 at 02:10:55PM -0400, Drew DeVault wrote:
>It could be. It's hard to debug by proxy.