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 [email protected] '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: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],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,[email protected]
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,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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,[email protected]
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,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
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

2 Answers 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]
9
  • 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, 2012 at 18:26
  • strange, ssh complains about the passphrase. Does it also fail from command line with -T option?
    – user130370
    Aug 23, 2012 at 18:59
  • Same error with: ssh -T -vvv
    – oblio
    Aug 23, 2012 at 19:26
  • Sorry : Only way to reproduce your problem was to give /dev/tty wierd permissions.
    – user130370
    Aug 23, 2012 at 20:07
  • crw-rw-rw- 1 Administrator None 5, 0 Aug 24 13:46 /dev/tty
    – oblio
    Aug 24, 2012 at 10:47
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

You must log in to answer this question.

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