2

When connecting to some linux servers over ssh with my openSUSE 15.1 machine, I get weird EOF and syntax errors. I run pretty much a standard setup and haven't changed anything but enabling pubkey authentication.

This is what happens:

~> ssh randomserver.hostname
bash: -c: line 0: unexpected EOF while looking for matching `"'
bash: -c: line 1: syntax error: unexpected end of file
Connection to randomserver.hostname closed.

Is the error generated on my local machine or is it originating from the remote server, before dropping the connection?

The output of ssh -v is:

~> ssh -v randomserver.hostname
OpenSSH_7.9p1, OpenSSL 1.1.0i-fips  14 Aug 2018
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to randomserver.hostname [192.168.1.2] port 22.
debug1: Connection established.
debug1: identity file /home/myuser/.ssh/id_rsa type 0
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u7
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 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 randomserver.hostname:22 as 'root'
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: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
debug1: Host 'randomserver.hostname' is known and matches the ECDSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts
debug1: rekey after 134572247 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134572548 blocks
debug1: Will attempt key: /home/myuser/.ssh/id_rsa XXXX
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/myuser/.ssh/id_rsa XXXX
debug1: Server accepts key: /home/myuser/.ssh/id_rsa XXXX
debug1: Authentication succeeded (publickey).
Authenticated to randomserver.hostname ([192.168.1.2]: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: Forced command.
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.utf8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
bash: -c: line 0: unexpected EOF while looking for matching `"'
bash: -c: line 1: syntax error: unexpected end of file
debug1: channel 0: free: client-session, nchannels 1
Connection to randomserver.hostname closed.
Transferred: sent 3864, received 3020 bytes, in 0.1 seconds
Bytes per second: sent 75479.5, received 58992.8
debug1: Exit status 1

What may I do to fix this issue, without changing all the remote configurations?

4
  • It might be both. Run ssh -v randomserver.hostname and add the output to the question. If you didn't play with the remote server .bashrc file, most probably .ssh/config (or /etc/ssh/ssh_config) has incorrect syntax.
    – Piotr P. Karwasz
    Dec 23, 2019 at 8:44
  • @PiotrP.Karwasz I added the information. The /etc/ssh/ssh_config only contains the IdentityFile, User root and SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES parameters.
    – akkari
    Dec 23, 2019 at 9:07
  • Probably the remote server has a broken configuration: they use the ForceCommand option in sshd_config, but they have unmatched quotes in it. Are you the remote server's admin?
    – Piotr P. Karwasz
    Dec 23, 2019 at 9:23
  • There is no ForceCommand option enabled in the remote sshd_config. I am the administrator, yes.
    – akkari
    Dec 23, 2019 at 9:34

2 Answers 2

Reset to default
4

In the .ssh/authorized_keys file you can force a command to be run before logging in. The syntax error could be found there (using command="").

This has been used to log the login of any administrator into the system log with an unique key identifier (in addition to the IP address and hostname).

4

Seems like after logging in, bash is trying to run a command automatically for you.

Try logging in with an explicit command like so:

$ ssh -t randomserver.hostname "bash --norc --noprofile"

If that works, then examine the files that bash loads before giving you a shell, search for any unusual lines or syntax errors.

8
  • Sadly no change. Seems like I couldn't give another shell like (/bin/)sh, it will still give out the same error message. I couldn't find a matching `"' on the file system either.
    – akkari
    Dec 23, 2019 at 9:27
  • Then it would seem that the SSH Server administrator has forced a command to be run after logging in. You may not be able to fix this without getting to know what is happening at the server after you logging in.
    – Mukesh Sai Kumar
    Dec 23, 2019 at 9:30
  • Do you know if any possibilities to force a command other then the ForceCommand in the sshd_config?
    – akkari
    Dec 23, 2019 at 9:37
  • 2
    I would add -t to the ssh command in the answer, since ssh will allocate no tty otherwise.
    – Piotr P. Karwasz
    Dec 23, 2019 at 9:54
  • 1
    @MukeshSaiKumar If you want a functional and sane interactive shell at the other end, it must be able to talk to a TTY. Try the command you listed against some server and see what difference -t makes.
    – Kusalananda ♦
    Dec 23, 2019 at 19:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .