使用自定义目录中的身份文件连接到主机时出现 SSH 错误:ERROR:gitosis.serve.main:环境中需要 SSH_ORIGINAL_COMMAND

使用自定义目录中的身份文件连接到主机时出现 SSH 错误:ERROR:gitosis.serve.main:环境中需要 SSH_ORIGINAL_COMMAND

问题是关于使用 ssh 连接到远程主机(主要是 git)时遇到的问题,使用自定义配置(如端口、识别文件、.ssh 文件夹位置等)。

配置详细信息:
笔记本电脑: Dell XPS 15z (L511Z)
操作系统: Ubuntu 20.04 LTS (Focal)
德: xubuntu-desktopxfce
显示管理器: lightdm
输入法: xim

GIT 版本: git version 2.25.1
SSH 版本: OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f 31 Mar 2020

我已经设置ssh如下:

  1. sudo apt-get install ssh
  2. sudo apt-get install molly-guard monkeysphere ssh-askpass(这些包是由 推荐的apt)。
  3. 根据 stackexchange 的建议,我也安装了openssh-client这两个和-。openssh-server
  4. 给出了一个强密码。
  5. 与客户端共享我的公钥,并且他们共享了他们的 git 存储库连接链接(我使用 ssh/git 命令连接到他们的服务器存储库)。
  6. 将默认的Port: 22, 更改为不同的Port: xx.
  7. 将默认 ssh 文件夹位置从 更改~/.ssh/xxxx/xxxx.ssh
  8. 将默认known_hosts文件位置从更改/etc/ssh/ssh_config.d/known_hosts/xxxx/xxxx/.ssh/known_hosts
  9. 将所有与 ssh 相关文件/配置移动到自定义目录。 文件如下: id_rsa,,id_rsa.pub& 。(这样做,是为了当我重新安装操作系统时known_hostsauthorized_keys不必重新配置所有内容)。
  10. 删除了该~/.ssh文件夹(请注意,该文件夹现在不存在。可能是个问题)。
  11. ssh通过我的路由器和允许ufw

现在,每当我这样做时ssh user@hostIP,它都会要求输入passphrase3 次并说无法连接或连接超时。因此,为了调试,我运行了

ssh -vi <path_to_custom_identityfile> username@hostIP

并得到以下输出:

$ ssh -vi /xxxx/xxxx/id_rsa_xx [email protected]
OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /xxxx/xxxx/id_rsa_xxx type 0
debug1: identity file /xxxx/xxxx/id_rsa_xxx-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to xxx.xxx.xxx.xxx:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:AQKsBukNwZoDJEEUZt/XTj1AUSeeiFKw5W3QBxcFObw
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /xxxx/xxxx/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /xxxx/xxxx/xxx/xxx/id_rsa_xxx RSA SHA256:Bh3pQ+E3Q70wjZ7qfuLkzdT7Hc4ItLHsR/C+KGeqzRM explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering public key: /xxxx/xxxx/xxx/xxx/id_rsa_xxx RSA SHA256:Bh3pQ+E3Q70wjZ7qfuLkzdT7Hc4ItLHsR/C+KGeqzRM explicit
debug1: Server accepts key: /xxxx/xxxx/xxx/xxx/id_rsa_xxx RSA SHA256:Bh3pQ+E3Q70wjZ7qfuLkzdT7Hc4ItLHsR/C+KGeqzRM explicit
Enter passphrase for key '/xxxx/xxxx/xxx/xxx/id_rsa_xxx': 
debug1: Authentication succeeded (publickey).
Authenticated to xxx.xxx.xxx.xxx ([xxx.xxx.xxx.xxx]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: Forced command.
**debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
debug1: Remote: Forced command.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: PTY allocation disabled.
PTY allocation request failed on channel 0
ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.**
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to xxx.xxx.xxx.xxx closed.
Transferred: sent 3896, received 3516 bytes, in 0.9 seconds
Bytes per second: sent 4523.6, received 4082.4
debug1: Exit status 1  

笔记:在上面的输出中,我突出显示了我觉得可疑的行。

我还做了一些故障排除更改(来自、、stackoverflow等的建议。 其中一些是:askubuntuserverfault

  1. 卸载并重新安装/dev/pts

    • 我无法重新安装它。注意:提到在使用的系统systemd(我正在使用的)中不需要此步骤。
  2. 修改了ssh配置,如
    ForwardX11Trusted、、、、、、、、、、、等。​PasswordAuthenticationChallengeResponseAuthenticationIdentityFileIdentitiesOnlyUserKnownHostsFileX11ForwardingAllowTcpForwardingPermitTTY

我认为某些配置更改(例如X11ForwardingPasswordAuthenticationIdentityFile有一些响应。但不确定其他配置是否如此。不确定它们是否是必需的(或)是否对我的系统有害。

奇怪的是,人们(尤其是我尝试连接的 git 服务器的帐户所有者)提到我不应该使用密码,这可能会导致问题。他们坚持认为,所有获得访问权限的人在使用 git 执行所有/任何操作时都没有遇到任何问题 - 唯一的不同是我使用了密码。我很好奇这是否属实,如果是,为什么/如何。

/etc/ssh/ssh_config以下是我的文件的内容:

$ sudo cat /etc/ssh/ssh_config

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Include /etc/ssh/ssh_config.d/*.conf

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   PasswordAuthentication no
#   PermitEmptyPasswords no
#   RSAAuthentication yes
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected]
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h

    **Port xxxx
    SendEnv LANG LC_*
    HashKnownHosts yes
    ForwardX11Trusted yes
    PasswordAuthentication yes
    ChallengeResponseAuthentication no
    PubkeyAuthentication yes
    StrictHostKeyChecking ask
    IdentityFile=/xxxx/xxxx/id_rsa
    ##Added based on: https://unix.stackexchange.com/questions/494483/specifying-an-identityfile-with-ssh
    IdentitiesOnly yes
    UserKnownHostsFile=/xxxx/xxxx/known_hosts
        X11Forwarding yes
    AllowTcpForwarding yes
    PermitTTY yes
    
    #Added to keep the ssh connection to host's Server alive, for more time.
    #Source: https://serverfault.com/questions/283129/why-do-consoles-sometimes-hang-forever-when-ssh-connection-breaks
    ServerAliveInterval 15
    ServerAliveCountMax 3**

/etc/ssh/sshd_config以下是我的文件的内容:

$ sudo cat /etc/ssh/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/bin:/bin:/usr/sbin:/sbin

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

Include /etc/ssh/sshd_config.d/*.conf

#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 prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#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 yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# 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 yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

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

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

**#Override values - as running ssh verbose debug, stated these as disabled.
    X11Forwarding yes
    AllowTcpForwarding yes
    PermitTTY yes**

**# Copied from /etc/ssh/ssh_config file, to ensure that the settings persist - even if the system uses this (/etc/ssh/sshd_config) file instead.
# copied on 2022-03-23_15:54 hrs. 
    Port xx
    # SendEnv LANG LC_*
    # HashKnownHosts yes
    # GSSAPIAuthentication no
    #PasswordAuthentication no
    #PermitEmptyPasswords no
    #RSAAuthentication yes
    PubkeyAuthentication yes
    # StrictHostKeyChecking ask
    # IdentityFile=/xxxx/xxxx/id_rsa
    # UserKnownHostsFile=/xxxx/xxxx/known_hosts
    
    #Added to keep the ssh connection to client's server alive, for more time.
    #Source: https://serverfault.com/questions/283129/why-do-consoles-sometimes-hang-forever-when-ssh-connection-breaks
    # ServerAliveInterval 15
    # ServerAliveCountMax 3**

以下是文件夹下的文件/etc/ssh

$ sudo ls /etc/ssh
moduli      ssh_config.d  sshd_config.d       ssh_host_ecdsa_key.pub  ssh_host_ed25519_key.pub  ssh_host_rsa_key.pub
ssh_config  sshd_config   ssh_host_ecdsa_key  ssh_host_ed25519_key    ssh_host_rsa_key      ssh_import_id

正如开头提到的,没有~/.ssh/文件夹。

$ ls ~/.ssh
<blank here>

(但是,每当我运行该命令时,都会创建一个 known_hosts 文件ssh。不确定是否要保留它,还是每次都将其删除。也不知道我是否可以/应该避免创建它)。

文件权限:

我已经修改了自定义路径下的ssh 文件夹和文件(如IdentityFileknown_hosts)的文件权限。authorized_keys

  1. /etc/ssh文件夹权限。
    /etc/ssh 文件夹权限。

  2. 以下文件的权限/etc/ssh
    /etc/ssh 下文件的权限。

  3. 自定义路径/目录下的文件(如IdentityFile、、、等)的权限:known_hostsauthorized_keys
    自定义路径/目录下的 IdentityFile、known_hosts、authorized_keys 等文件的权限。

  4. 保存上述文件的自定义目录的权限:
    保存上述文件的自定义目录的权限

我几乎确信更多信息将有助于集中精力解决这个问题。请告诉我,我会尽快分享所需的信息。

如果您能分享一些关于这个主题的高质量知识库/网站,这也会很有帮助。
(不仅仅是关于如何做,还有为什么/什么部分)。

谢谢你!

编辑(2022 年 3 月 4 日):

下列的@steeldriver的建议,我尝试使用git pull而不是ssh并得到了这个输出。
git pull 命令的权限被拒绝

但奇怪的是,git status并没有引发任何错误。 使用 git status 命令时没有错误。

git status在我之前克隆的项目文件夹中运行,得到如下结果:

克隆项目文件夹内的 git 状态

相关内容