![SSH 和 scp 可与 Google Compute Engine VM 配合使用,但 SFTP 无法使用](https://linux22.com/image/1616108/SSH%20%E5%92%8C%20scp%20%E5%8F%AF%E4%B8%8E%20Google%20Compute%20Engine%20VM%20%E9%85%8D%E5%90%88%E4%BD%BF%E7%94%A8%EF%BC%8C%E4%BD%86%20SFTP%20%E6%97%A0%E6%B3%95%E4%BD%BF%E7%94%A8.png)
我已阅读了有关在 Google Compute Engine VM 中设置 SFTP(在 OS X 上使用 Transmit)的其他问题。我的问题是,我目前可以通过 SSH 并使用 scp 进入 VM,但 Transmit 会抛出错误的登录名或密码错误。我该如何排除故障并修复此问题?
我已将 SSH 密钥添加到每个虚拟机和 GC 帐户的元数据中,并且我可以使用 ssh -i my_key 从本地计算机进行 SSH 连接[电子邮件保护]以及从本地主机使用 scp。
但是为什么 SFTP 不起作用?Transmit 客户端会自动为其他主机加载 SSH 密钥。
我已清除 known_hosts 中的条目并再次尝试,但没有任何效果。
虚拟机上的端口 22 显然是开放的。
主机的 ssh 配置不允许进行密码验证;必须这样做吗?
我没有使用 Google Cloud SDK,因为 SSH 和 scp 已经可以工作了。
调试:
ssh -v -i my_key [email protected]
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug1: Connecting to 12.345.678.10 [12.345.678.10] port 22.
debug1: Connection established.
debug1: identity file my_key type 0
debug1: identity file my_key-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u8
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 35.202.168.10:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
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: [key]
debug1: Host '12.345.678.10' is known and matches the ECDSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:66
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: my_key RSA SHA256:[key] explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: my_key RSA SHA256:[key] explicit
debug1: Server accepts key: my_key RSA SHA256:[key] explicit
debug1: Authentication succeeded (publickey).
Authenticated to 12.345.678.10 ([12.345.678.10]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
sftp -v -i my_key [email protected]
OpenSSH_8.1p1, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug1: Connecting to 12.345.678.10 [12.345.678.10] port 22.
debug1: Connection established.
debug1: identity file my_key type 0
debug1: identity file my_key-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u8
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 35.202.168.10:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
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: [key]
debug1: Host '12.345.678.10' is known and matches the ECDSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:66
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: my_key RSA SHA256:[key] explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: my_key RSA SHA256:[key] explicit
debug1: Server accepts key: my_key RSA SHA256:[key] explicit
debug1: Authentication succeeded (publickey).
Authenticated to 12.345.678.10 ([12.345.678.10]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending subsystem: sftp
Connected to 12.345.678.10.
sftp>
ssh_config on 12.345.678.10
Host *
# ForwardAgent no
# ForwardX11 no
# ForwardX11Trusted yes
# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# GSSAPIKeyExchange no
# GSSAPITrustDNS no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
# Protocol 2,1
# Cipher 3des
# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
答案1
问题原来是 Transmit 正在本地 ~/.ssh 中寻找密钥,但 Transmit 日志中的错误是由于密钥的名称或格式而未找到密钥;解决方法是专门在本地底部添加密钥ssh_config
并重新启动 SSH:
in /ssh/ssh_config
:
Host 12.345.678.10
User user
IdentityFile "~/.ssh/my_key"