# ssh-key problems



## eeluve (Aug 16, 2012)

That is gonna be hard to explain but I'll do my best. So I have got say Debian with openssh5.5 using protocol 1(does not really matter, for example RHEL/Fedora's with 5.9 using p1 got the same problem). Got different FreeBSD servers, one of them is using openssh5.4 protocol 1, other one is on openssh5.8 protocol 2. Configuring the rsa key logins succeeds on to the first server, but does not by any means on the second one. I have played all the way around with protocol version settings(at the moment on all the systems I mentioned protocol 2 is used only, and they keep acting differently), auth file names(checked multiple times for them to be correct in configs), rights and anything possible to make it work but close to giving up now. ssh-agent is working everywhere, sockets and pids are fine. I have commented out everything in my sshrc's because they like to cause various problems. Created all possible types of the key: rsa(which, if I am correct, should be the one I need for 2 protocol?), rsa1, dsa and ssh-add'ed them(-l checked for 200% confidence). What else to look at? The one thing I do not really get, is why `# ssh -v` gives me strict version, say 1.5-2 or alike, while the configure files allow the selection and probably(or not?) support the 2nd protocol regardless of version output. Maybe my head is generally messed up abit, if I have forgotten to mention something and this could help, please ask any questions.


----------



## wblock@ (Aug 16, 2012)

From SSH Mastery by Michael Lucas, page 17:



> Always use SSH protocol version 2.  Do not use SSH-1.
> ...
> SSH-1 permits man-in-the-middle attacks and session hijacking, as discussed in Chapter 1.  If someone insists on using SSH-1, practice saying "I told you so."


----------



## eeluve (Aug 16, 2012)

You did not read, what I have written past the second line, right? I only use protocol 2 and tend to do so, this is exactly the problem because I may not make one of my FreeBSD servers to allow me to connect without beeing forced to type 25+ char "army" password. Maybe my mistake was calling the 
	
	



```
ssh -v
```
 output "using" in the beginning, but please catch the point.


----------



## Lowell (Aug 16, 2012)

Increase the debug output (for the client as well as the server) and see what that tells you (for instance, whether the client tries to present the key, and whether the server rejects it). Another trick would be to compare the sshd configurations, especially if they haven't been changed from defaults.

[If you're not using the outdated protocol, I have no idea why you spent so much time talking about it. So I just ignored that aspect entirely.]


----------

