[Bug 2319] [PATCH REVIEW] U2F authentication

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2319

--- Comment #6 from Michael Stapelberg michael+mind...@stapelberg.de ---
(In reply to Damien Miller from comment #5)
 (In reply to Michael Stapelberg from comment #3)
  (In reply to Damien Miller from comment #2)
   I think it is best that you start with a description of the u2f
   authentication method protocol - it's much better to review that the
   protocol is sound before looking at the implementation. Could you
   write this up?
  
  From that comment it sounds like there is some misunderstanding here
  :).
  
  U2F stands for Universal Second Factor, see also
  http://en.wikipedia.org/wiki/Universal_2nd_Factor
  
  You can find the protocol specification on
  http://fidoalliance.org/specifications/download/
  
  I’ve done a presentation at our local computer club, you can find
  the slides here:
  https://www.noname-ev.de/w/File:C14h-u2f-how-security-keys-work.pdf
  — they contain a pretty high-level and easy to understand
  description of U2F.
  
  Is that what you were looking for? If not, let me know :).
 
 No, I'm looking for a description of what goes on the wire for SSH.
 Like what RFC4252 does for the existing SSH authentication methods.

Ah, I see. Here goes:

When the client starts the u2f authentication, it sends:

   byte  SSH_MSG_USERAUTH_REQUEST
   stringuser name in ISO-10646 UTF-8 encoding [RFC3629]
   stringservice name in US-ASCII
   stringmethod name in US-ASCII
   uint32U2F mode (authentication or registration)

1) In case the client requests registration, the server replies with:

   byte  SSH2_MSG_USERAUTH_INFO_REQUEST
   stringRegisterRequest

Where RegisterRequest is specified in
http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-javascript-api-ps-20141009.html#dictionary-registerrequest-members

After sending 'RegisterRequest' to the U2F security key, the client
sends back the security key’s response (see
http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-javascript-api-ps-20141009.html#dictionary-registerresponse-members):

   byte  SSH2_MSG_USERAUTH_INFO_RESPONSE
   stringRegisterResponse

Once the server verified the 'RegisterResponse' indeed signed the
original challenge, it extracts the user’s U2F public key and sends
back a ssh-u2f key line which the user should add to her
authorized_keys file:

   byte  SSH2_MSG_USERAUTH_INFO_REQUEST
   stringauthorizedKey

2) In case the client requests authentication, the server replies with:

   byte  SSH2_MSG_USERAUTH_INFO_REQUEST
   stringSignRequest

After sending 'SignRequest' (see
http://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-u2f-javascript-api-ps-20141009.html#dictionary-signrequest-members)
to the U2F security key, the client sends back the security key’s
response:

   byte  SSH2_MSG_USERAUTH_INFO_RESPONSE
   stringSignResponse

The authentication is successful if the server successfully verifies
that the signature on the 'SignResponse' was created with the formerly
registered public key.



As you can see, the protocol on the wire is fairly simple — I just
follow the JavaScript API because that is what libu2f-host expects.

Hope that helps, let me know if you have more questions.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2332] Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2332

Damien Miller d...@mindrot.org changed:

   What|Removed |Added

 CC||d...@mindrot.org

--- Comment #4 from Damien Miller d...@mindrot.org ---
(In reply to Petr Lautrbach from comment #3)

 But there seems to be a bug that you can't overwrite FingerprintHash
 option on the command line when it's set in a config file.

Can you give me a recipe to reproduce?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2332] Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2332

Petr Lautrbach plaut...@redhat.com changed:

   What|Removed |Added

 CC||plaut...@redhat.com

--- Comment #1 from Petr Lautrbach plaut...@redhat.com ---
It seems to be already changed in the development tree, see 
https://anongit.mindrot.org/openssh.git/commit/?id=56d1c83cdd1ac76f1c6bd41e01e80dad834f3994

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2334] New: Warn when weak Ciphers are used

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2334

Bug ID: 2334
   Summary: Warn when weak Ciphers are used
   Product: Portable OpenSSH
   Version: 6.7p1
  Hardware: Other
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: ssh
  Assignee: unassigned-b...@mindrot.org
  Reporter: thorsten.s...@email.de

Warn the user when the SSH client or server are using weak ciphers. 

This can be done by default, when using -v or on a specific
test-security parameter.

Client and Server settings should be tested.

According to

https://stribika.github.io/2015/01/04/secure-secure-shell.html

Many ciphers (but not all) are either weak or broken. By having an
automatic test in the tools we can improve the settings of the
currently used servers and clients. That would improve the average
security level in a simple anbd efficient way.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2333] forbid old Ciphers, KexAlgorithms and MACs by default

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2333

--- Comment #3 from kolafl...@kolahilft.de ---
I don't know any halfway recent SSH implementation that shouldn't work
without these.

Nevertheless:
What about a user-warning in interactive mode?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2332] Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2332

--- Comment #3 from Petr Lautrbach plaut...@redhat.com ---
You can put FingerprintHash=md5 into your ssh config files
(/etc/ssh/ssh_config, ~/.ssh/config) or use '-o FingerprintHash=md5'
directly on the command line.

$ ssh localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is
SHA256:WvwqGxIhzB8L7L3/V9v9cI4IZ+IxTtAGo2FXFRfpPSQ.


$ ssh -o FingerprintHash=md5 localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is
MD5:da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff.
...


$ ssh -o FingerprintHash=sha512 localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is
SHA512:lbvPnoYkOXD0yOv7C1iLFjrlPz0sg5ImLzT7ffZTte4iJ7MmZtHjBTRm9EimMAYKNGgB5XEHDs8gnCPnJCf5dQ.


But there seems to be a bug that you can't overwrite FingerprintHash
option on the command line when it's set in a config file.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2332] Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2332

--- Comment #2 from kolafl...@kolahilft.de ---
Just tested the current version from Git.

SHA256 is working great!

Gives me the SHA256 or MD5 fingerprint:
ssh-keygen -lv -E SHA256 -f id_rsa.pub
ssh-keygen -lv -E MD5 -f id_rsa.pub


But:

SSH client also needs an option to show MD5 (like ssh-keygen).

Why not also offer SHA512 for really paranoid people?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2306] ssh-add 6.7 inserts RSA keys into the ssh-agent as rsa w/o comment instead of filenames

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2306

Damien Miller d...@mindrot.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #1 from Damien Miller d...@mindrot.org ---
Fixed:

commit 1195f4cb07ef4b0405c839293c38600b3e9bdb46
Author: d...@openbsd.org d...@openbsd.org
Date:   Thu Jan 8 10:14:08 2015 +

upstream commit

deprecate key_load_private_pem() and
 sshkey_load_private_pem() interfaces. Refactor the generic key
loading API to
 not require pathnames to be specified (they weren't really used).

Fixes a few other things en passant:

Makes ed25519 keys work for hostbased authentication (ssh-keysign
previously used the PEM-only routines).

Fixes key comment regression bz#2306: key pathnames were being lost
as
comment fields.

ok markus@

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2266] Bugs intended to be fixed in 6.8

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2266
Bug 2266 depends on bug 2306, which changed state.

Bug 2306 Summary: ssh-add 6.7 inserts RSA keys into the ssh-agent as rsa w/o 
comment instead of filenames
https://bugzilla.mindrot.org/show_bug.cgi?id=2306

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching the reporter of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2332] Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2332

--- Comment #6 from Petr Lautrbach plaut...@redhat.com ---
works for me with this patch:

--- a/readconf.c
+++ b/readconf.c
@@ -1464,6 +1464,7 @@ parse_int:
goto parse_string;

case oFingerprintHash:
+   intptr = options-fingerprint_hash;
arg = strdelim(s);
if (!arg || *arg == '\0')
fatal(%.200s line %d: Missing argument.,
@@ -1471,8 +1472,8 @@ parse_int:
if ((value = ssh_digest_alg_by_name(arg)) == -1)
fatal(%.200s line %d: Invalid hash algorithm
\%s\.,
filename, linenum, arg);
-   if (*activep)
-   options-fingerprint_hash = value;
+   if (*activep  *intptr == -1)
+   *intptr = value;
break;

case oDeprecated:

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 2332] Show more secure fingerprints than MD5 (e.g. SHA256) in ssh and ssh-keygen

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=2332

Damien Miller d...@mindrot.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Damien Miller d...@mindrot.org ---
applied - thanks. I don't think there is anything left unfinished in
this bug then :)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 1768] scp: wrong error message when destination directory ends with a slash and is missing

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=1768

Jakub Jelen jje...@redhat.com changed:

   What|Removed |Added

 CC||jje...@redhat.com

--- Comment #2 from Jakub Jelen jje...@redhat.com ---
Created attachment 2523
  -- https://bugzilla.mindrot.org/attachment.cgi?id=2523action=edit
patch to improve error message

Hi,
I ran into this problem in RHBZ#1142223 [1] and tried to solve it.
After some time of digging in the source code I came up with solution
which I introduce here as a attachment. This added condition covers
only this one problematic case and according to regression test cases
published in portable tarbal, shouldn't bring here any regression.

Also I managed to write test case covering this problem. This file will
be attached as the second file.

Also I would like to say that the previous patch doesn't work, because
it will break recursive scp, for example:
 scp -r dir/ host:new_dir/
which is completely valid even if the new_dir doesn't exist.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1142223

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs


[Bug 1768] scp: wrong error message when destination directory ends with a slash and is missing

2015-01-08 Thread bugzilla-daemon
https://bugzilla.mindrot.org/show_bug.cgi?id=1768

--- Comment #3 from Jakub Jelen jje...@redhat.com ---
Created attachment 2524
  -- https://bugzilla.mindrot.org/attachment.cgi?id=2524action=edit
patch to verify this problem in regress test suite

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs