Re: Need some education: Man-in-the-Middle Attacks
Only if Eve gets in the way of the very first connection attempt, can he pass her own public key off as Alice's, without Bob detecting it. This is exactly my concern. Isn't that scary? On Wed, 2006-08-30 at 12:52 -0600, Mark Senior wrote: On 8/29/06, Christ, Bryan wrote: All, Please pardon my naivete. I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt? The server passes the client its public key; the client generates a fingerprint of this public key, and verifies that it matches a known one from previous connections. Eve can pass Alice's public key to Bob, but she doesn't possess Alice's private key, so she has no way to interfere further with the communications (beyond tampering at a network level - introducing delay, dropping the connection, etc.) Only if Eve gets in the way of the very first connection attempt, can she pass her own public key off as Alice's, without Bob detecting it. On the first connection, he'd have to either trust what he sees, or verify the fingerprint offline somehow. On subsequent connections, the mismatch would be obvious.
Re: Need some education: Man-in-the-Middle Attacks
But if Eve is later challenged to prove her identity (that she must now maintain the illusion of being Alice), what prevents Eve from passing the challenge on to the real Alice, getting valid results, and then passing them back to Bob? On Thu, 2006-08-31 at 10:01 +0400, Eygene Ryabinkin wrote: Bryan, I was looking at the diagram on the URL listed below and contemplating how host fingerprinting prevents MITM attacks. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html So my question is this... Given the illustration in the URL above, what prevents Eve from *first* contacting Alice to obtain a fingerprint which then gets passed to Bob on the first connection attempt? She can obtain it, but the fingerprint is closely related to the Alice's private key that Eve can not obtain easily. So there is no reason for Eve to pass Alice's fingerprint to Bob, because later she will not be able to prove to Bob that she has the corresponding private key and it will break the connection between Bob and Eve.
Re: Permission denied, please try again
Yes. I am completely at a loss. The Linux kernel version I updated to is 2.6.15.3. After chmoding 666 on /dev/tty, I changed it back to 777 because it is definitely a directory. Evidence below: [EMAIL PROTECTED]:/dev/tty# ls -l total 0 crw--- 1 root root 3, 10 2007-03-21 00:58 s crw--- 1 root root 3, 0 2007-03-21 00:58 s0 crw--- 1 root root 3, 1 2007-03-21 00:58 s1 crw--- 1 root root 3, 2 2007-03-21 00:58 s2 crw--- 1 root root 3, 3 2007-03-21 00:58 s3 crw--- 1 root root 3, 4 2007-03-21 00:58 s4 crw--- 1 root root 3, 5 2007-03-21 00:58 s5 crw--- 1 root root 3, 6 2007-03-21 00:58 s6 crw--- 1 root root 3, 7 2007-03-21 00:58 s7 crw--- 1 root root 3, 8 2007-03-21 00:58 s8 crw--- 1 root root 3, 9 2007-03-21 00:58 s9 On Wed, 2006-04-19 at 08:11 -0400, Greg Wooledge wrote: On Tue, Apr 18, 2006 at 09:58:24AM -0500, Christ, Bryan wrote: Most of the suggestions I have read say to chmod 666 /dev/tty, but my /dev/tty is a directory. That's bad. That's very, very bad. I'd suggest you get in touch with one of the support forums (mailing lists, IRC channels, etc.) for your operating system. ssh [EMAIL PROTECTED] Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-with-mic,password). If you did indeed issue chmod 666 on a directory, that might explain part of the problem -- a directory which lacks the execute bit would be untraversable. debug1: read_passphrase: can't open /dev/tty: Is a directory debug3: packet_send2: adding 8 (len 51 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password Permission denied, please try again. *nod* Whatever your Linux distribution has done, fixing it is probably outside the scope of this mailing list. /dev/tty is supposed to be a character device node. Shell scripts and other Unix programs have *always* been able to count on read foo /dev/tty working. If /dev/tty is a directory, that will break a *lot* of stuff. I'm hesitant to suggest even something as simple as man MAKEDEV, for fear that any attempt to fix this snafu (without understanding the primary cause) will just make it worse.
Re: Permission denied - check you console
Mike, Here is the solution. Apparently this is a particular problem with slackware 10.0... http://www.pocketace.net/pocketace.php?pg=articlesar=slackware) (excerpt) The Slackware udev.rules included with Slackware 10 needs to be altered for the man, less and ssh commands to work properly. To fix this problem you need to edit the /etc/udev/rules.d/udev.rules file. The change is in the pty devices section, you need to change KERNEL=tty[p-za-e][0-9a-f]*, NAME=tty/s%n, SYMLINK=%k to read KERNEL=tty[p-za-e][0-9a-f]*, NAME=pty/s%n, SYMLINK=%k. Thats it just change the t to a p, and everything should work. Bryan On Thu, 2006-04-20 at 09:32 -0700, Mike Ireton wrote: Bryan, This problem also drove me absolutely bonkers once also, and what the deal was had to do with the fact that the 'console' device was invalid. There is some interaction which I still to this day don't fully understand, between ssh and /dev/console. This stuff the list is suggesting regarding /dev/tty* is in the same vein but only applies if you're logged in thru ssh already, and I suspect you're on your vga console. Would you humor me and do the following? ls -l /dev/console cat /proc/cmdline uname -a Also, your ttys all do look funky as the list noted. Have you tred: cd /dev ./MAKEDEV tty (MAKEDEV is the standard script which populates /dev with device entries) Also, is devfsd running perchance? Mike- Christ, Bryan wrote: Yes. I am completely at a loss. The Linux kernel version I updated to is 2.6.15.3. After chmoding 666 on /dev/tty, I changed it back to 777 because it is definitely a directory. Evidence below: [EMAIL PROTECTED]:/dev/tty# ls -l total 0 crw--- 1 root root 3, 10 2007-03-21 00:58 s crw--- 1 root root 3, 0 2007-03-21 00:58 s0 crw--- 1 root root 3, 1 2007-03-21 00:58 s1 crw--- 1 root root 3, 2 2007-03-21 00:58 s2 crw--- 1 root root 3, 3 2007-03-21 00:58 s3 crw--- 1 root root 3, 4 2007-03-21 00:58 s4 crw--- 1 root root 3, 5 2007-03-21 00:58 s5 crw--- 1 root root 3, 6 2007-03-21 00:58 s6 crw--- 1 root root 3, 7 2007-03-21 00:58 s7 crw--- 1 root root 3, 8 2007-03-21 00:58 s8 crw--- 1 root root 3, 9 2007-03-21 00:58 s9 On Wed, 2006-04-19 at 08:11 -0400, Greg Wooledge wrote: On Tue, Apr 18, 2006 at 09:58:24AM -0500, Christ, Bryan wrote: Most of the suggestions I have read say to chmod 666 /dev/tty, but my /dev/tty is a directory. That's bad. That's very, very bad. I'd suggest you get in touch with one of the support forums (mailing lists, IRC channels, etc.) for your operating system. ssh [EMAIL PROTECTED] Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-with-mic,password). If you did indeed issue chmod 666 on a directory, that might explain part of the problem -- a directory which lacks the execute bit would be untraversable. debug1: read_passphrase: can't open /dev/tty: Is a directory debug3: packet_send2: adding 8 (len 51 padlen 5 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password Permission denied, please try again. *nod* Whatever your Linux distribution has done, fixing it is probably outside the scope of this mailing list. /dev/tty is supposed to be a character device node. Shell scripts and other Unix programs have *always* been able to count on read foo /dev/tty working. If /dev/tty is a directory, that will break a *lot* of stuff. I'm hesitant to suggest even something as simple as man MAKEDEV, for fear that any attempt to fix this snafu (without understanding the primary cause) will just make it worse.
Permission denied, please try again
Can anyone help? I've started getting this message on my slackware box when trying to ssh out of it. I can ssh in, but not out. After google searching and scanning through the mailing lists, I found some discussions which seem to pertain to udev. The fact that I updated my kernel sometime ago may very well have something to do with it (udev). Most of the suggestions I have read say to chmod 666 /dev/tty, but my /dev/tty is a directory. This does seem to be at least part of the problem (verbose output at very bottom) Any thoughts? ssh [EMAIL PROTECTED] Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-with-mic,password). When I first discovered the issue, I was using the version of OpenSSH which came with initial release of slackware 10.0. Now I have upgraded to openssh-4.3p2. Thanks in advance, Bryan Christ OpenSSH_4.3p2, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug3: cipher ok: blowfish-cbc [blowfish-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [blowfish-cbc,aes256-cbc] debug3: ciphers ok: [blowfish-cbc,aes256-cbc] debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.0.103 [192.168.0.103] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3 debug1: match: OpenSSH_4.3 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: blowfish-cbc,aes256-cbc debug2: kex_parse_kexinit: blowfish-cbc,aes256-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,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: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,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_init: found hmac-md5 debug1: kex: server-client blowfish-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client-server blowfish-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 115/256 debug2: bits set: 522/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts Warning: Permanently added '192.168.0.103' (RSA) to the list of known hosts. debug2: bits set: 520/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug3: start over, passed a different list publickey,gssapi-with-mic,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug3: no such identity: /root/.ssh/id_rsa debug1: Trying private key:
