2

Below you can see the log. The connection is from a Cygwin SSH client to a Cygwin SSHD server. The connection works ok when launched from the command line but fails when launched from Jenkins (Java Continuous Integration server). The /dev/tty file exists and is rw for everybody. I tried deleting it and recreating it, but I can't since Cygwin recreates it before I can create a link to /dev/ttySO.

ssh -t -vvv myuser@server.company.com 'mv -v /cygdrive/z/deploy-scripts /cygdrive/z/deploy-scripts-`date +%F_%H-%M-%S`'
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug2: ssh_connect: needpriv 0
debug1: Connecting to server.company.com [] port 22.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 
debug1: read_passphrase: can't open /dev/tty: No such device or address
oblio
  • 375
  • 1
  • 3
  • 12

2 Answers2

0
...
debug1: Server host key: ECDSA 
debug1: read_passphrase: can't open /dev/tty: No such device or address

I came to this issue (10 years in the future) and found that the issue is not the tty or the passphrase per-se. Jenkins ssh keys can handle pass-phrases via the ssh-agent feature. But anyway I disabled the passphrase in testing this. That was not the problem.

The reference read_passphrase must be the generic input "ask a question code". For me it was failing to present this dialog:

The authenticity of host 'server.company.com (192.168.188.44)' can't be established.
RSA key fingerprint is SHA256:UNOzlP66WpDuEo34Wgs8mewypV0UzqHLsIFoqwe8dYo.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no

To programmatically accept the key for all addresses associated with a server you can use this:

ssh-keyscan -p 22 `getent ahosts server.company.com | awk '$3 { print $1 " " $3 }' | sort -u` >> ~/.ssh/known_hosts
Greg
  • 121
  • 2
-1

How do you expect Jenkins (Java Continuous Integration server) to type the passphrase of the ssh key?

If this is development or staging environment and that there is no security concern, you can try to temporarily remove the passphrase from the key and see if it works better.

Edit #1:

Only way I could reproduce your problem was by removing permissions from /dev/tty, as stated in openssh faq, but I guess you already checked that?

With wrong permissions :

#ls -l /dev/tty
crw-r----- 1 root root 5, 0 Aug 23 21:47 /dev/tty
$ssh -T -vv -p 2222 <username>@127.0.0.1
[...]
debug1: read_passphrase: can't open /dev/tty: Permission denied
debug1: permanently_drop_suid: xxxx
[...]

With good permissions :

#chmod 666 /dev/tty
# ls -l /dev/tty
crw-rw-rw- 1 root root 5, 0 Aug 23 21:56 /dev/tty
[ssh client works]
  • The SSH key has no passphrase. And the launcher doesn't matter much, it just executes a batch script containing the same command I launch from the command line. Only it doesn't work when launched from the "script". – oblio Aug 23 '12 at 18:26
  • strange, ssh complains about the passphrase. Does it also fail from command line with -T option? –  Aug 23 '12 at 18:59
  • Same error with: ssh -T -vvv – oblio Aug 23 '12 at 19:26
  • Sorry : Only way to reproduce your problem was to give /dev/tty wierd permissions. –  Aug 23 '12 at 20:07
  • crw-rw-rw- 1 Administrator None 5, 0 Aug 24 13:46 /dev/tty – oblio Aug 24 '12 at 10:47
  • I found the root cause. Jenkins launches slaves on other machines. These slaves run as Windows services. In my situation one of the slaves was launched as SYSTEM => no console. Ka-boom! – oblio Sep 04 '12 at 10:48
  • So /dev/tty had nothing to do with the problem . –  Sep 05 '12 at 13:47
  • Yes, it was a strange symptom, not the actual cause of the problem. Thanks for the ideas ;) – oblio Sep 11 '12 at 05:54
  • How did you fix it, I have the same problem now! – user1911091 May 04 '20 at 19:51