From peter at stuge.se Thu Apr 1 00:30:54 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 31 Mar 2010 15:30:54 +0200 Subject: please decrypt your manuals In-Reply-To: <234751.12182.qm@web52308.mail.re2.yahoo.com> References: <234751.12182.qm@web52308.mail.re2.yahoo.com> Message-ID: <20100331133054.11199.qmail@stuge.se> OpenSSH documentation might assume strong familiarity with UNIX systems. I'm not sure that this is a bad thing. Doru Georgescu wrote: > I. most of ssh manual and all sshd manual present server and client > as one machine, called host. All files mentioned are placed on one > machine. This is incorrect, and makes the explanation unclear. I understand your point, but I don't think the documentation is incorrect. Every system is potentially both a server and a client, and there is only one set of manual pages. Although I think wording in OpenSSH man pages is already pretty good, I'm sure that patches which improve wording even further will be most welcome. > II. a general presentation of ssh workings is missing, This is completely out of scope for OpenSSH IMO. OpenSSH is one of many implementations of the protocol. How SSH works, in general, is very well described in the SSH RFCs. Please read RFC 4250 through 4254 for more info, at least RFC 4251. > both encrypt their messages with the encryption keys in: > both can memorize known hosts' public encryption keys in > /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts > only the server is protected through authentication. Check out the RFCs, then go back to the OpenSSH manual to learn more about how specifically OpenSSH maps SSH onto UNIX systems. > These few lines took me three frustating days of hard work, instead > of two easy hours of learning, and I am still not sure I guessed > rightly. I believe that this attitude makes Linux lose market in > favour of Windows servers. OpenSSH has nothing to do with Linux, really. And OpenSSH could not care less about the market of Linux. Finally, OpenSSH runs also on Windows. That said, I agree with you that open source requires ownership of one's problems. If you want to solve a problem with open source tools then you really need to understand the problem, and then the solution will be easy to find. Or you can hire a consultant to help. I find that Windows servers often do not even allow me to find out what the problem actually is, so even though I am fairly experienced with computers all my methods fail, because I get no data that I can try to use to find a solution. I can of course hire Microsoft, then they will gladly send someone to help me, maybe even without explaining what the problem was. > I hope that the author of sshd manual will correct his writing. That's really not very nice. I hope that YOU will correct the writing - if you think you can do it better! Please do! It would be fantastic to have even better documentation. Remember that the OpenSSH project is not the work of one single author, but the work of many people working together. It is very easy to get involved - just send an improvement of current state to the mailing list. > Please verify my "discoveries" above and publish them somewhere. Please ask specific questions. Noone will explain every single detail of OpenSSH to you - but I think many will be happy to give quick answers to straightforward questions. > Less important: > I still don't know if the encryption keys can be regenerated, Which encryption keys? There can be many keys involved already in SSH, and further keys introduced by the OpenSSH implementation. Please have a look at the protocol description, and ask a more specific question. > and I am not sure that every line sent from client to server is > authenticated, as it should. Again, have a look at the protocol, to learn more about the format of bytes between client and server. All data uses encryption and message authentication. > Also, I was surprised to see that I can not limit the number of > tries for passwords. That config option is about logging of tries, > not limiting them. sshd is not likely the only service in your system which accepts password authentication, so it is clearly not the appropriate entity to implement your security policy. Something else, more appropriate, would be PAM, but there are also other possibilities. In any case, I strongly recommend against using passwords for authentication at all. Create keys for your users instead. Kind regards //Peter From rees at umich.edu Thu Apr 1 02:35:38 2010 From: rees at umich.edu (Jim Rees) Date: Wed, 31 Mar 2010 11:35:38 -0400 Subject: Sending PATH using SendEnv In-Reply-To: <26E10875-54FA-41D4-9230-1B3364D2FAAB@staffmail.ed.ac.uk> References: <26E10875-54FA-41D4-9230-1B3364D2FAAB@staffmail.ed.ac.uk> Message-ID: <20100331153537.GA3555@merit.edu> Stuart Taylor wrote: I thought this was something that might concern the developers so I thought I'd post here. Apologies in advance if that's not the case. I'm setting up a CentOS cluster with OpenSSH_4.3p2 which uses ssh to launch processes on the remote nodes. I'm trying to use the SendEnv/AcceptEnv functionality to send the PATH environment variable from the headnode when users are launching jobs on remote nodes, since everything is cross-mounted and therefore in the same place. If everything is mounted in the same place, why aren't the users getting the same shell rc file on the remote machine, and therefore the same PATH? You forgot to say what shell you're using, but bash seems to inherit the PATH even if it's run as a login shell. But I wouldn't depend on login to preserve the PATH, in fact I'd be surprised if it did. This is not an ssh issue. From tim at multitalents.net Thu Apr 1 04:49:39 2010 From: tim at multitalents.net (Tim Rice) Date: Wed, 31 Mar 2010 10:49:39 -0700 (PDT) Subject: Sending PATH using SendEnv In-Reply-To: <26E10875-54FA-41D4-9230-1B3364D2FAAB@staffmail.ed.ac.uk> References: <26E10875-54FA-41D4-9230-1B3364D2FAAB@staffmail.ed.ac.uk> Message-ID: On Wed, 31 Mar 2010, Stuart Taylor wrote: [...] > Using verbose output I can see the client sending the vars, and if I create some test vars on the client and add them to the SendEnv/AcceptEnv statements in ssh_config/sshd_config, they are preserved in the remote environment, but PATH is not, and defaults to /usr/local/bin:/bin:/usr/bin, which is not very useful in this case. Take a look at do_setup_env() in session.c That is where the server sets PATH Use the --with-default-path= and --with-superuser-path= configure options to build with the path you want. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From heyu at nortel.com Thu Apr 1 17:47:44 2010 From: heyu at nortel.com (Yu He) Date: Thu, 1 Apr 2010 01:47:44 -0500 Subject: OpenSSH Coredump and "Bad packet length" errors seen on 5.10 sparc sun4v (Generic_125100-10) Message-ID: Hi, OpenSSH coredump was seen on our customer's side causing ssh login slow and manual command not workable. We need help to identify the root cause. Thanks!! >> Background: 1) server info: # uname -a SunOS owtnmncccm0cnmo 5.10 Generic_125100-10 sun4v sparc SUNW,Netra-CP3060 bash-3.00# /usr/local/bin/ssh -v OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007 bash-3.00# cat /usr/local/etc/sshd_config | grep -v "^#" | grep -v "^$" Subsystem sftp /usr/local/libexec/sftp-server 2) there is no user activities around the issue. A daemon script was running at background to sync certain files between our server pair (From unit A to unit B, both have same configuration and OS level) 3) After error happened, system hung and responsed very slowly to like ssh login 4) People had to reboot the server and everything looked fine afterwards. >> Coredump: # cd /var/core # ls -ltr -rw------- 1 root root 5199389 Feb 24 07:01 core_owtnmncccm0cnmo_ssh_0_0_1267016512_6729 # pstack core_owtnmncccm0cnmo_ssh_0_0_1267016512_6729 core 'core_owtnmncccm0cnmo_ssh_0_0_1267016512_6729' of 6729: /usr/local/bin/ssh root at server0-unit1 rm -f /etc/init.d/staticroutes ff1ee314 AES_decrypt (3c, d1, aaa5d0a5, 314, 74, 3b0) + 2f4 ff1ee66c AES_cbc_encrypt (74490, 774a8, 10, 6a358, 61fb8, 61fb8) +2c ff238abc aes_128_cbc_cipher (1, 774a8, 74490, 10, f0, ff2d9a18) + 1c ff23dfb8 EVP_Cipher (61f98, 774a8, 74490, 10, 61800, 62400) + 18 0002f3e4 cipher_crypt (61f94, 774a8, 74490, 10, f0, 7b528) + 34 000338a4 packet_read_poll_seqnr (ffbfe474, 62000, 62000, 620f0,61800, 62400) + 258 00033f94 packet_read_seqnr (0, 6, ffbfe510, 628a8, f0, 3c) + 40 00038bbc dispatch_run (0, ffbfe524, ffbfe510, ffbfe4f0, 624ac, ff) +1c 00025988 ssh_userauth2 (64568, 65250, 72e08, 628a8, 1, 0) + 52c 00021a20 ssh_login (72e08, 4, 45400, 14, 45400, a) + 3a4 000196b4 main (62b14, 647e4, 42a60, 42a58, 42800, 62800) + 8a4 00017e48 _start (0, 0, 0, 0, 0, 0) + 5 Around the coredump, many "Bad packet length" errors can be seen in /var/adm/message, like: Disconnecting: Bad packet length 2298694383. Feb 24 07:00:36 owtnmncccm0cnmo sshd[860]: [ID 800047 auth.info] Disconnecting: Bad packet length 604783901. Feb 24 07:00:36 owtnmncccm0cnmo sshd[873]: [ID 800047 auth.info] Disconnecting: Bad packet length 2577232018. >> More: SSH calling is by sync daemon script (from server0-unit0 to server0-unit1), trying to remove /etc/init.d/staticroutes file which is on unit1 but not on unit0 A snippet: message_out ${MSG_TRACE} "The replicated file $a_file does not exist; remove it from the other unit: $OTHERUNIT." yes /usr/local/bin/ssh root@${OTHERUNIT} "rm -f ${a_file}" rc=$? if [ $rc -ne 0 ]; then message_out $MSG_ERROR "Failed to delete ${a_file} on ${OTHERUNIT} with return code $rc." yes return 1 fi FYI: No record now if or not this calling (rm -f /etc/init.d/staticroutes) succeeded. Coredump and message files have back ups. Tell me if I need upload it somewhere. Looking forward to your help&advice Regards, Yu From niklas at komani.de Sat Apr 3 04:30:48 2010 From: niklas at komani.de (Niklas Schnelle) Date: Fri, 02 Apr 2010 19:30:48 +0200 Subject: Extremely weired Thunderbird OpenSSH interaction Message-ID: <1270229448.2360.6.camel@localhost.localdomain> Dear OpenSSH developers, first thank you for this great tool! Me and a friend have experienced some seriously crazy interaction between Thunderbird and OpenSSH, the problem is it's not reproducable but as it left definite traces on the server and it could be a serious security problem I still want to report it. so the following happened: My friend is running Ubuntu 9.10 with the new Thunderbird from a PPA he connected to our server (running Debian Lenny) using OpenSSH in a normal gnome-terminal. Then he launched Thunderbird from the application menu and now it's getting really weired. When thunderbird launched and connected to the IMAP Servers the SSH session in the currently unfocussed terminal was flooded with data, specifically with subject lines from the mails in Thunderbird this was to the degree that it created weired named files on our server like "Gesendet:" ("sent" in German) "bla at example.com" and so on. The interesting thing being that albeit those are garbage they are clearly noy chiffered. The only idea I could come up with is that somehow the OpenSSL Input buffer used by Thunderbird could have leaked into the one used by OpenSSH which would be quite catastrophic. It could also have to do with the clipboard but we weren't able to reproduce it or see anything like it with other software and he has been running this Thunderbird version for some time now. It's to fishy for a bug report but still to dangerours to simply ignore. Greetings Niklas Schnelle From arw at arw.name Sat Apr 3 05:50:00 2010 From: arw at arw.name (Alexander Wuerstlein) Date: Fri, 2 Apr 2010 20:50:00 +0200 Subject: Extremely weired Thunderbird OpenSSH interaction In-Reply-To: <1270229448.2360.6.camel@localhost.localdomain> References: <1270229448.2360.6.camel@localhost.localdomain> Message-ID: <20100402185000.GC13788@cip.informatik.uni-erlangen.de> On 10-04-02 19:45, Niklas Schnelle wrote: > Dear OpenSSH developers, > first thank you for this great tool! > Me and a friend have experienced some seriously crazy interaction > between Thunderbird and OpenSSH, the problem is it's > not reproducable but as it left definite traces on the server and it > could be a serious security problem I still want to report it. > so the following happened: > My friend is running Ubuntu 9.10 with the new Thunderbird from a PPA > he connected to our server (running Debian Lenny) using OpenSSH in a > normal gnome-terminal. Then he launched Thunderbird from the application > menu and now it's getting really weired. > When thunderbird launched and connected to the IMAP Servers the SSH > session in the currently unfocussed terminal was > flooded with data, specifically with subject lines from the mails in > Thunderbird this was to the degree that it created weired named files on > our server like "Gesendet:" ("sent" in German) > "bla at example.com" and so on. I would guess that you stumbled over the somewhat obscure and weird "remote" feature of some Mozilla products[1]. Try starting thunderbird with -no-remote as a parameter and see if it makes a difference. Ciao, Alexander Wuerstlein. [1] https://developer.mozilla.org/en/Command_Line_Options From hermitcrab at kelpworks.com Sat Apr 3 07:02:34 2010 From: hermitcrab at kelpworks.com (Samuel Winchenbach) Date: Fri, 2 Apr 2010 16:02:34 -0400 Subject: AuthorizedKeysFile with default value prevents Public/Private key authentication Message-ID: Hi All, I noticed that if I put: AuthorizedKeysFile .ssh/authorized_keys in my sshd_config file, pub/priv key authentication no longer worked. I am using OpenSSH_5.4p1, OpenSSL 0.9.8n 24 Mar 2010 on Archlinux. Sam ****************** Here is my WORKING config ****************** Port 22 ListenAddress 0.0.0.0 Protocol 2 PermitRootLogin no PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes Subsystem sftp /usr/lib/ssh/sftp-server ****************** END ****************** ****************** Here is my NON-WORKING config ****************** Port 22 ListenAddress 0.0.0.0 Protocol 2 PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no UsePAM yes Subsystem sftp /usr/lib/ssh/sftp-server ****************** END ****************** ****************** Here is a ssh -v to the server in question ****************** [swinchen at strongbad ~]$ ssh -v swinchen@********.org OpenSSH_5.4p1, OpenSSL 0.9.8n 24 Mar 2010 debug1: Reading configuration data /home/swinchen/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to ********.org [130.111.XXX.XXX] port 22. debug1: Connection established. debug1: identity file /home/swinchen/.ssh/id_rsa type -1 debug1: identity file /home/swinchen/.ssh/id_rsa-cert type -1 debug1: identity file /home/swinchen/.ssh/id_dsa type -1 debug1: identity file /home/swinchen/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4 debug1: match: OpenSSH_5.4 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.4 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host '********.org' is known and matches the RSA host key. debug1: Found key in /home/swinchen/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/swinchen/.ssh/id_rsa debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/home/swinchen/.ssh/id_rsa': debug1: read PEM private key done: type RSA debug1: Authentications that can continue: publickey debug1: Trying private key: /home/swinchen/.ssh/id_dsa debug1: No more authentication methods to try. Permission denied (publickey). ****************** END ****************** From rees at umich.edu Sat Apr 3 07:27:03 2010 From: rees at umich.edu (Jim Rees) Date: Fri, 2 Apr 2010 16:27:03 -0400 Subject: AuthorizedKeysFile with default value prevents Public/Private key authentication In-Reply-To: References: Message-ID: <20100402202703.GB6890@merit.edu> What happens if you change it to ~/.ssh/authorized_keys ? Maybe the man page is wrong. I could be paranoid but I avoid the use of relative paths in security sensitive config files. From imorgan at nas.nasa.gov Sat Apr 3 07:46:43 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 2 Apr 2010 13:46:43 -0700 Subject: AuthorizedKeysFile with default value prevents Public/Private key authentication In-Reply-To: References: Message-ID: <20100402204643.GH1314@linux55.nas.nasa.gov> This issue was reported to the list shortly after the release of 5.4p1 and should be fixed in an upcoming release. Please check the list archive for details. On Fri, Apr 02, 2010 at 15:02:34 -0500, Samuel Winchenbach wrote: > Hi All, > > I noticed that if I put: > > AuthorizedKeysFile .ssh/authorized_keys in my sshd_config file, > pub/priv key authentication no longer worked. > > I am using OpenSSH_5.4p1, OpenSSL 0.9.8n 24 Mar 2010 > on Archlinux. > > Sam > > > ****************** Here is my WORKING config ****************** > > Port 22 > ListenAddress 0.0.0.0 > > > Protocol 2 > > PermitRootLogin no > > PubkeyAuthentication yes > #AuthorizedKeysFile .ssh/authorized_keys > > PasswordAuthentication no > PermitEmptyPasswords no > > ChallengeResponseAuthentication no > > UsePAM yes > > Subsystem sftp /usr/lib/ssh/sftp-server > > ****************** END ****************** > ****************** Here is my NON-WORKING config ****************** > > > Port 22 > ListenAddress 0.0.0.0 > > > Protocol 2 > > PermitRootLogin no > > PubkeyAuthentication yes > AuthorizedKeysFile .ssh/authorized_keys > > PasswordAuthentication no > PermitEmptyPasswords no > > ChallengeResponseAuthentication no > > UsePAM yes > > Subsystem sftp /usr/lib/ssh/sftp-server > > ****************** END ****************** > ****************** Here is a ssh -v to the server in question > ****************** > > [swinchen at strongbad ~]$ ssh -v swinchen@********.org > OpenSSH_5.4p1, OpenSSL 0.9.8n 24 Mar 2010 > debug1: Reading configuration data /home/swinchen/.ssh/config > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Connecting to ********.org [130.111.XXX.XXX] port 22. > debug1: Connection established. > debug1: identity file /home/swinchen/.ssh/id_rsa type -1 > debug1: identity file /home/swinchen/.ssh/id_rsa-cert type -1 > debug1: identity file /home/swinchen/.ssh/id_dsa type -1 > debug1: identity file /home/swinchen/.ssh/id_dsa-cert type -1 > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4 > debug1: match: OpenSSH_5.4 pat OpenSSH* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.4 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-ctr hmac-md5 none > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host '********.org' is known and matches the RSA host key. > debug1: Found key in /home/swinchen/.ssh/known_hosts:1 > debug1: ssh_rsa_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey > debug1: Next authentication method: publickey > debug1: Trying private key: /home/swinchen/.ssh/id_rsa > debug1: PEM_read_PrivateKey failed > debug1: read PEM private key done: type > Enter passphrase for key '/home/swinchen/.ssh/id_rsa': > debug1: read PEM private key done: type RSA > debug1: Authentications that can continue: publickey > debug1: Trying private key: /home/swinchen/.ssh/id_dsa > debug1: No more authentication methods to try. > Permission denied (publickey). > ****************** END ****************** > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From hermitcrab at kelpworks.com Sat Apr 3 07:52:19 2010 From: hermitcrab at kelpworks.com (Samuel Winchenbach) Date: Fri, 2 Apr 2010 16:52:19 -0400 Subject: AuthorizedKeysFile with default value prevents Public/Private key authentication In-Reply-To: <20100402204643.GH1314@linux55.nas.nasa.gov> References: <20100402204643.GH1314@linux55.nas.nasa.gov> Message-ID: My apologies. I thought I searched the list correctly looking for a report. I must be mistaken. Thanks, Sam On Fri, Apr 2, 2010 at 4:46 PM, Iain Morgan wrote: > This issue was reported to the list shortly after the release of 5.4p1 > and should be fixed in an upcoming release. > > Please check the list archive for details. > > On Fri, Apr 02, 2010 at 15:02:34 -0500, Samuel Winchenbach wrote: >> Hi All, >> >> I noticed that if I put: >> >> AuthorizedKeysFile .ssh/authorized_keys in my sshd_config file, >> pub/priv key authentication no longer worked. >> >> I am using OpenSSH_5.4p1, OpenSSL 0.9.8n 24 Mar 2010 >> on Archlinux. >> >> Sam >> >> >> ****************** Here is my WORKING config ****************** >> >> Port 22 >> ListenAddress 0.0.0.0 >> >> >> Protocol 2 >> >> PermitRootLogin no >> >> PubkeyAuthentication yes >> #AuthorizedKeysFile ? .ssh/authorized_keys >> >> PasswordAuthentication no >> PermitEmptyPasswords no >> >> ChallengeResponseAuthentication no >> >> UsePAM yes >> >> Subsystem ? ? sftp ? ?/usr/lib/ssh/sftp-server >> >> ****************** END ****************** >> ****************** ?Here is my NON-WORKING config ****************** >> >> >> Port 22 >> ListenAddress 0.0.0.0 >> >> >> Protocol 2 >> >> PermitRootLogin no >> >> PubkeyAuthentication yes >> AuthorizedKeysFile ? ?.ssh/authorized_keys >> >> PasswordAuthentication no >> PermitEmptyPasswords no >> >> ChallengeResponseAuthentication no >> >> UsePAM yes >> >> Subsystem ? ? sftp ? ?/usr/lib/ssh/sftp-server >> >> ****************** ?END ****************** >> ****************** Here is a ssh -v to the server in question >> ****************** >> >> [swinchen at strongbad ~]$ ssh -v swinchen@********.org >> OpenSSH_5.4p1, OpenSSL 0.9.8n 24 Mar 2010 >> debug1: Reading configuration data /home/swinchen/.ssh/config >> debug1: Reading configuration data /etc/ssh/ssh_config >> debug1: Applying options for * >> debug1: Connecting to ********.org [130.111.XXX.XXX] port 22. >> debug1: Connection established. >> debug1: identity file /home/swinchen/.ssh/id_rsa type -1 >> debug1: identity file /home/swinchen/.ssh/id_rsa-cert type -1 >> debug1: identity file /home/swinchen/.ssh/id_dsa type -1 >> debug1: identity file /home/swinchen/.ssh/id_dsa-cert type -1 >> debug1: Remote protocol version 2.0, remote software version OpenSSH_5.4 >> debug1: match: OpenSSH_5.4 pat OpenSSH* >> debug1: Enabling compatibility mode for protocol 2.0 >> debug1: Local version string SSH-2.0-OpenSSH_5.4 >> debug1: SSH2_MSG_KEXINIT sent >> debug1: SSH2_MSG_KEXINIT received >> debug1: kex: server->client aes128-ctr hmac-md5 none >> debug1: kex: client->server aes128-ctr hmac-md5 none >> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP >> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent >> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY >> debug1: Host '********.org' is known and matches the RSA host key. >> debug1: Found key in /home/swinchen/.ssh/known_hosts:1 >> debug1: ssh_rsa_verify: signature correct >> debug1: SSH2_MSG_NEWKEYS sent >> debug1: expecting SSH2_MSG_NEWKEYS >> debug1: SSH2_MSG_NEWKEYS received >> debug1: Roaming not allowed by server >> debug1: SSH2_MSG_SERVICE_REQUEST sent >> debug1: SSH2_MSG_SERVICE_ACCEPT received >> debug1: Authentications that can continue: publickey >> debug1: Next authentication method: publickey >> debug1: Trying private key: /home/swinchen/.ssh/id_rsa >> debug1: PEM_read_PrivateKey failed >> debug1: read PEM private key done: type >> Enter passphrase for key '/home/swinchen/.ssh/id_rsa': >> debug1: read PEM private key done: type RSA >> debug1: Authentications that can continue: publickey >> debug1: Trying private key: /home/swinchen/.ssh/id_dsa >> debug1: No more authentication methods to try. >> Permission denied (publickey). >> ****************** END ****************** >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > Iain Morgan > From scott_n at xypro.com Sat Apr 3 08:10:37 2010 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 2 Apr 2010 14:10:37 -0700 Subject: AuthorizedKeysFile with default value prevents Public/Private keyauthentication In-Reply-To: References: <20100402204643.GH1314@linux55.nas.nasa.gov> Message-ID: <78DD71C304F38B41885A242996B96F73022A70E9@xyservd.XYPRO-23.LOCAL> > My apologies. I thought I searched the list correctly looking for a > report. I must be mistaken. > Look for an email from Corinna Vinschen on March 11, with subject "Re: Announce: OpenSSH 5.4 released" From jnierodzik at gmail.com Sat Apr 3 09:11:01 2010 From: jnierodzik at gmail.com (James Nierodzik) Date: Fri, 2 Apr 2010 17:11:01 -0500 Subject: Compiling for Windows Message-ID: <0AC478B6-47E0-46FD-9FC8-96D27B81B3FD@gmail.com> Hello OpenSSH devs, I'm hoping this is the proper forum for this question, but if not maybe some kind soul could point me in the right direction. I've been tasked with maintaing a Windows application that currently, or will need to, make use of the following tools: ? ssh-keygen ? ssh ? sshd ? sftp I know there are a few packages out there already CopSSH being one of them (which does work for my purposes albeit clunkily) but they all have various pitfalls. (footprint too large, no silent install, having to authorize users, no sftp support, etc?) so I am looking to compile my own. Ideally I would end up with the cygwin dlls required and my executable OpenSSH files that I could then dump in a directory on the Windows client, import the required registry keys from within my app and be off to the races. No 'real' installation required and a minimal footprint. So with all that said can anyone point me in the right direction of how to go about doing this? I've done a bit of research and mentally have been unable to put all the pieces in place. I appreciate any help and hopefully I won't get told to RTFM (unless you also want to point me to the appropriate section) =) Cheers, Jay From plambrechtsen at gmail.com Sat Apr 3 12:12:06 2010 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Sat, 3 Apr 2010 14:12:06 +1300 Subject: Compiling for Windows In-Reply-To: <0AC478B6-47E0-46FD-9FC8-96D27B81B3FD@gmail.com> References: <0AC478B6-47E0-46FD-9FC8-96D27B81B3FD@gmail.com> Message-ID: <66CC8D84-3BCC-474D-B101-0A86EF967A5F@gmail.com> On 3/04/2010, at 11:11 AM, James Nierodzik wrote: > Hello OpenSSH devs, > > I'm hoping this is the proper forum for this question, but if not > maybe some kind soul could point me in the right direction. > > I've been tasked with maintaing a Windows application that > currently, or will need to, make use of the following tools: > ? ssh-keygen > ? ssh > ? sshd > ? sftp So what's wrong with putty for everything apart from sshd? Works well, stable and has a good installer? In my experience all the sshd versions on windows have their own issues with either running as a service or other windows related issues when trying to run a unix service on a windows platform. Ymmv but the cygwin builds are the easist, albiet not the smallest or the most compatible for running a sshd. It really depends on what you are trying to achieve by having a sshd server on a windows host? > > I know there are a few packages out there already CopSSH being one > of them (which does work for my purposes albeit clunkily) but > they all have various pitfalls. (footprint too large, no silent > install, having to authorize users, no sftp support, etc?) so I am l > ooking to compile my own. > > Ideally I would end up with the cygwin dlls required and my > executable OpenSSH files that I could then dump in a directory on the > Windows client, import the required registry keys from within my app > and be off to the races. No 'real' installation required and a > minimal > footprint Cygwin is the only real way to go. Install it and then zip up the installed directory with all the packages you want, then it's pretty portable. > > > So with all that said can anyone point me in the right direction of > how to go about doing this? I've done a bit of research and > mentally have > been unable to put all the pieces in place. > > I appreciate any help and hopefully I won't get told to RTFM (unless > you also want to point me to the appropriate section) =) > > Cheers, > > Jay > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From headset001 at yahoo.com Mon Apr 5 21:23:44 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Mon, 5 Apr 2010 04:23:44 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <864129.63823.qm@web52302.mail.re2.yahoo.com> >> I. most of ssh manual and all sshd manual present server and client >> as one machine, called host. All files mentioned are placed on one >> machine. This is incorrect, and makes the explanation unclear. > I understand your point, but I don't think the documentation is > incorrect. Every system is potentially both a server and a client, > and there is only one set of manual pages. Please, help me understand what do you mean by "I understand your point", and "I don't think the documentation is incorrect". You mean, the manual shows good humour by explaining how to connect safely, using keys, from one computer to itself? I refer to man sshd, where the SSH_KNOWN_HOSTS FILE FORMAT section suggests to copy keys from /etc/ssh/ssh_host_key.pub into /etc/ssh/ssh_known_hosts, as if those files are on the same machine. > Although I think wording in OpenSSH man pages is already pretty good, > I'm sure that patches which improve wording even further will be most > welcome. I timidly propose to specify, for each file, the machine on which it lives, this way: //client/etc/ssh/ssh_host_key.pub and //server/etc/ssh/ssh_known_hosts. The fact that ssh and sshd are always installed together, and files for both client and server are present on each machine, only increases the manual reader's confusion. >> II. a general presentation of ssh workings is missing, > This is completely out of scope for OpenSSH IMO. OpenSSH is one of > many implementations of the protocol. > How SSH works, in general, is very well described in the SSH RFCs. > Please read RFC 4250 through 4254 for more info, at least RFC 4251. I referred to a short scheme about how ssh files are actually used and managed by the user. I tried to begin the creation of such a scheme in my paragraph II, which is no longer here ... ;-). >> both encrypt their messages with the encryption keys in: >> both can memorize known hosts' public encryption keys in >> /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts >> only the server is protected through authentication. > Check out the RFCs, then go back to the OpenSSH manual to learn more > about how specifically OpenSSH maps SSH onto UNIX systems. Are you sure that those RFC's explain whether /etc/ssh/ssh_known_hosts is used by the client or by the server? I didn't find this name in those RFC's, but maybe I can deduce somehow what ssh_known_hosts is doing if I read them. >> These few lines took me three frustating days of hard work, instead >> of two easy hours of learning, and I am still not sure I guessed >> rightly. I believe that this attitude makes Linux lose market in >> favour of Windows servers. > OpenSSH has nothing to do with Linux, really. > And OpenSSH could not care less about the market of Linux. > Finally, OpenSSH runs also on Windows. I thought about ssh as a part of Linux, but ssh manuals are part of the ssh product, and I expected its developers to care about the quality of their product. Can I access dos with ssh through cygwin? >> I hope that the author of sshd manual will correct his writing. > That's really not very nice. I hope that YOU will correct the > writing - if you think you can do it better! Please do! It would be > fantastic to have even better documentation. I started to propose small improvements. If we work out where do those files actually reside, I hope we will pass through the few lines in my paragaph II, sometimes. > Remember that the OpenSSH project is not the work of one single > author, but the work of many people working together. It is very easy > to get involved - just send an improvement of current state to the mailing list. I should improve my paragraph II, of course. I hope I will find help for this. >> Less important: >> I still don't know if the encryption keys can be regenerated, > Which encryption keys? There can be many keys involved already in > SSH, and further keys introduced by the OpenSSH implementation. > Please have a look at the protocol description, and ask a more > specific question. I was referring to the keys memorized in the /etc/ssh/ssh_host_dsa_key.pub and /etc/ssh/ssh_host_rsa_key.pub files. I suspect that they contain public keys used by both ssh client and server to encrypt their messages under protocol 2. >> and I am not sure that every line sent from client to server is >> authenticated, as it should. > Again, have a look at the protocol, to learn more about the format of > bytes between client and server. All data uses encryption and message > authentication. But there is no way to authenticate messages from server to client! This should be in RFC, anyway. >> Also, I was surprised to see that I can not limit the number of >> tries for passwords. That config option is about logging of tries, >> not limiting them. > sshd is not likely the only service in your system which accepts > password authentication, so it is clearly not the appropriate entity > to implement your security policy. Something else, more appropriate, > would be PAM, but there are also other possibilities. > In any case, I strongly recommend against using passwords for > authentication at all. Create keys for your users instead. Right, thanks for this. I'll use the keys ... :) > Kind regards > //Peter Thanks, maybe I'll untie this node. Doru From keisial at gmail.com Mon Apr 5 23:59:47 2010 From: keisial at gmail.com (Keisial) Date: Mon, 05 Apr 2010 15:59:47 +0200 Subject: please decrypt your manuals In-Reply-To: <864129.63823.qm@web52302.mail.re2.yahoo.com> References: <864129.63823.qm@web52302.mail.re2.yahoo.com> Message-ID: <4BB9ECD3.6050909@gmail.com> Doru Georgescu wrote: >>> I. most of ssh manual and all sshd manual present server and client >>> as one machine, called host. All files mentioned are placed on one >>> machine. This is incorrect, and makes the explanation unclear. >>> > >> I understand your point, but I don't think the documentation is >> incorrect. Every system is potentially both a server and a client, >> and there is only one set of manual pages. >> > Please, help me understand what do you mean by "I understand your point", and "I don't think the documentation is incorrect". You mean, the manual shows good humour by explaining how to connect safely, using keys, from one computer to itself? I refer to man sshd, where the SSH_KNOWN_HOSTS FILE FORMAT section suggests to copy keys from /etc/ssh/ssh_host_key.pub into /etc/ssh/ssh_known_hosts, as if those files are on the same machine. > > >> Although I think wording in OpenSSH man pages is already pretty good, >> I'm sure that patches which improve wording even further will be most >> welcome. >> > I timidly propose to specify, for each file, the machine on which it lives, this way: //client/etc/ssh/ssh_host_key.pub and //server/etc/ssh/ssh_known_hosts. The fact that ssh and sshd are always installed together, and files for both client and server are present on each machine, only increases the manual reader's confusion. > a) Your proposed format only makes it more confusing. b) You copy /etc/ssh/ssh_host_key.pub from the server to /etc/ssh/ssh_known_hosts on the client (or ~/.ssh/known_hosts the ~ character meaning your home directory). Not mentioning the place you would change, also makes it more difficult to review. I think you refer to the line that says "Bits, exponent, and modulus are taken directly from the RSA host key; they can be obtained, for example, from /etc/ssh/ssh_host_key.pub." I think that could be expanded by adding "from the server machine", although the previous phrase already concretises it, since to add the RSA host key for host foo, you need to copy that file from machine foo. >>> both encrypt their messages with the encryption keys in: >>> both can memorize known hosts' public encryption keys in >>> /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts >>> only the server is protected through authentication. >>> > >> Check out the RFCs, then go back to the OpenSSH manual to learn more >> about how specifically OpenSSH maps SSH onto UNIX systems. >> > Are you sure that those RFC's explain whether /etc/ssh/ssh_known_hosts is used by the client or by the server? I didn't find this name in those RFC's, but maybe I can deduce somehow what ssh_known_hosts is doing if I read them. > It's used by the client to maintain a list of trusted hosts keys. It's like ~/.ssh/known_hosts, but set by the administrator. >>> Less important: >>> I still don't know if the encryption keys can be regenerated, >>> > >> Which encryption keys? There can be many keys involved already in >> SSH, and further keys introduced by the OpenSSH implementation. >> Please have a look at the protocol description, and ask a more >> specific question. >> > I was referring to the keys memorized in the /etc/ssh/ssh_host_dsa_key.pub and /etc/ssh/ssh_host_rsa_key.pub files. I suspect that they contain public keys used by both ssh client and server to encrypt their messages under protocol 2. > AFAIK the files are used only by the server. The client will receive that public key from the handshake. You can regenerate them. Your users will get big warnings that someone may be trying to pose as your machine, so I recommend to properly publicise the change, or not to change them. >>> and I am not sure that every line sent from client to server is >>> authenticated, as it should. >>> > >> Again, have a look at the protocol, to learn more about the format of >> bytes between client and server. All data uses encryption and message >> authentication. >> > But there is no way to authenticate messages from server to client! This should be in RFC, anyway. > With ssh you open a secure tunnel between two ends. Anything passed through it is secure. You authenticate that the server is not a deceiver by checking that the provided key matches the one you have associated with that host, which you would have supposedly verified by some unspecified secure mean. There's no authentication on who holds the "client" end of the tunnel, that's why the first step after establishing the tunnel is to ask the user username + password or using a username + public key authentication (user public key usually stored in ~/.ssh/authorized_keys, see AuthorizedKeysFile of sshd_config). From christophe.lyon at st.com Tue Apr 6 23:47:57 2010 From: christophe.lyon at st.com (Christophe LYON) Date: Tue, 06 Apr 2010 15:47:57 +0200 Subject: scp reject remote users with space in username In-Reply-To: <4BB33AA0.7080009@st.com> References: <4BB33AA0.7080009@st.com> Message-ID: <4BBB3B8D.7000700@st.com> Hello, After some googling, I have found https://bugzilla.mindrot.org/show_bug.cgi?id=1164 and applied the mentioned patch, which solves my problem. But given the fact that the patch dates from 2006, I am wondering why it hasn't been applied to the main official sources. Is there a problem with it? Thanks Christophe. On 31.03.2010 14:05, Christophe LYON wrote: > Hello, > > I have noticed that since release 5.x of openssh, the scp command > rejects remote user names with white spaces. (We have such user names on > Windows hosts) > > For instance: > $ scp myfile "my user"@machine:. > used to work with openssh-4.2p1 and fails with 5.2p1 and 5.3p1: > my user: invalid user name. > > I have traced this down to revision 1.129 of scp.c which now calls > okname(). > > OTOH, ssh "my user"@machine works. > > Is this a bug, or a feature, and if so is there a workaround? > > Thanks. > > Christophe. From francois.perou at free.fr Wed Apr 7 01:05:22 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Tue, 06 Apr 2010 17:05:22 +0200 Subject: Using OpenSSH with smart cards HOWTO In-Reply-To: <4BBB2E9F.5040007@gmail.com> References: <1270143768.5159.6.camel@acer> <4BBB2E9F.5040007@gmail.com> Message-ID: <1270566322.4290.9.camel@acer> On Tue, 2010-04-06 at 15:52 +0300, Lars Nooden wrote: > You might wish to focus on sftp instead of scp. Okay, I will have a look. I had some problems: 1) I would like to store smart card information -o PKCS11Provider=/usr/lib/opensc-pkcs11.so in /etc/ssh/ssh-config. Is it possible? 2) ssh-add -s does not seem to work. Read: http://www.gooze.eu/howto/using-openssh-scp-with-smart-cards-pkcs11/using-ssh-authentication-agent-ssh-add-with Can anyone help with these issues. Kind regards, Jean-Michel From bob at proulx.com Wed Apr 7 04:27:59 2010 From: bob at proulx.com (Bob Proulx) Date: Tue, 6 Apr 2010 12:27:59 -0600 Subject: please decrypt your manuals In-Reply-To: <234751.12182.qm@web52308.mail.re2.yahoo.com> References: <234751.12182.qm@web52308.mail.re2.yahoo.com> Message-ID: <20100406182759.GA19744@dementia.proulx.com> Doru Georgescu wrote: > I. most of ssh manual and all sshd manual present server and client > as one machine, called host. Well, that is certainly one possibility. A single host may be operating both as a client and as a server *to itself* and that is perfectly okay. The documentation is very generically and very precisely correct by not making assumptions and simply explaining things dryly. > All files mentioned are placed on one machine. This is incorrect, > and makes the explanation unclear. But it isn't incorrect. A single host may be either a client or a server or both. The choice is completely controlled by how it is configured. The administrator may configure it ether one way or the other way or both ways. The documentation is very generically and very precisely correct by not making assumptions and simply explaining things dryly. > For example, man sshd SSH_KNOWN_HOSTS FILE FORMAT suggests to copy > keys from /etc/ssh/ssh_host_key.pub into /etc/ssh/ssh_known_hosts, > as if those files are on the same machine. I do not see that in my copy of the manual. I do see an explanation of where the bits come from. But I don't see a suggestion that a human do this copying. In fact I see an admonition that you would not want to "type them in by hand" but would instead "generate them by a script or by taking /etc/ssh/ssh_host_key.pub and adding the host names at the front." By "host names" it is clearly talking about multiple hosts, in the plural, and cannot be referring to a single host. But... I think most users of ssh can use it for many years and never even know about the files in /etc/ssh/*. It isn't necessary in the normal course of operation for them to know about them. I wouldn't recommend that a user copy files /etc/ssh/ssh_host_rsa_key.pub to their ~/known_hosts file. How would they actually do that? They would likely want to use ssh for that and that would be a bootstrapping problem. Better to check the hash fingerprint of the key in that case. > II. a general presentation of ssh workings is missing, and makes the > decryption of those manuals even more difficult. i suppose, but i am > not sure that: > > both encrypt their messages with the encryption keys in: > /etc/ssh/ssh_host_[rd]sa_key > /etc/ssh/ssh_host_[rd]sa_key.pub On one level I don't think this matters to a user. Users don't need to know this in order to use ssh securely. As an alternate example, people drive cars. People drive cars over bridges. Documenting how the bridge is constructed is definitely of interest to public safety but most drivers do not need to know how to construct a bridge in order to drive over one safely. Therefore I would leave this documentation for other resources. > both can memorize known hosts' public encryption keys in > /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts Checking the key's fingerprint is more commonly the check method of choice. > only the server is protected through authentication. this happens in > two ways: > > 1. server side: > a. the client provides an authentication key: > + public part in //server/~/.ssh/authorized_keys > with chmod 700 .ssh; chmod 600 authorized_keys It isn't necessary that the file not be readable, just not writable by other than the owner. Your use of 700 and 600 is too restrictive. > + private part in //client/~/.ssh/id_rsa There is a problem with using //client/etc/ssh/... and //server/etc/ssh/... types of paths in the documentation to mean that files reside on the client and server however. The "//" characters are special at the front of a path name. Apollo Domain systems, later OSF/1, and currently Cygwin all use it to indicate that the next part is a hostname. Because of this POSIX has standardized that when "//" occurs at the leading part of a path name that the result is implementation defined. (Or maybe undefined, I didn't look it up now to be certain.) Therefore it would be very confusing to use it here to indicate that some files exist on the client side of the ssh connection and another file on the server side of the ssh connection when, depending upon the system the user happens to be running on, the syntax on that machine might actually indicate something completely different from what you are trying to indicate. It is possible that on a user's system that //client/etc/... might be an actual working live path to a real system! They might end up trying it literally and getting files from some other system other than the one you intended. Therefore you shouldn't use it as an example meaning something completely different. Even though it doesn't work that way on most systems we avoid it out of neighborly politeness and respect for the standard. > the authentication key is created with: > ssh-keygen -t rsa > ll gives: > -rw------- 1 dave dave 526 Nov 3 01:21 id_rsa > -rw-r--r-- 1 dave dave 330 Nov 3 01:21 id_rsa.pub > and can be copied with (just a direct copy from > //client/~/.ssh/id_rsa.pub to //server/~/.ssh/authorized_keys, > or append to preserve other keys): > ssh-copy-id username at host The ssh man page already says: The user creates his/her key pair by running ssh-keygen(1). ... The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. A few more reinforcing "on the server host" and "on the client host" sprinkled through the docs may be beneficial though. > b. the client provides its password > > 2. client side: I think the client side should be described first. Since that is where most users will start. Otherwise before the cart is where the horse is put. > b. verifying the server's public encryption key against the > lists of servers' public encryption keys in: > //client/etc/ssh/ssh_known_hosts and //client/~/.ssh/known_hosts > you can copy and paste the key from > //server/etc/ssh/ssh_host_rsa_key.pub to > //client/~/.ssh/known_hosts, minus username at server at the end, > plus username at server at the beginning, with blanks as > separators. ssh-keygen -H to hash names. I think that is very confusing. I don't think it would survive most humans trying to execute those instructions. Better for most people is to verify the key fingerprint and let the software handle manipulating the known hosts information for you. I know many ssh users who have used it (securely) for years and have never known about /etc/ssh/ssh_host*.pub keys. I wouldn't start a user there. But of course if at a site with many systems locally then maintaining a site ssh_known_hosts by the site administrator makes sense. But again that isn't usually where people would start when learning about ssh. Site administrators are expected to have a familiarity with the operating system. > These few lines took me three frustating days of hard work, instead > of two easy hours of learning, and I am still not sure I guessed > rightly. The format of man pages makes them good reference documents but not so good user manuals. This has long been argued. HOWTO documents, tutorials, user manuals, and FAQs really are better served in a format more specific to their needs. There are many ssh HOWTOs and tutorials in the world. I think what you are realy wanting is to have ssh include the best of them with the ssh suite instead of having them be independent works available elsewhere. The problem is that someone would actually need to do the work and it would be a lot of work. There are a lot of good Getting Started style user manuals and HOWTOs that are available on the web. I would start there when trying to learn how to use ssh. They are a lot easier than the man pages. And if you try to change the man pages into a Gentle Introduction to ssh then they lose their value as man pages. > I believe that this attitude makes Linux lose market in favour of > Windows servers. OpenSSH really doesn't relate to Linux market share. Natively OpenSSH is part of OpenBSD which doesn't make use of Linux. GNU/Linux based systems use OpenSSH from OpenBSD as a port. (And we are very appreciative of it!) Plus ssh runs on all kinds of operating system platforms including MS-Windows. Someone trying to use ssh on MS-Windows could be just as frustrated and issue the same statement there too! > I still don't know if the encryption keys can be regenerated, and I > am not sure that every line sent from client to server is > authenticated, as it should. Also, I was surprised to see that I can > not limit the number of tries for passwords. That config option is > about logging of tries, not limiting them. When I think of encryption keys in conjuction with ssh connections I think of the session key used to encrypt the communication between the two hosts. This is handled automatically by ssh. You don't need to manually re-key the connection. However you may do so with a newline followed by "~R". Terminal escape characters are documented in the ssh(1) manual where it says: ~R Request rekeying of the connection (only useful for SSH protocol version 2 and if the peer supports it). The RekeyLimit is documented in the ssh_config(5) manual and says: RekeyLimit Specifies the maximum amount of data that may be transmitted before the session key is renegotiated. The argument is the num- ber of bytes, with an optional suffix of ?K?, ?M?, or ?G? to indicate Kilobytes, Megabytes, or Gigabytes, respectively. The default is between ?1G? and ?4G?, depending on the cipher. This option applies to protocol version 2 only. But you are probably thinking about keys used for user authentication. You can change those keys too. Of course if you do then the previous credentials are no longer valid and the new ones would need to be installed. I do this every so often as a matter of routine when I move from one system to another during system upgrades. Or you may be talking about host keys used for host identification. Host keys can certainly be changed too but doing so will appear to users the same as if the host were being attacked with a man in the middle attack. Therefore this type of change must be communicated such that the user can expect it and manually deal with the change. That would mean removing the old host key and verifying the fingerprint of the new host. Fortunately changing host keys isn't often needed and so this isn't something routinely seen. Bob From gorhas at gmail.com Wed Apr 7 04:36:43 2010 From: gorhas at gmail.com (Goran Hasse) Date: Tue, 6 Apr 2010 20:36:43 +0200 Subject: please decrypt your manuals In-Reply-To: <20100406182759.GA19744@dementia.proulx.com> References: <234751.12182.qm@web52308.mail.re2.yahoo.com> <20100406182759.GA19744@dementia.proulx.com> Message-ID: Godag! ... >> All files mentioned are placed on one machine. This is incorrect, >> and makes the explanation unclear. > > But it isn't incorrect. ?A single host may be either a client or a > server or both. ?The choice is completely controlled by how it is > configured. ?The administrator may configure it ether one way or the > other way or both ways. I think this should be more exactly stated as: A machine is nither a server nor a client. The *software* that runs on a machine could be implemented as a server (have a listen inside the code) or a client (have a connect inside the code). Some software are *both* servers and clients. So a machine is *not* configured to be a server or a client. You can place server software and/or client software on a machine. I know this is semantics but it is this semantics that make things difficult to grasp. -- gorhas at gmail.com Mob: 070-5530148 From markus.r.friedl at arcor.de Wed Apr 7 04:50:47 2010 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Tue, 6 Apr 2010 20:50:47 +0200 Subject: Using OpenSSH with smart cards HOWTO In-Reply-To: <1270566322.4290.9.camel@acer> References: <1270143768.5159.6.camel@acer> <4BBB2E9F.5040007@gmail.com> <1270566322.4290.9.camel@acer> Message-ID: <20100406185047.GA6064@folly> On Tue, Apr 06, 2010 at 05:05:22PM +0200, Fran?ois P?rou wrote: > On Tue, 2010-04-06 at 15:52 +0300, Lars Nooden wrote: > > You might wish to focus on sftp instead of scp. > Okay, I will have a look. > > I had some problems: > > 1) I would like to store smart card information > -o PKCS11Provider=/usr/lib/opensc-pkcs11.so > in /etc/ssh/ssh-config. Is it possible? yes, echo PKCS11Provider /usr/lib/opensc-pkcs11.so > /etc/ssh/config > 2) ssh-add -s does not seem to work. you have to use ssh-add -s /usr/lib/opensc-pkcs11.so From alex at alex.org.uk Wed Apr 7 05:14:57 2010 From: alex at alex.org.uk (Alex Bligh) Date: Tue, 06 Apr 2010 20:14:57 +0100 Subject: rsync over ssh, multiple private keys sharing same UID, chroot Message-ID: <511834AFD8C8AEA2F44AA86F@Ximines.local> I am thinking of configuring a service where multiple users have their own private keys to do rsync over ssh. I don't want each of these users to have their own UID. I want them each to share a UID, but to have space on the ssh server isolated from any other user. Let us assume that I also wish to prevent them from using any service other than rsync. Is this possible? Is a sensible approach to use authorized_keys2 ChrootDirectory and ForceCommand? Assuming that I only allow the shared user to write to a specific directory in each chroot setup (through access permissions), am I reasonably safe security wise? Or am better off hacking rsync to do the chroot stuff itself (as if rsync were running as a daemon). -- Alex Bligh From martin at oneiros.de Wed Apr 7 05:52:31 2010 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Tue, 6 Apr 2010 21:52:31 +0200 Subject: rsync over ssh, multiple private keys sharing same UID, chroot In-Reply-To: <511834AFD8C8AEA2F44AA86F@Ximines.local> References: <511834AFD8C8AEA2F44AA86F@Ximines.local> Message-ID: 2010/4/6 Alex Bligh : > Let us assume that I also wish to prevent them from using any > service other than rsync. Sure. Use the attached script in ForceCommand or google for more complex solutions. Best Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: rrsync.sh Type: application/x-sh Size: 347 bytes Desc: not available URL: From alex at alex.org.uk Wed Apr 7 07:54:22 2010 From: alex at alex.org.uk (Alex Bligh) Date: Tue, 06 Apr 2010 22:54:22 +0100 Subject: rsync over ssh, multiple private keys sharing same UID, chroot In-Reply-To: References: <511834AFD8C8AEA2F44AA86F@Ximines.local> Message-ID: <07BDE1D4CC6F282A20F5EEEC@[192.168.1.98]> --On 6 April 2010 21:52:31 +0200 Martin Schr?der wrote: > 2010/4/6 Alex Bligh : >> Let us assume that I also wish to prevent them from using any >> service other than rsync. > > Sure. Use the attached script in ForceCommand or google for more > complex solutions. How do you, for instance, prevent copies with (e.g.) --copy-unsafe-links set, with links which point outside the directory tree of the pseudo-user concerned, to other parts with the same UID? Or are you relying on chroot to handle that? I thought about pre-processing all the options to the rsync --server process, but that seems like lots of hard work prone to accidental failure. I suppose I could strip all options, except for a select few. I can't help think that if I could avoid rsync generating anything but regular files in one directory (which is all I need), I could avoid the whole chroot stuff. -- Alex Bligh From apb at cequrux.com Wed Apr 7 08:16:28 2010 From: apb at cequrux.com (Alan Barrett) Date: Wed, 7 Apr 2010 00:16:28 +0200 Subject: rsync over ssh, multiple private keys sharing same UID, chroot In-Reply-To: <511834AFD8C8AEA2F44AA86F@Ximines.local> References: <511834AFD8C8AEA2F44AA86F@Ximines.local> Message-ID: <20100406221628.GA1507@apb-laptoy.apb.alt.za> On Tue, 06 Apr 2010, Alex Bligh wrote: > I am thinking of configuring a service where multiple users have their > own private keys to do rsync over ssh. I don't want each of these > users to have their own UID. I want them each to share a UID, but > to have space on the ssh server isolated from any other user. > Let us assume that I also wish to prevent them from using any > service other than rsync. I'd probably trust rsync's daemon mode to keep the users separate, and not bother with user-specific chroots at the ssh level. Search for this example in the rsync man page: rsync -av -e "ssh -l ssh-user" rsync-user at host::module /dest The client users would all use the same "ssh-user" value, but different "rsync-user" values (or you could omit the rsync-user part from the command line, and let it default to whatever their local username is on the client machine -- the rsync-user name won't be used by the server-side configuration that I suggest below). Make each each line of the ssh authorized_keys file contain a command="..." option that refers to a wrapper script that verifies that $SSH_ORIGINAL_COMMAND looks like "rsync --server --daemon .", and then execs "rsync --config=/path/to/user-specific/rsyncd.conf --server --daemon .", with different ssh keys using different rsync configurations. Within each rsync daemon configuration file, specify the module names that the user is allowed to access, the corresponding directory names on the server, and whether they are read-only or read-write. --apb (Alan Barrett) From francois.perou at free.fr Wed Apr 7 15:25:26 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Wed, 07 Apr 2010 07:25:26 +0200 Subject: Using OpenSSH with smart cards HOWTO In-Reply-To: <20100406185047.GA6064@folly> References: <1270143768.5159.6.camel@acer> <4BBB2E9F.5040007@gmail.com> <1270566322.4290.9.camel@acer> <20100406185047.GA6064@folly> Message-ID: <1270617926.4277.2.camel@acer> On Tue, 2010-04-06 at 20:50 +0200, Markus Friedl wrote: > echo PKCS11Provider /usr/lib/opensc-pkcs11.so > /etc/ssh/config Thanks a lot. > > 2) ssh-add -s does not seem to work. ssh-add -s /usr/lib/opensc-pkcs11.so Enter passphrase for PKCS#11: SSH_AGENT_FAILURE Could not add card: /usr/lib/opensc-pkcs11.so How can I provide more debug? If you need a free PKI card and you live in the European-Union, I can send some for developing and testing OpenSSH. Kind regards, Jean-Michel From francois.perou at free.fr Wed Apr 7 15:33:30 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Wed, 07 Apr 2010 07:33:30 +0200 Subject: Using OpenSSH with smart cards HOWTO In-Reply-To: <1270617926.4277.2.camel@acer> References: <1270143768.5159.6.camel@acer> <4BBB2E9F.5040007@gmail.com> <1270566322.4290.9.camel@acer> <20100406185047.GA6064@folly> <1270617926.4277.2.camel@acer> Message-ID: <1270618410.5573.1.camel@acer> On Wed, 2010-04-07 at 07:25 +0200, Fran?ois P?rou wrote: > > echo PKCS11Provider /usr/lib/opensc-pkcs11.so > /etc/ssh/config /etc/ssh/ssh_config SendEnv LANG LC_* HashKnownHosts yes GSSAPIAuthentication yes GSSAPIDelegateCredentials no PKCS11Provider /usr/lib/opensc-pkcs11.so Then when I try ssh user at foo.com, it does not use smartcards. Permission denied (publickey). In fact, the -v lof shows that ssh does not search for smartcards. If you would like to implement more smart card features, it would be nice for some of you to have testing cards. To apply for free cards: http://www.gooze.eu/feitian-pki-free-software-developer-card Really, it would make me happy. Kind regards, Jean-Michel From headset001 at yahoo.com Thu Apr 8 02:40:45 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Wed, 7 Apr 2010 09:40:45 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <82976.3342.qm@web52303.mail.re2.yahoo.com> > >>> I. most of ssh manual and all sshd manual > present server and client > >>> as one machine, called host. All files > mentioned are placed on one > >>> machine. This is incorrect, and makes the > explanation unclear. > >>>? ? ??? > >??? > >> I understand your point, but I don't think the > documentation is > >> incorrect. Every system is potentially both a > server and a client, > >> and there is only one set of manual pages. > >>? ??? > > Please, help me understand what do you mean by "I > understand your point", and "I don't think the documentation > is incorrect". You mean, the manual shows good humour by > explaining how to connect safely, using keys, from one > computer to itself? I refer to man sshd, where the > SSH_KNOWN_HOSTS FILE FORMAT section suggests to copy keys > from /etc/ssh/ssh_host_key.pub into > /etc/ssh/ssh_known_hosts, as if those files are on the same > machine. > > > >??? > >> Although I think wording in OpenSSH man pages is > already pretty good, > >> I'm sure that patches which improve wording even > further will be most > >> welcome. > >>? ??? > > I timidly propose to specify, for each file, the > machine on which it lives, this way: > //client/etc/ssh/ssh_host_key.pub and > //server/etc/ssh/ssh_known_hosts. The fact that ssh and sshd > are always installed together, and files for both client and > server are present on each machine, only increases the > manual reader's confusion. > >??? > > a) Your proposed format only makes it more confusing. > b) You copy /etc/ssh/ssh_host_key.pub from the server to > /etc/ssh/ssh_known_hosts on the client (or > ~/.ssh/known_hosts the ~ > character meaning your home directory). You certainly are right, and I apologize for my mistake. I should have written: //server/etc/ssh/ssh_host_rsa_key.pub and //client/etc/ssh/ssh_known_hosts. Of course, one can say: /etc/ssh/ssh_host_rsa_key.pub on server and /etc/ssh/ssh_known_hosts on client. > > Not mentioning the place you would change, also makes it > more difficult > to review. > I think you refer to the line that says "Bits,? > exponent,? and? modulus > are? taken? directly? from? the? > RSA? host? key;? they? can? be > obtained, for example, from > ? ? > ???/etc/ssh/ssh_host_key.pub." > I think that could be expanded by adding "from the server > machine", > although the previous phrase already concretises it, since > to add the > RSA host key for host foo, you need to copy that file from > machine foo. Yes, every file mentioned in the sshd manual should be fully specified, that is, it should be always very clear if it lives on the server or on the client. The manual does not mention any machine foo. Maybe it tells you to copy that key from the server to the server, from the server to the client, from the client to the server, or from the client to the client. Or combinations of the above. Please show me clearly, step by step, how do you use the content of the sshd manual to conclude that /etc/ssh/ssh_host_key.pub is on the server. You can assume that I know about public-key cryptography from Wikipedia, and I know some Unix, but you can't assume that I know how did OpenSSH decide to protect itself against man-in-the-middle attacks before I read the manual. Also, I'm a user who only wants to use keys instead of passwords for authentication, for safety reasons, therefore I have no time to read RFC, code etc. Also, you may concede that the manual should be readable at 3 am, without requiring complicated logic over two RFC's and several manual pages only to find out on what machine is /etc/ssh/ssh_host_key.pub mentioned in the SSH_KNOWN_HOSTS FILE FORMAT paragraph of the sshd manual. > > > > > >>> both encrypt their messages with the > encryption keys in: > >>> both can memorize known hosts' public > encryption keys in > >>> /etc/ssh/ssh_known_hosts and > ~/.ssh/known_hosts > >>> only the server is protected through > authentication. > >>>? ? ??? > >??? > >> Check out the RFCs, then go back to the OpenSSH > manual to learn more > >> about how specifically OpenSSH maps SSH onto UNIX > systems. > >>? ??? > > Are you sure that those RFC's explain whether > /etc/ssh/ssh_known_hosts is used by the client or by the > server? I didn't find this name in those RFC's, but maybe I > can deduce somehow what ssh_known_hosts is doing if I read > them. > >??? > It's used by the client to maintain a list of trusted hosts > keys. It's > like ~/.ssh/known_hosts, but set by the administrator. Where is this specified in the manual. I respect your opinion, but this is not the subject of the post. The manual does not fully specify the files it refers, this is the subject of the post. Plus, are you sure that the server never uses /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts, according to sshd_config manual. If I guessed rightly, because that manual also does not fully specify the files it refers. > > > >>> Less important: > >>> I still don't know if the encryption keys can > be regenerated, > >>>? ? ??? > >??? > >> Which encryption keys? There can be many keys > involved already in > >> SSH, and further keys introduced by the OpenSSH > implementation. > >> Please have a look at the protocol description, > and ask a more > >> specific question. > >>? ??? > > I was referring to the keys memorized in the > /etc/ssh/ssh_host_dsa_key.pub and > /etc/ssh/ssh_host_rsa_key.pub files. I suspect that they > contain public keys used by both ssh client and server to > encrypt their messages under protocol 2. > >??? > AFAIK the files are used only by the server. The client > will receive > that public key from the handshake. > You can regenerate them. Your users will get big warnings > that someone > may be trying to pose as your machine, so I recommend to > properly > publicise the change, or not to change them. So the client uses another key for the encryption of the messages it receives? > > > >>> and I am not sure that every line sent from > client to server is > >>> authenticated, as it should. > >>>? ? ??? > >??? > >> Again, have a look at the protocol, to learn more > about the format of > >> bytes between client and server. All data uses > encryption and message > >> authentication. > >>? ??? > > But there is no way to authenticate messages from > server to client! This should be in RFC, anyway. > >??? > > With ssh you open a secure tunnel between two ends. > Anything passed > through it is secure. You authenticate that the server is > not a deceiver > by checking that the provided key matches the one you have > associated > with that host, which you would have supposedly verified by > some > unspecified secure mean. This procedure ensures that only the server can decrypt messages from the client, but still the client can receive messages from anybody in the middle and it can not tell if they come from the server or from the man-in-the-middle. So the server is not authenticated to the client. It goes one way only, as you see, the server does not supply any password or authentication key. I guess this is less important, because the client only displays messages from the server, it does not run commands from the server. > > There's no authentication on who holds the "client" end of > the tunnel, > that's why the first step after establishing the tunnel is > to ask the > user username + password or using a username + public key > authentication > (user public key usually stored in ~/.ssh/authorized_keys, > see > AuthorizedKeysFile of sshd_config). > > > > The client is authenticated to the server, it either supplies a password, or it has a special authentication key, whose public part is memorized in //server/~/.ssh/authorized_keys. Maybe it uses this algorithm: http://en.wikipedia.org/wiki/Rsa#Signing_messages. However, again, the server is not authenticated to the client. Doru From gorhas at gmail.com Thu Apr 8 04:08:52 2010 From: gorhas at gmail.com (Goran Hasse) Date: Wed, 7 Apr 2010 20:08:52 +0200 Subject: please decrypt your manuals In-Reply-To: <642511.7373.qm@web52302.mail.re2.yahoo.com> References: <642511.7373.qm@web52302.mail.re2.yahoo.com> Message-ID: 2010/4/7 Doru Georgescu : > I want to connect two computers, using openssh. One computer will be the client, there I sit in front of the console and do "ssh the_other_computer". The other computer will be the server. I want to connect using keys instead of a password, for improved security. > So: > I open the sshd manual and see that it refers to many files. Some of these files are on the server, others are on the client. Of course, there are files with the same name both on server and client. But the manual does not say when it refers to files on server, and when it refers to files on client. Therefore, the manual is incorrect, because it does not convey the information it is supposed to convey. Or you have some basic lack of understanding client/server software... You have missunderstood how files are used in Unix. In fact many files are used by both client software and server software. The files /etc/services and /etc/protocols are of this kind. If you write "man sshd" all configuration files should be stated, for the server, in the manual page and likewise "man ssh" should give all relevant files for the client. NOTE! Some of them *could* be the same! It is up to the programmer! > Now tell me what don't you understand in the above two paragraphs, because I certainly can tell what can't I understand in the large number of answers which I received on this list: why do none of them answer to what I said, and why do you everybody change the subject while still post in my thread? You can't write in a thread like this and say that the manuals are wrong, when you don't know the definition of client/server software, *and* refereing to machines as clients or server or operating systems as clients or server, without getting a lot of comments. Cordially yours, GH > > Doru > > > --- On Mon, 4/5/10, Goran Hasse wrote: > >> From: Goran Hasse >> Subject: Re: please decrypt your manuals >> To: "Doru Georgescu" >> Date: Monday, April 5, 2010, 8:50 AM >> Dear Doru, >> >> You should know that in the Unix environment it is *very* >> common to >> connect from one machine to "itself". If for instance a >> system have >> several interface (many IP addresses) this could be the >> only way to >> access some services. >> >> In fact, there is no sutch terms as server/client machines. >> Software >> can be server (they have a "listen" system call), and >> software could be >> clients (they have a "connect" system call). >> >> You should know that if you want to discuss those matters, >> the ssh >> mail list is *not* the place to do it. >> >> Cordially Yours, >> >> GH >> >> -- >> gorhas at gmail.com >> Mob: 070-5530148 >> > > > > -- gorhas at gmail.com Mob: 070-5530148 From peter at stuge.se Thu Apr 8 05:24:57 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 7 Apr 2010 21:24:57 +0200 Subject: please decrypt your manuals In-Reply-To: <82976.3342.qm@web52303.mail.re2.yahoo.com> References: <82976.3342.qm@web52303.mail.re2.yahoo.com> Message-ID: <20100407192457.26733.qmail@stuge.se> Doru Georgescu wrote: > Yes, every file mentioned in the sshd manual should be fully > specified, that is, it should be always very clear if it lives > on the server or on the client. The very first line of my sshd(8) man page reads: NAME sshd ? OpenSSH SSH daemon And after the list of flags there's: DESCRIPTION sshd (OpenSSH Daemon) is the daemon program for ssh(1). And in the next paragraph: sshd listens for connections from clients. This must be clear enough indication that sshd is the server program. So anything you read in the sshd man page must be in the context of the server program. If you read "daemon" on the first line and you're not yet sure of exactly what that means, then naturally the rest of the documentation will be of limited use to you. If you do want to learn about daemons and clients, then maybe allocate some time at an opportunity which is not 3am, and study how the system works. If you don't care about daemons and clients, then the sshd man page is of no use. > Please show me clearly, step by step, how do you use the content of > the sshd manual to conclude that /etc/ssh/ssh_host_key.pub is on > the server. The man page sshd(8) documents the server part of OpenSSH. In the FILES section it is therefore clear that these files are relevant only for the server. Under FILES, there's this paragraph which I think is really clear: --8<-- /etc/ssh/ssh_host_key.pub /etc/ssh/ssh_host_dsa_key.pub /etc/ssh/ssh_host_rsa_key.pub These three files contain the public parts of the host keys. These files should be world-readable but writable only by root. Their contents should match the respective private parts. These files are not really used for anything; they are provided for the convenience of the user so their contents can be copied to known hosts files. These files are created using ssh-keygen(1). -->8-- So the file is a *host* key. Further, the instructions on permissions for these files is very strong indication that they are not intended for users to write. > but you can't assume that I know how did OpenSSH decide to protect > itself against man-in-the-middle attacks before I read the manual. Remember that there are two concepts in this discussion. First of all there's the SSH protocol, which is well documented in RFCs. Then there is OpenSSH, an implementation of the protocol. There are many security features already at the protocol level which make SSH an excellent choice for any secure communication. There are also some security features within OpenSSH that may or may not be unique, compared to other SSH implementations. It is still not completely clear to me which of the two entities you are talking about. As I already wrote, the SSH protocol uses message authentication for all communication. > Also, I'm a user who only wants to use keys instead of passwords > for authentication, for safety reasons, therefore I have no time to > read RFC, code etc. I'm not sure you stated this very clearly, which could certainly be reason for the kind of replies that you get. It's important to ask the right thing. It can be difficult to do so, there are great essays on the subject. Anyway, if your role is as a user then you shouldn't start with the sshd man page. Instead, start with the ssh man page. It explains what files OpenSSH uses for public key authentication: --8<-- ~/.ssh/authorized_keys Lists the public keys (RSA/DSA) that can be used for logging in as this user. The format of this file is described in the sshd(8) manual page. This file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others. .. ~/.ssh/identity ~/.ssh/id_dsa ~/.ssh/id_rsa Contains the private key for authentication. These files contain sensitive data and should be readable by the user but not acces? sible by others (read/write/execute). ssh will simply ignore a private key file if it is accessible by others. It is possible to specify a passphrase when generating the key which will be used to encrypt the sensitive part of this file using 3DES. ~/.ssh/identity.pub ~/.ssh/id_dsa.pub ~/.ssh/id_rsa.pub Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone. -->8-- Now you know that you need to create an authorized_keys file. In fact, the first paragraph, on authorized_keys, should maybe not be in here at all since only the server looks at that file - but at least it has the reference to the sshd man page so that people can go there to get all the details on the file. In the sshd man page it says that you should copy your public key and into authorized_keys, and edit it to suit. Editing it is actually optional. > find out on what machine is /etc/ssh/ssh_host_key.pub > mentioned in the SSH_KNOWN_HOSTS FILE FORMAT paragraph of the sshd > manual. If nothing else is mentioned, you must assume that this file belongs to the server, since it's described in the sshd manual page. If this kind of logic does not come very naturally to you then there isn't much we can do to help. :\ > > Are you sure that those RFC's explain whether > > /etc/ssh/ssh_known_hosts is used by the client or by the > > server? Not at all. This suggests that you are (again?) confusing the protocol SSH with the implementation OpenSSH. The documentation relating to these two things will not neccessarily overlap very much, if at all. It's better for each entity to document it's own scope accurately, than for everyone to try to document everything. > > I didn't find this name in those RFC's, but maybe I can deduce > > somehow what ssh_known_hosts is doing if I read them. You need to first read the OpenSSH manual page for ssh and then sshd to learn what /etc/ssh/ssh_known_hosts is used for. > The manual does not fully specify the files it refers, Did you read all of the manual? It's really good to do so, but you should find a better time than 3am, if you are usually tired by then. > Plus, are you sure that the server never uses > /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts, according to > sshd_config manual. If I guessed rightly, because that manual also > does not fully specify the files it refers. Are you looking at the IgnoreUserKnownHosts directive? That also explains circumstances when the file is used, giving you further things to look up, and learn about. > So the client uses another key for the encryption of the messages > it receives? As I wrote there are many keys involved in the SSH protocol. Now you are discussing something completely unrelated to OpenSSH and manuals in OpenSSH. I don't think it's too off-topic for the list, but please remember to keep the distinction between the protocol and the implementation. Really, to get the details of the SSH protocol, you should look at the RFCs. They are not too dense, and should be digestable in a day or two if you want to read them from start to end. > This procedure ensures that only the server can decrypt messages > from the client, but still the client can receive messages from > anybody in the middle and it can not tell if they come from the > server or from the man-in-the-middle. So the server is not > authenticated to the client. It goes one way only, as you see, the > server does not supply any password or authentication key. I guess > this is less important, because the client only displays messages > from the server, it does not run commands from the server. This assumption is incorrect. Look at the protocol RFCs to learn all about how SSH client and server authenticate each other. In short, the client verifies the host key. Once the host key is considered to be approved (by the user in case of OpenSSH) the client will then continue to try to authenticate the user to the server. Once authentication is complete, the message authentication protects against any MITM attack. MITM is easy if the TCP session can be rerouted, but it's not possible to perform undetected MITM attack without access to the server host key. > The client is authenticated to the server, No. The user authenticates to a server. The client is never authenticated. > it either supplies a password, or it has a special authentication > key, whose public part is memorized in > //server/~/.ssh/authorized_keys. Maybe it uses this algorithm: > http://en.wikipedia.org/wiki/Rsa#Signing_messages. As you can see in both ssh and sshd man pages, as well as the RFC, the key that can be used for public key authentication of a user can be either RSA, DSA, or any local key type supported as a local extension of the SSH protocol. (key type blabla at mydomain.com) > However, again, the server is not authenticated to the client. Yes, it is. The client receives the server's host key, and OpenSSH let's the user decide if to go ahead with communication with this host, or not. Really, look at RFC 4251 and 4252. You may not even need to go into the details of 4252 to answer your questions. //Peter From keisial at gmail.com Thu Apr 8 08:43:00 2010 From: keisial at gmail.com (Keisial) Date: Thu, 08 Apr 2010 00:43:00 +0200 Subject: please decrypt your manuals In-Reply-To: <82976.3342.qm@web52303.mail.re2.yahoo.com> References: <82976.3342.qm@web52303.mail.re2.yahoo.com> Message-ID: <4BBD0A74.5050906@gmail.com> Doru Georgescu wrote: >> It's used by the client to maintain a list of trusted hosts >> keys. It's >> like ~/.ssh/known_hosts, but set by the administrator. >> > Where is this specified in the manual. I respect your opinion, but this is not the subject of the post. The manual does not fully specify the files it refers, this is the subject of the post. > "Host keys are stored in ~/.ssh/known_hosts in the user's home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts." > Plus, are you sure that the server never uses /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts, according to sshd_config manual. If I guessed rightly, because that manual also does not fully specify the files it refers. > That only applies to ssh v1 RhostsRSAAuthentication. You shouldn't use that (but it's a good point, anyway). >> AFAIK the files are used only by the server. The client >> will receive >> that public key from the handshake. >> You can regenerate them. Your users will get big warnings >> that someone >> may be trying to pose as your machine, so I recommend to >> properly >> publicise the change, or not to change them. >> > So the client uses another key for the encryption of the messages it receives? > They don't use the public key for message encryption. See below. >> With ssh you open a secure tunnel between two ends. >> Anything passed >> through it is secure. You authenticate that the server is >> not a deceiver >> by checking that the provided key matches the one you have >> associated >> with that host, which you would have supposedly verified by >> some >> unspecified secure mean. >> > This procedure ensures that only the server can decrypt messages from the client, but still the client can receive messages from anybody in the middle and it can not tell if they come from the server or from the man-in-the-middle. So the server is not authenticated to the client. It goes one way only, as you see, the server does not supply any password or authentication key. I guess this is less important, because the client only displays messages from the server, it does not run commands from the server. I'm not the most qualified one to explain this but... here I go. Anyone is welcome to fix me should I say something wrong. - C connects to S - They perform a Diffie-Hellman key exchange, and establish a private communication using a ephimeral key and a symmetrical cipher. >From this point on, they know they are talking to someone other and the connection cannot be read, or modified in any way. - S signs a token with its private key, so that C can verify that it is really the server it wants to talk to. - C present a password / signs another token with public key to authenticate with the server. A third party wouldn't be able to inject in the ciphered S->C stream. And the server does provide its public for authentication. You may see it more easily in HTTPS terms, which is based on the same protocol ideas, where the server provides a certificate (which in that case contain the domain name) and that certificate is also signed by a trusted authority. In this case there's no trusted CA, the user performs the validation by itself checking that the fingerprint matches the expected one. >> There's no authentication on who holds the "client" end of >> the tunnel, >> that's why the first step after establishing the tunnel is >> to ask the >> user username + password or using a username + public key >> authentication >> (user public key usually stored in ~/.ssh/authorized_keys, >> see >> AuthorizedKeysFile of sshd_config). >> > The client is authenticated to the server, it either supplies a password, or it has a special authentication key, whose public part is memorized in //server/~/.ssh/authorized_keys. Maybe it uses this algorithm: http://en.wikipedia.org/wiki/Rsa#Signing_messages. > Yes, that's more or less right. RSA is one of the algorithms it can use for the public keys. > However, again, the server is not authenticated to the client. > > Doru > It is. It proves that it is the server which you wanted to connect to. From andreas at zzlevo.net Thu Apr 8 16:24:04 2010 From: andreas at zzlevo.net (Andreas Gunnarsson) Date: Thu, 8 Apr 2010 08:24:04 +0200 Subject: please decrypt your manuals In-Reply-To: <20100407192457.26733.qmail@stuge.se> References: <82976.3342.qm@web52303.mail.re2.yahoo.com> <20100407192457.26733.qmail@stuge.se> Message-ID: <20100408062400.GA11031@zzlevo.net> On Wed, Apr 07, 2010 at 09:24:57PM +0200, Peter Stuge wrote: > MITM is easy if the TCP session can be rerouted, but it's not > possible to perform undetected MITM attack without access to the > server host key. And if user authentication is done with public keys then a man in the middle attack isn't possible even if the attacker knows the private part of the host key. At least not unless the server or the client has been compromised in other ways, e.g. if it is using a broken random number generator. Andreas From francois.perou at free.fr Thu Apr 8 20:00:23 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Thu, 08 Apr 2010 12:00:23 +0200 Subject: ssh-add -s /usr/lib/opensc-pkcs11.so does not work Message-ID: <1270720823.14453.5.camel@acer> Dear friends, First, thanks for helping me on ssh default option for smartcards. I recompiled SSH from CVS and it seems to work. I still have problems with: ssh-add -s /usr/lib/opensc-pkcs11.so Enter passphrase for PKCS#11: (I enter PIN code) SSH_AGENT_FAILURE Could not add card: /usr/lib/opensc-pkcs11.so pkcs11-tool --slot 1 -O Public Key Object; RSA 2048 bits label: Public Key ID: 7645d913d5***********54816ff02324c23a7ebf4 Usage: none Certificate Object, type = X.509 cert label: CAcert WoT User's Root CA ID ID: 7645d913d5***********54816ff02324c23a7ebf4 Public Key Object; RSA 2048 bits label: Public Key ID: 6d0534d04a***********49967a2e33571deec58 Usage: none Certificate Object, type = X.509 cert label: StartCom Free Certificate Member's StartCom Ltd. ID ID: 6d0534d04a***********49967a2e33571deec58 ps aux | grep ssh-agent jmpoure 2520 0.0 0.0 20420 600 ? Ss 09:04 0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/jmpoure/.gnupg/gpg-agent-info-acer /usr/bin/dbus-launch --exit-with-session /usr/bin/seahorse-agent --execute gnome-session I suspect this is not the right ssh-agent. Any idea? Kind regards, Fran?ois From francois.perou at free.fr Fri Apr 9 06:40:37 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Thu, 08 Apr 2010 22:40:37 +0200 Subject: ssh-add -s /usr/lib/opensc-pkcs11.so does not work In-Reply-To: <20100408162505.GA11546@folly> References: <1270720823.14453.5.camel@acer> <20100408162505.GA11546@folly> Message-ID: <1270759237.25685.10.camel@acer> On Thu, 2010-04-08 at 18:25 +0200, Markus Friedl wrote: > does > ssh-keygen -D /usr/lib/opensc-pkcs11.so > print the public keys? Yes, it does : ssh-keygen -D /usr/lib/opensc-pkcs11.so ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMd48TfLhCcr3QB**************************************3gB4+Zb4h0HS5+EhJiQSZFz5xgdBO7BqowucgYYHr3RX7S+PqNXcp/XO67piNQAn3SFiG01wa0tPXeNqcsA9+r7A2RDGPaLrzbiDpTboMPjyrnZi3b1AFTr/zK7mtb9upaed0aZdx9FFu/w6l7P5KsndWgP ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCnsHHbRxDrWQOfj90ybrJbT088FrwojJFHxWPKl1LtnGBSKeTAAzsWst9WcRSao4mF+UDEX6yYCSmVFzWY2xHq0yxoux3xWYu5e***********************************************Ff19FrWaMF25ul+gLFa4iyCykdNI7DvKGUNfIp/KoeHz5yVjiToKtOc+31TZAHcLcBKeUmxCQtyrsR9EQ7MeKHsfot4xotz6YqE/RPve+1dAvTl > you could also try to start the ssh-agent w/debugging: > > first terminal: > % ssh-agent -d > SSH_AUTH_SOCK=/tmp/ssh-SYLCbU29yI/agent.24984; export SSH_AUTH_SOCK; > echo Agent pid 24984; Okay. > other terminal: > % SSH_AUTH_SOCK=/tmp/ssh-SYLCbU29yI/agent.24984; export SSH_AUTH_SOCK; > % ssh-add -s /usr/lib/opensc-pkcs11.so > % ssh-add -L SSH_AUTH_SOCK=/tmp/ssh-SYLCbU29yI/agent.24984; export SSH_AUTH_SOCK; jmpoure at acer:~$ ssh-add -s /usr/lib/opensc-pkcs11.so Could not open a connection to your authentication agent. jmpoure at acer:~$ ssh-add -L Could not open a connection to your authentication agent. Houston, we have a problem :) Kind regards From openssh at roumenpetrov.info Fri Apr 9 07:47:06 2010 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Fri, 09 Apr 2010 00:47:06 +0300 Subject: cygwin install override files Message-ID: <4BBE4EDA.20805@roumenpetrov.info> The install from contrib/cygwin/Makefile will override files. See attached diff file "cygwin-Makefile.diff". Roumen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cygwin-Makefile.diff URL: From djm at mindrot.org Fri Apr 9 11:19:22 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Apr 2010 11:19:22 +1000 (EST) Subject: ssh-add -s /usr/lib/opensc-pkcs11.so does not work In-Reply-To: <1270759237.25685.10.camel@acer> References: <1270720823.14453.5.camel@acer> <20100408162505.GA11546@folly> <1270759237.25685.10.camel@acer> Message-ID: On Thu, 8 Apr 2010, Fran?ois P?rou wrote: > > other terminal: > > % SSH_AUTH_SOCK=/tmp/ssh-SYLCbU29yI/agent.24984; export SSH_AUTH_SOCK; > > % ssh-add -s /usr/lib/opensc-pkcs11.so > > % ssh-add -L > SSH_AUTH_SOCK=/tmp/ssh-SYLCbU29yI/agent.24984; export SSH_AUTH_SOCK; > jmpoure at acer:~$ ssh-add -s /usr/lib/opensc-pkcs11.so > Could not open a connection to your authentication agent. > jmpoure at acer:~$ ssh-add -L > Could not open a connection to your authentication agent. > > Houston, we have a problem :) Don't copy Markus' example literally - the actual SSH_AUTH_SOCK path is randomised. You will need to copy the SSH_AUTH_SOCK that your ssh-agent prints. -d From dtucker at zip.com.au Fri Apr 9 13:37:06 2010 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 09 Apr 2010 13:37:06 +1000 Subject: cygwin install override files In-Reply-To: <4BBE4EDA.20805@roumenpetrov.info> References: <4BBE4EDA.20805@roumenpetrov.info> Message-ID: <4BBEA0E2.5060706@zip.com.au> Roumen Petrov wrote: > The install from contrib/cygwin/Makefile will override files. See > attached diff file "cygwin-Makefile.diff". I think you meant "overwrite", and after I realised that your patch was reversed it made perfect sense :-) There's a couple of removals that need not have been removed so I've fixed them instead and committed it. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Apr 9 14:31:13 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Apr 2010 14:31:13 +1000 (EST) Subject: OpenSSH 5.5p1 about to be released Message-ID: Hi, I'm likely going to release 5.5p1 in the next couple of days, mainly for the AuthorizedKeys bug. If you would like to test on your platform or submit any patches (portability only) then this is your last chance :) -d From openssh at roumenpetrov.info Sat Apr 10 05:35:26 2010 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Fri, 09 Apr 2010 22:35:26 +0300 Subject: cygwin install override files In-Reply-To: <4BBEA0E2.5060706@zip.com.au> References: <4BBE4EDA.20805@roumenpetrov.info> <4BBEA0E2.5060706@zip.com.au> Message-ID: <4BBF817E.2040107@roumenpetrov.info> Hi Darren, Darren Tucker wrote: > Roumen Petrov wrote: >> The install from contrib/cygwin/Makefile will override files. See >> attached diff file "cygwin-Makefile.diff". > > I think you meant "overwrite", and after I realised that your patch was > reversed it made perfect sense :-) I didn't sent a patch . The attached file is previous post is just difference between repository version from yesterday and about one month old copy and only show that install is not correct. > There's a couple of removals that need not have been removed so I've > fixed them instead and committed it. Thanks > Thanks. > Roumen From imorgan at nas.nasa.gov Sat Apr 10 09:46:37 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 9 Apr 2010 16:46:37 -0700 Subject: OpenSSH 5.5p1 about to be released In-Reply-To: References: Message-ID: <20100409234637.GI1314@linux55.nas.nasa.gov> On Thu, Apr 08, 2010 at 23:31:13 -0500, Damien Miller wrote: > Hi, > > I'm likely going to release 5.5p1 in the next couple of days, mainly for > the AuthorizedKeys bug. If you would like to test on your platform or > submit any patches (portability only) then this is your last chance :) > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev The 20100410 snapshot builds and passes the regression tests on the following platforms: RHEL 5 (x86_64) SLES 10 (IA64) Solaris 9 (SPARC) AIX 5.3 -- Iain Morgan From francois.perou at free.fr Sat Apr 10 18:00:04 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Sat, 10 Apr 2010 10:00:04 +0200 Subject: OpenSSH 5.5p1 about to be released In-Reply-To: References: Message-ID: <1270886404.3545.2.camel@acer> On Fri, 2010-04-09 at 14:31 +1000, Damien Miller wrote: > I'm likely going to release 5.5p1 in the next couple of days, mainly > for > the AuthorizedKeys bug. If you would like to test on your platform or > submit any patches (portability only) then this is your last > chance :) Dear Damien, I am not sure, but would it be possible to validate ssh-agent and ssh-add with /usr/lib/opensc-pkcs11.so for smartcard management. This is my last problem with OpenSSH and if a bug remained it would be very painful to me. Thanks! From vinschen at redhat.com Sat Apr 10 18:41:00 2010 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 10 Apr 2010 10:41:00 +0200 Subject: OpenSSH 5.5p1 about to be released In-Reply-To: References: Message-ID: <20100410084100.GK28908@calimero.vinschen.de> On Apr 9 14:31, Damien Miller wrote: > Hi, > > I'm likely going to release 5.5p1 in the next couple of days, mainly for > the AuthorizedKeys bug. If you would like to test on your platform or > submit any patches (portability only) then this is your last chance :) Builds fine on Cygwin 1.7.4. The regression tests are passed, except for the sftp-glob test, which is expected on Cygwin given the usage of backslashes in the test. Since Cygwin supports POSIX paths as well as DOS paths, both, slashes and backslashes are valid directory separators and invalid in filenames. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From luciano at debian.org Mon Apr 12 06:16:16 2010 From: luciano at debian.org (Luciano Bello) Date: Sun, 11 Apr 2010 17:16:16 -0300 Subject: [PATCH] AuthorizedKeysFile: tokens for type and fingerprint Message-ID: <201004111716.24371.luciano@debian.org> Hello all, There are some scenarios where is useful to storage one key per authorized_keys in an OpenSSH server. This is particularly true in gitosis cases. It manages multiple repositories under the same user account and it may have escalation problems. In our case, the keys are stored in a MySQL database and queried by a fuse application when the authorized file is requested by OpenSSH. Of course we wanted to minimized the size of the query response. That's why we wrote the attached patch. It allows to use two new tokens in the AuthorizedKeysFile sshd_config option: * %t, user pubkey type * %f, user pubkey fingerprint So, "AuthorizedKeysFile ~/%t-%f.pubkey" will look for the key at ~/RSA-e9:6e:a0:72:c6:a3:29:f6:bd:79:f2:f8:e0:08:b4:14.pubkey. Maybe you have your own scenario where this may be useful. It would be nice if you put this code in. thanks, luciano -------------- next part -------------- A non-text attachment was scrubbed... Name: fp_token.patch Type: text/x-diff Size: 2990 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dkohn7 at gmail.com Wed Apr 14 00:38:26 2010 From: dkohn7 at gmail.com (david kohn7) Date: Tue, 13 Apr 2010 07:38:26 -0700 Subject: Size of data packets in SSH connection Message-ID: Hello, During an interactive connection (i.e past the login), is it true that all data packets (i.e data size of the packet excluding the TCP/IP headers) must be a multiple of 4? or it can it be odd? If so , will the other end hang up? Can it change during the connection? Is it also true for non interactive connections such as scp,sftp ? Thanks DK From djm at mindrot.org Wed Apr 14 06:44:54 2010 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Apr 2010 06:44:54 +1000 (EST) Subject: Size of data packets in SSH connection In-Reply-To: References: Message-ID: On Tue, 13 Apr 2010, david kohn7 wrote: > Hello, > During an interactive connection (i.e past the login), is it true that all > data packets (i.e data size of the packet excluding the TCP/IP headers) > must be a multiple of 4? or it can it be odd? If so , will the other end > hang up? No, the TCP packets can be any size. The SSH packets that they carry must be sized correctly and this depends on the cipher in use. See cipher.c in the OpenSSH source for the list of blocksizes. > Can it change during the connection? If the connection is rekeyed, yes. > Is it also true for non interactive connections such as scp,sftp ? It is a depends on the cipher used, not the interactivity of the connection. -d From dkohn7 at gmail.com Wed Apr 14 07:32:26 2010 From: dkohn7 at gmail.com (david kohn7) Date: Tue, 13 Apr 2010 17:32:26 -0400 Subject: Size of data packets in SSH connection In-Reply-To: References: Message-ID: > > No, the TCP packets can be any size. The SSH packets that they carry > must be sized correctly and this depends on the cipher in use. See > cipher.c in the OpenSSH source for the list of blocksizes. Thank you, i'll look into that.I can access the SSH packet data (via pcap), then this should be sized correctly(according to SSH). For example out of 10K connections, all SSH packet sizes were a multiple of 4[1], 30 connections had packets with odd number of bytes (nearly always sent by the server) . I'm guessing this could happen at the TCP/IP level (i am seeing this in tcpdump) - e.g fragmentation. Could this be the reason why I see it? Why would it be so rare? Thank you for your time DK [1] If i'm not mistaken, the LCD of all sizes irrespective of cipher used is 4 From djm at mindrot.org Wed Apr 14 15:20:11 2010 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Apr 2010 15:20:11 +1000 (EST) Subject: Size of data packets in SSH connection In-Reply-To: References: Message-ID: On Tue, 13 Apr 2010, david kohn7 wrote: > > > > No, the TCP packets can be any size. The SSH packets that they carry > > must be sized correctly and this depends on the cipher in use. See > > cipher.c in the OpenSSH source for the list of blocksizes. > > Thank you, i'll look into that.I > can access the SSH packet data (via pcap), then this should be sized > correctly(according to SSH). For example out of 10K connections, > all SSH packet sizes were a multiple of 4[1], 30 connections had > packets with odd number of bytes (nearly always sent by the server) > . > I'm guessing this could happen at the TCP/IP level (i am seeing this > in tcpdump) - e.g fragmentation. > Could this be the reason why I see it? Why would it be so rare? Before the cipher is brought up the packets are not forced to a cipher blocksize, so you might be seeing KEXINIT packets or client/server banners. > [1] If i'm not mistaken, the LCD of all sizes irrespective of > cipher used is 4 That's true for protocol 2, but protocol 1 has one cipher (DES) with a shorter blocksize. Occasionally people patch support for the null cipher into their SSH clients or servers and it has no blocksize either. -d From dkohn7 at gmail.com Thu Apr 15 01:17:13 2010 From: dkohn7 at gmail.com (david kohn7) Date: Wed, 14 Apr 2010 11:17:13 -0400 Subject: Size of data packets in SSH connection In-Reply-To: References: Message-ID: Thank you. > > Before the cipher is brought up the packets are not forced to a cipher > blocksize, so you might be seeing KEXINIT packets or client/server banners. > >> [1] If i'm not mistaken, the LCD of all sizes irrespective of >> cipher used is 4 > > That's true for protocol 2, but protocol 1 has one cipher (DES) with a > shorter blocksize. Occasionally people patch support for the null cipher > into their SSH clients or servers and it has no blocksize either. > From avi.albo at lantronix.com Thu Apr 15 01:30:31 2010 From: avi.albo at lantronix.com (Avi Albo) Date: Wed, 14 Apr 2010 08:30:31 -0700 Subject: sshd sending eof to peer instead of SSH_MSG_CHANNEL_CLOSE. Message-ID: <8128F0FD6C26E14C8EB4BFDB92B8D6B2DDF7FE@2putt.int.lantronix.com> I am using the ssh port forwarding feature. My configuration is as follows: On my server machine, running sshd, and app1. On my client machine, running ssh (client) and app2. The client connects to the server requesting remote port forwarding from port X on the server machine to port Y on the client machine. app2 is listening on port Y on the client machine. app1 connects to port X on the server machine. sshd (on the server machine) forwards the connection to the client machine, and the two applications begin to exchange data. app1 pushes bytes into the socket much faster than app2 can process, and there is a backlog on both machines. At some point, app1 gives up and terminates the session (by calling close()), as a result sshd on the server machine sends an SSH_MSG_CHANNEL_EOF to the peer. The two sides then wait. app2 does not know that its peer is gone, since its session with the ssh client is still active. ssh client, on the client machine does not terminate the session, because it hasn't received the SSH_MSG_CHANNEL_CLOSE message. I am not sure what sshd on the server machine is waiting for. Probably waiting for the ssh client to consume all of the backlog. Finally, my question: Is there a way to force sshd (on the server machine) to send SSH_MSG_CHANNEL_CLOSE and terminate the session immediately? ********************************************************************** This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. From djm at mindrot.org Thu Apr 15 08:37:46 2010 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Apr 2010 08:37:46 +1000 (EST) Subject: sshd sending eof to peer instead of SSH_MSG_CHANNEL_CLOSE. In-Reply-To: <8128F0FD6C26E14C8EB4BFDB92B8D6B2DDF7FE@2putt.int.lantronix.com> References: <8128F0FD6C26E14C8EB4BFDB92B8D6B2DDF7FE@2putt.int.lantronix.com> Message-ID: On Wed, 14 Apr 2010, Avi Albo wrote: > I am using the ssh port forwarding feature. My configuration is as > follows: > > On my server machine, running sshd, and app1. > > On my client machine, running ssh (client) and app2. > > The client connects to the server requesting remote port forwarding > from port X on the server machine to port Y on the client machine. > > app2 is listening on port Y on the client machine. > > app1 connects to port X on the server machine. > > sshd (on the server machine) forwards the connection to the client > machine, and the two applications begin to exchange data. > > app1 pushes bytes into the socket much faster than app2 can process, > and there is a backlog on both machines. > > At some point, app1 gives up and terminates the session (by > calling close()), as a result sshd on the server machine sends an > SSH_MSG_CHANNEL_EOF to the peer. > > The two sides then wait. app2 does not know that its peer is gone, > since its session with the ssh client is still active. > > ssh client, on the client machine does not terminate the session, > because it hasn't received the SSH_MSG_CHANNEL_CLOSE message. SSH protocol 2 channels are bidirectional, so they have a half-closed state where one direction is closed but the other is open. CLOSE messages are only send when both directions are closed (fully closed). If app2 is backlogged then it might not respond promptly to the half-close state, but you might be able to force the issue by having app1 close both its input and output file descriptors. Unfortunately, older OpenSSH and all non-OpenSSH implementations suffer from a protocol deficiency where the half-closed signalling is missing in one direction. If both ends are using a recent OpenSSH then this shouldn't be a problem. For more details, search for "eow at openssh.com" in the PROTOCOL file in the OpenSSH source distribution. -d From bartha at cerias.purdue.edu Thu Apr 15 16:17:52 2010 From: bartha at cerias.purdue.edu (Ashrith Barthur) Date: Thu, 15 Apr 2010 02:17:52 -0400 Subject: Odd Size SSH data frame Message-ID: I am doing a certain analysis with different kinds of traffic and SSH is one of them. I am using SSH Version 2 on the complete test bed. Also, I am doing in depth packet analysis and have landed up with some anomalies. 1. Out of Millions of packet there are about 5 packets that are of odd size. The size is only the data frame size considered after the TCP header has been removed. All other packets we have got even data size. It is also understood that if one were to be using SSH version 2 then the data frame would be a multiple of 4. 2. These packets are not occurring while there is a key negotiation or while there is a re-key in progress but they are happening bang in the middle of a data transfer. And its usually just one packet in the middle of thousands of other packets which have even, multiple of 4 size. 3. There is no IP fragmentation as the Offsets have been verified. I really wonder why these packets with odd Data frame size exist. I would be thankful if there could be some understanding about it. Regards Ashrith -- Please do not print this E-mail unless you really need to. From scott_n at xypro.com Fri Apr 16 01:28:51 2010 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 15 Apr 2010 08:28:51 -0700 Subject: Limit number of connections per user? Message-ID: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> I'm working from modified 5.0p1 codebase. What I'm looking for is a mechanism to limit the number of simultaneous connections on a per-user/IP basis. That is, disallow multiple simultaneous logins/authentication of the same user from different IP addresses. e.g.: fred from 10.1.1.1 - accept fred from 10.1.1.2 -- reject while fred is still connected from 10.1.1.1 fred from 10.1.1.1 - OK (same IP) --- all freds log out fred from 10.1.1.2 -- OK (fred not logged in) Is this doable, or not? I realize that the sshd architecture may make this difficult or impossible. ---- Scott Neugroschl From philipp_subx at redfish-solutions.com Fri Apr 16 03:57:18 2010 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Thu, 15 Apr 2010 11:57:18 -0600 Subject: QoS marking for Openssh In-Reply-To: <4BAA5DD3.6020004@redfish-solutions.com> References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> Message-ID: <4BC7537E.2010003@redfish-solutions.com> On 03/24/2010 12:45 PM, Philip A. Prindeville wrote: > Anyone want to code review: > > https://bugzilla.mindrot.org/show_bug.cgi?id=1733 > > > There's a patch attached. We're currently using it on astlinux. > > Thanks. > > We're using it now. Works great. I've built Fedora scratch images and posted those, and haven't gotten any negative feedback from anyone using them. What do we need to do at this point to get it committed? I'm hoping it can make 5.5p2? Maybe?? Thanks. From mouring at eviladmin.org Fri Apr 16 05:39:45 2010 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 15 Apr 2010 14:39:45 -0500 Subject: QoS marking for Openssh In-Reply-To: <4BC7537E.2010003@redfish-solutions.com> References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BC7537E.2010003@redfish-solutions.com> Message-ID: "p" releases beyond "p1" are normally used to fix portable issues. Since this is a feature add I suspect the soonest (if accepted) it will get it will be 5.6. Since it may have to go upstream to OpenBSD. - Ben On Apr 15, 2010, at 12:57 PM, Philip A. Prindeville wrote: > On 03/24/2010 12:45 PM, Philip A. Prindeville wrote: >> Anyone want to code review: >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=1733 >> >> >> There's a patch attached. We're currently using it on astlinux. >> >> Thanks. >> >> > > > We're using it now. Works great. > > I've built Fedora scratch images and posted those, and haven't gotten > any negative feedback from anyone using them. > > What do we need to do at this point to get it committed? > > I'm hoping it can make 5.5p2? Maybe?? > > Thanks. > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From scott_n at xypro.com Fri Apr 16 06:26:57 2010 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 15 Apr 2010 13:26:57 -0700 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> because I have a customer who requested it? > -----Original Message----- > From: Goran Hasse [mailto:gorhas at gmail.com] > Sent: Thursday, April 15, 2010 1:24 PM > To: Scott Neugroschl > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Limit number of connections per user? > > Why do you want to do this! This is totaly against all > praxis in a Unix environment! Users will bee VERY anyoyed. If they log > in from > home and then go to some other place and try to login and the server > says "rejected" > they will just get mad. (In my opinion). And mostly because they don't > understand > the logic in this. A unix is a multiuser, mutli session environment. > Scrap this idea! > > GH > > 2010/4/15 Scott Neugroschl : > > I'm working from modified 5.0p1 codebase. > > > > What I'm looking for is a mechanism to limit the number of > simultaneous > > connections on a per-user/IP basis. > > That is, disallow multiple simultaneous logins/authentication of the > > same user from different IP addresses. > > > > e.g.: > > > > fred from 10.1.1.1 - accept > > fred from 10.1.1.2 -- reject while fred is still connected from > 10.1.1.1 > > fred from 10.1.1.1 - OK (same IP) > > --- all freds log out > > fred from 10.1.1.2 -- OK (fred not logged in) > > > > Is this doable, or not? ?I realize that the sshd architecture may > make > > this difficult or impossible. > > > > ---- > > Scott Neugroschl > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > > -- > gorhas at gmail.com > Mob: 070-5530148 From gorhas at gmail.com Fri Apr 16 06:28:19 2010 From: gorhas at gmail.com (Goran Hasse) Date: Thu, 15 Apr 2010 22:28:19 +0200 Subject: Limit number of connections per user? In-Reply-To: <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> Message-ID: Educate your customer - don't just take his money! GH 2010/4/15 Scott Neugroschl : > because I have a customer who requested it? > >> -----Original Message----- >> From: Goran Hasse [mailto:gorhas at gmail.com] >> Sent: Thursday, April 15, 2010 1:24 PM >> To: Scott Neugroschl >> Cc: openssh-unix-dev at mindrot.org >> Subject: Re: Limit number of connections per user? >> >> Why do you want to do this! This is totaly against all >> praxis in a Unix environment! Users will bee VERY anyoyed. If they log >> in from >> home and then go to some other place and try to login and the server >> says "rejected" >> they will just get mad. (In my opinion). And mostly because they don't >> understand >> the logic in this. A unix is a multiuser, mutli session environment. >> Scrap this idea! >> >> GH >> >> 2010/4/15 Scott Neugroschl : >> > I'm working from modified 5.0p1 codebase. >> > >> > What I'm looking for is a mechanism to limit the number of >> simultaneous >> > connections on a per-user/IP basis. >> > That is, disallow multiple simultaneous logins/authentication of the >> > same user from different IP addresses. >> > >> > e.g.: >> > >> > fred from 10.1.1.1 - accept >> > fred from 10.1.1.2 -- reject while fred is still connected from >> 10.1.1.1 >> > fred from 10.1.1.1 - OK (same IP) >> > --- all freds log out >> > fred from 10.1.1.2 -- OK (fred not logged in) >> > >> > Is this doable, or not? ?I realize that the sshd architecture may >> make >> > this difficult or impossible. >> > >> > ---- >> > Scott Neugroschl >> > >> > _______________________________________________ >> > openssh-unix-dev mailing list >> > openssh-unix-dev at mindrot.org >> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > >> >> >> >> -- >> gorhas at gmail.com >> Mob: 070-5530148 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- gorhas at gmail.com Mob: 070-5530148 From gorhas at gmail.com Fri Apr 16 06:24:26 2010 From: gorhas at gmail.com (Goran Hasse) Date: Thu, 15 Apr 2010 22:24:26 +0200 Subject: Limit number of connections per user? In-Reply-To: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: Why do you want to do this! This is totaly against all praxis in a Unix environment! Users will bee VERY anyoyed. If they log in from home and then go to some other place and try to login and the server says "rejected" they will just get mad. (In my opinion). And mostly because they don't understand the logic in this. A unix is a multiuser, mutli session environment. Scrap this idea! GH 2010/4/15 Scott Neugroschl : > I'm working from modified 5.0p1 codebase. > > What I'm looking for is a mechanism to limit the number of simultaneous > connections on a per-user/IP basis. > That is, disallow multiple simultaneous logins/authentication of the > same user from different IP addresses. > > e.g.: > > fred from 10.1.1.1 - accept > fred from 10.1.1.2 -- reject while fred is still connected from 10.1.1.1 > fred from 10.1.1.1 - OK (same IP) > --- all freds log out > fred from 10.1.1.2 -- OK (fred not logged in) > > Is this doable, or not? ?I realize that the sshd architecture may make > this difficult or impossible. > > ---- > Scott Neugroschl > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- gorhas at gmail.com Mob: 070-5530148 From francois.perou at free.fr Fri Apr 16 07:10:31 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Thu, 15 Apr 2010 23:10:31 +0200 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: <1271365831.4358.7.camel@acer> On Thu, 2010-04-15 at 22:24 +0200, Goran Hasse wrote: > If they log in from > home and then go to some other place and try to login and the server > says "rejected" I think this is simultaneous access from different IPs, when people use TOR for example. This could be a nice security feature. From keisial at gmail.com Fri Apr 16 07:14:05 2010 From: keisial at gmail.com (Keisial) Date: Thu, 15 Apr 2010 23:14:05 +0200 Subject: Limit number of connections per user? In-Reply-To: <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> Message-ID: <4BC7819D.60600@gmail.com> >> -----Original Message----- >> From: Goran Hasse [mailto:gorhas at gmail.com] >> Sent: Thursday, April 15, 2010 1:24 PM >> To: Scott Neugroschl >> Cc: openssh-unix-dev at mindrot.org >> Subject: Re: Limit number of connections per user? >> >> Why do you want to do this! This is totaly against all >> praxis in a Unix environment! Users will bee VERY anyoyed. If they log >> in from >> home and then go to some other place and try to login and the server >> says "rejected" >> they will just get mad. (In my opinion). And mostly because they don't >> understand >> the logic in this. A unix is a multiuser, mutli session environment. >> Scrap this idea! >> >> GH >> >> >> 2010/4/15 Scott Neugroschl : >> >>> because I have a customer who requested it? >>> Try to reach ot the reason he wants it. I guess he really wants a program which bans multiple unsuccessful login attempts. Not allowing Fred to login twice could be done with PAM, but it would be like shooting itself in the foot. The users will still be able to run many programs (or just a single program with an high load), and when their connection drops (as will happen if they are not all in the same intranet) and they retry they will discover that the server hasn't noticed yet and they are locked out. From scott_n at xypro.com Fri Apr 16 07:19:01 2010 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 15 Apr 2010 14:19:01 -0700 Subject: Limit number of connections per user? In-Reply-To: <4BC7819D.60600@gmail.com> References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> <4BC7819D.60600@gmail.com> Message-ID: <78DD71C304F38B41885A242996B96F73022ECA91@xyservd.XYPRO-23.LOCAL> > -----Original Message----- > From: Keisial [mailto:keisial at gmail.com] = > >> -----Original Message----- > >> From: Goran Hasse [mailto:gorhas at gmail.com] > >> Why do you want to do this! This is totaly against all > >> praxis in a Unix environment! Users will bee VERY anyoyed. If they > log > >> in from > >> home and then go to some other place and try to login and the server > >> says "rejected" > >> they will just get mad. (In my opinion). And mostly because they > don't > >> understand > >> the logic in this. A unix is a multiuser, mutli session environment. > >> Scrap this idea! > >> 2010/4/15 Scott Neugroschl : > >> > >>> because I have a customer who requested it? > >>> > Try to reach ot the reason he wants it. I guess he really wants a > program > which bans multiple unsuccessful login attempts. Not allowing Fred to > login > twice could be done with PAM, but it would be like shooting itself in > the foot. > The users will still be able to run many programs (or just a single > program > with an high load), and when their connection drops (as will happen if > they > are not all in the same intranet) and they retry they will discover > that > the > server hasn't noticed yet and they are locked out. [[SAN]] What I'm really looking for is what Francois mentioned -- a ban on simultaneous logins from multiple IPs. From rick.jones2 at hp.com Fri Apr 16 06:45:26 2010 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 15 Apr 2010 13:45:26 -0700 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: <4BC77AE6.9060604@hp.com> Goran Hasse wrote: > Why do you want to do this! This is totaly against all praxis in a Unix > environment! Users will bee VERY anyoyed. If they log in from home and then > go to some other place and try to login and the server says "rejected" they > will just get mad. (In my opinion). And mostly because they don't understand > the logic in this. A unix is a multiuser, mutli session environment. Scrap > this idea! I agree it could be very annoying, but perhaps the customer "knows" that what the users are doing on the system is an "only one login required" thing and feels that having the second login attempt fail would be an (imperfect) indication of someone having stolen a username/password, or someone improperly sharing one? Never mind that they could in theory glean the same information from last/wtmp :) rick jones From kevin.brott at gmail.com Fri Apr 16 06:23:35 2010 From: kevin.brott at gmail.com (Kevin Brott) Date: Thu, 15 Apr 2010 13:23:35 -0700 Subject: OpenSSH 5.5p1 about to be released In-Reply-To: References: Message-ID: On Thu, Apr 8, 2010 at 21:31, Damien Miller wrote: > Hi, > > I'm likely going to release 5.5p1 in the next couple of days, mainly for > the AuthorizedKeys bug. If you would like to test on your platform or > submit any patches (portability only) then this is your last chance :) > > BUILDING openssh-SNAP-20100416.tar.gz powerpc-ibm-aix5.2.0.0 (AIX 5.2 SP10) - builds, all tests passed powerpc-ibm-aix5.3.0.0 (AIX 5.3 SP7) - builds, all tests passed powerpc-ibm-aix6.1.4.0 (AIX 6.1 SP4) - builds, all tests passed hppa2.0w-hp-hpux11.11 (HP-UX 11iv1) - builds, all tests passed ia64-hp-hpux11.23 (HP-UX 11iv2) - builds, all tests passed ia64-hp-hpux11.31 (HP-UX 11iv3) - builds, all tests passed i686-pc-linux-gnu (RH 6.2) - builds, all tests passed i686-pc-linux-gnu (RH 8.0) - builds, all tests passed i686-pc-linux-gnu (RHL AS 2.1) - builds, all tests passed i686-pc-linux-gnu (RHEL WS 3.6) - builds, all tests passed i686-pc-linux-gnu (RHEL AS 4.5) - builds, all tests passed x86_64-unknown-linux-gnu (RHEL AS 4.5) - builds, all tests passed powerpc64-unknown-linux-gnu (RHEL AS 4.7) - builds, all tests passed i686-pc-linux-gnu (RHEL 5.3) - builds, all tests passed x86_64-unknown-linux-gnu (RHEL 5.4) - builds, all tests passed i686-pc-linux-gnu (Ubuntu 6.06.2) - builds, all tests passed i686-pc-linux-gnu (Ubuntu 7.10) - builds, all tests passed x86_64-unknown-linux-gnu (Ubuntu 9.10) - builds, all tests passed -- # include /* Kevin Brott */ From djm at mindrot.org Fri Apr 16 11:02:44 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Apr 2010 11:02:44 +1000 (EST) Subject: Limit number of connections per user? In-Reply-To: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: On Thu, 15 Apr 2010, Scott Neugroschl wrote: > I'm working from modified 5.0p1 codebase. > > What I'm looking for is a mechanism to limit the number of > simultaneous connections on a per-user/IP basis. That is, disallow > multiple simultaneous logins/authentication of the same user from > different IP addresses. There isn't any way to do this at present and adding the ability would be a little tricky. The master server would need to maintain some state for each connection that is active so it can apply the rules. I have vague plans to get the listening server maintaining similar state for another reason (to track and act on frequent abnormal terminations), so the infrastructure might happen eventually. -d From djm at cvs.openbsd.org Fri Apr 16 11:03:16 2010 From: djm at cvs.openbsd.org (Damien Miller) Date: Thu, 15 Apr 2010 19:03:16 -0600 (MDT) Subject: Announce: OpenSSH 5.5 released Message-ID: <201004160103.o3G13Gg9021741@cvs.openbsd.org> OpenSSH 5.5 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested snapshots or donated to the project. More information on donations may be found at: http://www.openssh.com/donations.html This is a bugfix release. Changes since OpenSSH 5.4 ========================= * Unbreak sshd_config's AuthorizedKeysFile option for $HOME-relative paths * Fix compilation failures on platforms that lack dlopen() * Include a language tag when sending a protocol 2 disconnection message. * Make logging of certificates used for user authentication more clear and consistent between CAs specified using TrustedUserCAKeys and authorized_keys Portable OpenSSH: * Allow contrib/ssh-copy-id to fail gracefully when there are no keys in the ssh-agent. bz#1723 * Explicitly link libX11 into contrib/gnome-ssh-askpass2. bz#1725 * Allow ChrootDirectory to work in SELinux platforms. bz#1726 * Add configure.ac stanza for Haiku OS. bz#1741 * Enable utmpx support on FreeBSD where possible. bz#1732 * Use pkg-config to determine libedit linker flags where possible. bz#1744 Checksums: ========== - SHA1 (openssh-5.5.tar.gz) = 59864a048b09ad1b6e65a74d5d385d8189ab8c74 - SHA1 (openssh-5.5p1.tar.gz) = 361c6335e74809b26ea096b34062ba8ff6c97cd6 Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From gorhas at gmail.com Fri Apr 16 14:06:07 2010 From: gorhas at gmail.com (Goran Hasse) Date: Fri, 16 Apr 2010 06:06:07 +0200 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: Then plan from the beginning how to handle aliased interfaces! On FreeBSD it could look like: ifconfig -a rl0: flags=8843 mtu 1500 options=8 inet 192.5.36.21 netmask 0xfffffff0 broadcast 192.5.36.31 inet 192.5.36.24 netmask 0xffffffff broadcast 192.5.36.24 inet 192.168.10.10 netmask 0xffffffff broadcast 192.168.10.10 inet 192.168.10.11 netmask 0xffffffff broadcast 192.168.10.11 inet 192.168.10.12 netmask 0xffffffff broadcast 192.168.10.12 inet 192.170.10.1 netmask 0xffffffff broadcast 192.170.10.1 inet 192.170.10.2 netmask 0xffffffff broadcast 192.170.10.2 inet 192.170.10.3 netmask 0xffffffff broadcast 192.170.10.3 inet 192.170.10.4 netmask 0xffffffff broadcast 192.170.10.4 ether 00:50:22:40:2c:23 media: Ethernet autoselect (100baseTX ) status: active The interface is listening for all those ip numbers! And of course I could come from a machine with many interfaces going over different routes. This is the one and same machine! de0: flags=8843 mtu 1500 inet 192.5.36.2 netmask 0xfffffffc broadcast 192.5.36.3 inet6 fe80::2e0:29ff:fe0f:a097%de0 prefixlen 64 scopeid 0x1 inet 192.5.36.10 netmask 0xffffffff broadcast 192.5.36.10 ether 00:e0:29:0f:a0:97 media: Ethernet autoselect (100baseTX ) status: active de1: flags=8843 mtu 1500 inet 192.5.36.17 netmask 0xfffffff0 broadcast 192.5.36.31 inet6 fe80::2e0:29ff:fe0f:a096%de1 prefixlen 64 scopeid 0x2 ether 00:e0:29:0f:a0:96 media: Ethernet autoselect (100baseTX ) status: active dc0: flags=8843 mtu 1500 inet 192.5.36.81 netmask 0xfffffff0 broadcast 192.5.36.95 inet6 fe80::204:e2ff:fe1f:bd76%dc0 prefixlen 64 scopeid 0x3 ether 00:04:e2:1f:bd:76 media: Ethernet autoselect (none) status: no carrier dc1: flags=8843 mtu 1500 inet 192.5.36.49 netmask 0xfffffff0 broadcast 192.5.36.63 inet6 fe80::204:e2ff:fe1f:bd0e%dc1 prefixlen 64 scopeid 0x4 ether 00:04:e2:1f:bd:0e media: Ethernet autoselect (none) status: no carrier dc2: flags=8843 mtu 1500 inet 192.5.36.33 netmask 0xfffffff0 broadcast 192.5.36.47 inet6 fe80::204:e2ff:fe1f:bd6c%dc2 prefixlen 64 scopeid 0x5 ether 00:04:e2:1f:bd:6c media: Ethernet 100baseTX status: active ed0: flags=8843 mtu 1500 inet 192.5.36.97 netmask 0xfffffff0 broadcast 192.5.36.111 inet6 fe80::250:bfff:fe2f:46c4%ed0 prefixlen 64 scopeid 0x6 ether 00:50:bf:2f:46:c4 So you have to define what "the same user from different IP adresses" means! GH 2010/4/16 Damien Miller : > On Thu, 15 Apr 2010, Scott Neugroschl wrote: > >> I'm working from modified 5.0p1 codebase. >> >> What I'm looking for is a mechanism to limit the number of >> simultaneous connections on a per-user/IP basis. That is, disallow >> multiple simultaneous logins/authentication of the same user from >> different IP addresses. > > There isn't any way to do this at present and adding the ability would > be a little tricky. The master server would need to maintain some state > for each connection that is active so it can apply the rules. > > I have vague plans to get the listening server maintaining similar state > for another reason (to track and act on frequent abnormal terminations), > so the infrastructure might happen eventually. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- gorhas at gmail.com Mob: 070-5530148 From djm at mindrot.org Fri Apr 16 15:43:55 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Apr 2010 15:43:55 +1000 (EST) Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: On Fri, 16 Apr 2010, Goran Hasse wrote: > Then plan from the beginning how to handle aliased interfaces! > ... [ifconfig] > So you have to define what "the same user from different IP adresses" means! It means what it says it means, and the existence of aliases and policy routing don't really change the meaning. The fact that it is possible to circumvent address-based restrictions by changing one's address isn't news. -d From djm at mindrot.org Fri Apr 16 16:29:06 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Apr 2010 16:29:06 +1000 (EST) Subject: revised cert format and deprecation schedule Message-ID: Hi, I just committed this: > - djm at cvs.openbsd.org 2010/04/16 01:47:26 > [PROTOCOL.certkeys auth-options.c auth-options.h auth-rsa.c] > [auth2-pubkey.c authfd.c key.c key.h myproposal.h ssh-add.c] > [ssh-agent.c ssh-dss.c ssh-keygen.1 ssh-keygen.c ssh-rsa.c] > [sshconnect.c sshconnect2.c sshd.c] > revised certificate format ssh-{dss,rsa}-cert-v01 at openssh.com with > the following changes: > > move the nonce field to the beginning of the certificate where it > can better protect against chosen-prefix attacks on the signature > hash > > Rename "constraints" field to "critical options" > > Add a new non-critical "extensions" field > > Add a serial number > > The older format is still supported for authentication and cert > generation (use "ssh-keygen -t v00 -s ca_key ..." to generate a v00 > certificate) so it seems like an opportune time to mention the deprecation rules that I plan to follow for the certificate support as it is developed. There are basically three goals: 1) Develop OpenSSH certificates until they solve enough of the use-cases to be a compelling substitute for X.509 certs for a substantial number of users. This may require occasional backwards-incompatible changes. 2) Don't burn our early adopters by breaking their working configurations without ample warning. 3) Avoid having to be stuck with maintaining backwards compatibility code in perpetuity. This is for both workload and security reasons; more twisty compat code == more bugs. So my working, self-imposed policy is to retain backwards compatibility support for at least 13 months after the release that includes an incompatible change. This duration is intended to let users sign certs of one year duration and know that an OpenSSH release won't break them in their life time. A corollary of this is that you shouldn't sign certs that have an expiry date more than one year in the future if you want to be able to upgrade to the latest version at will. As an example, our next release will include the above incompatible change and will likely be made some time around July. Following this plan, I'll remove support for the v00 certificate format in the next release after August 2011. Hopefully this provides enough clarity for people to start using this certificate support with some confidence that we won't break it at random. Naturally this policy is open for discussion, but I'd prefer that the discussion happen *now* rather than when we are preparing for the release in late 2011. So have at it :) -d From gorhas at gmail.com Fri Apr 16 14:23:56 2010 From: gorhas at gmail.com (Goran Hasse) Date: Fri, 16 Apr 2010 06:23:56 +0200 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: There is also a problem of how to define a user. Is it the login name or is it the process UID that should be used? The /etc/passwd file sometimes looks like: # $FreeBSD: src/etc/master.passwd,v 1.25.2.6 2002/06/30 17:57:17 des Exp $ # root:*:0:0:Charlie &:/root:/bin/csh ketoroot:*:0:0:Charlie &:/root:/bin/csh nvtroot:*:0:0:Charlie &:/root:/bin/csh oskarroot:*:0:0:Charlie &:/root:/bin/csh toor:*:0:0:Bourne-again Superuser:/root: GH 2010/4/16 Damien Miller : > On Thu, 15 Apr 2010, Scott Neugroschl wrote: > >> I'm working from modified 5.0p1 codebase. >> >> What I'm looking for is a mechanism to limit the number of >> simultaneous connections on a per-user/IP basis. That is, disallow >> multiple simultaneous logins/authentication of the same user from >> different IP addresses. > > There isn't any way to do this at present and adding the ability would > be a little tricky. The master server would need to maintain some state > for each connection that is active so it can apply the rules. > > I have vague plans to get the listening server maintaining similar state > for another reason (to track and act on frequent abnormal terminations), > so the infrastructure might happen eventually. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- gorhas at gmail.com Mob: 070-5530148 From aris.adamantiadis at belnet.be Fri Apr 16 18:27:02 2010 From: aris.adamantiadis at belnet.be (Aris Adamantiadis) Date: Fri, 16 Apr 2010 10:27:02 +0200 Subject: Odd Size SSH data frame In-Reply-To: References: Message-ID: <4BC81F56.1030708@belnet.be> Hi Ashrith, There are lots of reasons which could create that situation. First, as you told, all SSH packets are multiple of the block size, which itself is a multiple of 4. But all SSH packets do not end as-is in TCP packets. TCP as a transport protocol can split SSH packets at will and reconstruct them later. What you've seen may be happening because of some firewall re-encoding the TCP stream, a certain host hitting a MTU value, ... The idea here is that one tcp packet does not always fit a SSH packet. Aris Ashrith Barthur a ?crit : > I am doing a certain analysis with different kinds of traffic and SSH is one > of them. I am using SSH Version 2 on the complete test bed. Also, I am doing > in depth packet analysis and have landed up with some anomalies. > > 1. Out of Millions of packet there are about 5 packets that are of odd size. > The size is only the data frame size considered after the TCP header has > been removed. All other packets we have got even data size. It is also > understood that if one were to be using SSH version 2 then the data frame > would be a multiple of 4. > > 2. These packets are not occurring while there is a key negotiation or while > there is a re-key in progress but they are happening bang in the middle of a > data transfer. And its usually just one packet in the middle of thousands of > other packets which have even, multiple of 4 size. > > 3. There is no IP fragmentation as the Offsets have been verified. > > I really wonder why these packets with odd Data frame size exist. I would be > thankful if there could be some understanding about it. > > Regards > Ashrith > -- Aris Adamantiadis -- BELNET, Customer Relations Technical Advisor t: +32 2 790 33 33 Dept: customer at belnet.be Contact: http://www.belnet.be/fr/content/contact From chrivers at iversen-net.dk Fri Apr 16 22:05:55 2010 From: chrivers at iversen-net.dk (Christian Iversen) Date: Fri, 16 Apr 2010 14:05:55 +0200 Subject: Limit number of connections per user? In-Reply-To: <78DD71C304F38B41885A242996B96F73022ECA91@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> <78DD71C304F38B41885A242996B96F73022ECA79@xyservd.XYPRO-23.LOCAL> <4BC7819D.60600@gmail.com> <78DD71C304F38B41885A242996B96F73022ECA91@xyservd.XYPRO-23.LOCAL> Message-ID: <4BC852A3.5050701@iversen-net.dk> On 2010-04-15 23:19, Scott Neugroschl wrote: >>>>> because I have a customer who requested it? >>>>> >> Try to reach ot the reason he wants it. I guess he really wants a >> program >> which bans multiple unsuccessful login attempts. Not allowing Fred to >> login >> twice could be done with PAM, but it would be like shooting itself in >> the foot. >> The users will still be able to run many programs (or just a single >> program >> with an high load), and when their connection drops (as will happen if >> they >> are not all in the same intranet) and they retry they will discover >> that >> the >> server hasn't noticed yet and they are locked out. > > [[SAN]] What I'm really looking for is what Francois mentioned -- a ban > on simultaneous logins from multiple IPs. Check out fail2ban. It will block hammering attempts. And always try to figure out what the customers _really_ want ;-) -- Med venlig hilsen Christian Iversen From rees at umich.edu Fri Apr 16 23:22:35 2010 From: rees at umich.edu (Jim Rees) Date: Fri, 16 Apr 2010 09:22:35 -0400 Subject: revised cert format and deprecation schedule In-Reply-To: References: Message-ID: <20100416132235.GA26954@merit.edu> I'm up to my knees in openssl x.509 cert code right now and although I'm not crazy about yet another cert format, I'm ecstatic at the thought of using pki without the nightmare of asn1. Thanks for taking this on. From Susan.Diller at PAETEC.com Fri Apr 16 23:23:04 2010 From: Susan.Diller at PAETEC.com (Diller, Susan (Sue)) Date: Fri, 16 Apr 2010 09:23:04 -0400 Subject: logging details Message-ID: Are there plans to expand the logging capabilities in OpenSSH, so that the details of what files were moved using sftp is included? If not, does anyone know of a good way to capture this information? Thanks in advance, - Sue Susan K. Diller UNIX Systems Administration PAETEC Communications, Inc. 600 WillowBrook Office Park Fairport, New York 14450 *(585) 413-2320 * susan.diller at paetec.com From scott_n at xypro.com Sat Apr 17 03:52:23 2010 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 16 Apr 2010 10:52:23 -0700 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: <78DD71C304F38B41885A242996B96F73022ECB8E@xyservd.XYPRO-23.LOCAL> > -----Original Message----- > From: Goran Hasse [mailto:gorhas at gmail.com] > Sent: Friday, April 16, 2010 10:43 AM > To: Damien Miller > Cc: Scott Neugroschl; openssh-unix-dev at mindrot.org > Subject: Re: Limit number of connections per user? > > 2010/4/16 Damien Miller : > > On Fri, 16 Apr 2010, Goran Hasse wrote: > > > >> Then plan from the beginning how to handle aliased interfaces! > >> ... [ifconfig] > >> So you have to define what "the same user from different IP > adresses" means! > > > > It means what it says it means, and the existence of aliases and > policy > > routing don't really change the meaning. The fact that it is possible > to > > circumvent address-based restrictions by changing one's address isn't > news. > > But I don't especially mean frauds. Sometimes when I am logged in from > one machine > I also have needs to logg in from my laptop, (traveling by GPRS), and > then, should I be > toold "You are already logged in from a different system". This sounds > like an invention > from Microsoft! ;-) [[SAN]] Different environments, different needs. I'm not saying this is a good thing for everyone. From gorhas at gmail.com Sat Apr 17 03:43:15 2010 From: gorhas at gmail.com (Goran Hasse) Date: Fri, 16 Apr 2010 19:43:15 +0200 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: 2010/4/16 Damien Miller : > On Fri, 16 Apr 2010, Goran Hasse wrote: > >> Then plan from the beginning how to handle aliased interfaces! >> ... [ifconfig] >> So you have to define what "the same user from different IP adresses" means! > > It means what it says it means, and the existence of aliases and policy > routing don't really change the meaning. The fact that it is possible to > circumvent address-based restrictions by changing one's address isn't news. But I don't especially mean frauds. Sometimes when I am logged in from one machine I also have needs to logg in from my laptop, (traveling by GPRS), and then, should I be toold "You are already logged in from a different system". This sounds like an invention from Microsoft! ;-) > > -d > -- gorhas at gmail.com Mob: 070-5530148 From djm at mindrot.org Sat Apr 17 07:45:54 2010 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Apr 2010 07:45:54 +1000 (EST) Subject: logging details In-Reply-To: References: Message-ID: On Fri, 16 Apr 2010, Diller, Susan (Sue) wrote: > Are there plans to expand the logging capabilities in OpenSSH, so that > the details of what files were moved using sftp is included? If not, > does anyone know of a good way to capture this information? sftp-server has supported this for a while. Try specifying: Subsystem sftp /usr/libexec/sftp-server -l VERBOSE in sshd_config (you might need a different path to sftp-server). -d From francois.perou at free.fr Sun Apr 18 17:36:43 2010 From: francois.perou at free.fr (=?ISO-8859-1?Q?Fran=E7ois_P=E9rou?=) Date: Sun, 18 Apr 2010 09:36:43 +0200 Subject: Limit number of connections per user? In-Reply-To: References: <78DD71C304F38B41885A242996B96F73022EC9A2@xyservd.XYPRO-23.LOCAL> Message-ID: <1271576203.17791.7.camel@acer> On Fri, 2010-04-16 at 19:43 +0200, Goran Hasse wrote: > Microsoft! Please, it is now 10 years that I did not boot into this system. From headset001 at yahoo.com Sun Apr 18 17:54:22 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Sun, 18 Apr 2010 00:54:22 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <55785.82946.qm@web52308.mail.re2.yahoo.com> > > I. most of ssh manual and all sshd manual present > server and client > > as one machine, called host. > > Well, that is certainly one possibility.? A single > host may be > operating both as a client and as a server *to itself* and > that is > perfectly okay.? The documentation is very generically > and very > precisely correct by not making assumptions and simply > explaining > things dryly. This "possibility" is a degenerated case, and the manual does not deliver the information it should. It is like teaching Pythagoras' theorem for the case of a triangle with one side zero. I am sure that you do not need to be a good computer programmer to understand this. > > > All files mentioned are placed on one machine. This is > incorrect, > > and makes the explanation unclear. > > But it isn't incorrect.? A single host may be either a > client or a > server or both.? The choice is completely controlled > by how it is > configured.? The administrator may configure it ether > one way or the > other way or both ways. > > The documentation is very generically and very precisely > correct by > not making assumptions and simply explaining things dryly. The manual is incorrect by not delivering the information it should. It presents a degenerated case which is useless for the normal user. > > > For example, man sshd SSH_KNOWN_HOSTS FILE FORMAT > suggests to copy > > keys from /etc/ssh/ssh_host_key.pub into > /etc/ssh/ssh_known_hosts, > > as if those files are on the same machine. > > I do not see that in my copy of the manual.? I do see > an explanation > of where the bits come from.? But I don't see a > suggestion that a > human do this copying.? In fact I see an admonition > that you would not > want to "type them in by hand" but would instead "generate > them by a > script or by taking /etc/ssh/ssh_host_key.pub and adding > the host > names at the front."? By "host names" it is clearly > talking about > multiple hosts, in the plural, and cannot be referring to a > single > host. In that case, the manual should distinguish between those multiple hosts. I am not going to discuss with you who is supposed to "take" and "add" that data, a human or a robot. > > But...? I think most users of ssh can use it for many > years and never > even know about the files in /etc/ssh/*.? It isn't > necessary in the > normal course of operation for them to know about > them.? I wouldn't > recommend that a user copy files > /etc/ssh/ssh_host_rsa_key.pub to > their ~/known_hosts file.? How would they actually do > that?? Sorry, but that's how it works. They > would likely want to use ssh for that and that would be a > bootstrapping problem.? I use public transportation. Anyway, it is more difficult for someone to put together a SMS and a ssh connection for a man in the middle attack, rather than to wait for you to established a connection unprotected against such an attack. Better to check the hash > fingerprint of the > key in that case. > I prefer to reserve that choice. I hope you don't propose that the paragraph I discuss in the sshd manual to be removed. > > II. a general presentation of ssh workings is missing, > and makes the > > decryption of those manuals even more difficult. i > suppose, but i am > > not sure that: > > > > both encrypt their messages with the encryption keys > in: > > /etc/ssh/ssh_host_[rd]sa_key > > /etc/ssh/ssh_host_[rd]sa_key.pub > > On one level I don't think this matters to a user.? > Users don't need > to know this in order to use ssh securely.? As an > alternate example, > people drive cars.? People drive cars over > bridges.? Documenting how > the bridge is constructed is definitely of interest to > public safety > but most drivers do not need to know how to construct a > bridge in > order to drive over one safely.? Therefore I would > leave this > documentation for other resources. Then, you should delete those files from the manual. They are used a lot there. What is the point with mentioning them, if they are not explained a little bit and if they are not actually necessary? > > > both can memorize known hosts' public encryption keys > in > > /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts > > Checking the key's fingerprint is more commonly the check > method of > choice. That is your choice. I have been already advised on this mail list to use keys instead of passwords and I also agree with this. > > > only the server is protected through authentication. > this happens in > > two ways: > > > > 1. server side: > >? ? ???a. the client provides > an authentication key: > >? ? ? ? ? + public part in > //server/~/.ssh/authorized_keys > >? ? ? ? ? > ???with chmod 700 .ssh; chmod 600 > authorized_keys > > It isn't necessary that the file not be readable, just not > writable by > other than the owner.? Your use of 700 and 600 is too > restrictive. OK. > > >? ? ? ? ? + private part in > //client/~/.ssh/id_rsa > > There is a problem with using //client/etc/ssh/... and > //server/etc/ssh/... types of paths in the documentation to > mean > that files reside on the client and server however.? > The "//" > characters are special at the front of a path name.? > Apollo Domain > systems, later OSF/1, and currently Cygwin all use it to > indicate that > the next part is a hostname.? Because of this POSIX > has standardized > that when "//" occurs at the leading part of a path name > that the > result is implementation defined.? (Or maybe > undefined, I didn't look > it up now to be certain.) > > Therefore it would be very confusing to use it here to > indicate that > some files exist on the client side of the ssh connection > and another > file on the server side of the ssh connection when, > depending upon the > system the user happens to be running on, the syntax on > that machine > might actually indicate something completely different from > what you > are trying to indicate.? It is possible that on a > user's system that > //client/etc/... might be an actual working live path to a > real system! > They might end up trying it literally and getting files > from some > other system other than the one you intended.? > Therefore you shouldn't > use it as an example meaning something completely > different.? Even > though it doesn't work that way on most systems we avoid it > out of > neighborly politeness and respect for the standard. OK, so use plain English: ~/.ssh/id_rsa on client. The issue is, do you agree that the manuals should fully specify the files they refer, that is, including the machine on which they live, or not? > > >? ? ???the authentication key > is created with: > >? ? ???ssh-keygen -t rsa > >? ? ???ll gives: > >? ? ???-rw-------? ? > 1 dave? ???dave? ? ? > ? ? 526 Nov? 3 01:21 id_rsa > >? ? ???-rw-r--r--? ? > 1 dave? ???dave? ? ? > ? ? 330 Nov? 3 01:21 id_rsa.pub > >? ? ???and can be copied with > (just a direct copy from > >? ? > ???//client/~/.ssh/id_rsa.pub to > //server/~/.ssh/authorized_keys, > >? ? ???or append to preserve > other keys): > > >? ? ???ssh-copy-id > username at host > > The ssh man page already says: > > ? The user creates his/her key pair by running > ssh-keygen(1).? ... > ? The user should then copy the public key to > ~/.ssh/authorized_keys > ? in his/her home directory on the remote machine. > > A few more reinforcing "on the server host" and "on the > client host" > sprinkled through the docs may be beneficial though. That only appears in one place in the ssh manual, and every file in the sshd manual can be found on both the server and client, and some files are actually used by both the ssh server and the ssh client software on one machine, such that the reader can not know about what functionality is the manual actually speaking and about what file precisely: the one on the server, or the one on the client? > > >? ? ???b. the client provides > its password > > > > 2. client side: > > I think the client side should be described first.? > Since that is > where most users will start.? Otherwise before the > cart is where the > horse is put. As a programmer, I saw that the server is running first, and that the server is protected by authentication, so I started with the server. However, if this change makes it to the manual, I wholeheartedly agree with it. > > >? ? ???b. verifying the > server's public encryption key against the > >? ? ???lists of servers' > public encryption keys in: > >? ? ? ? ? > //client/etc/ssh/ssh_known_hosts and > //client/~/.ssh/known_hosts > >? ? ???you can copy and paste > the key from > >? ? > ???//server/etc/ssh/ssh_host_rsa_key.pub to > >? ? > ???//client/~/.ssh/known_hosts, minus > username at server at the end, > >? ? ???plus username at server at > the beginning, with blanks as > >? ? ???separators. ssh-keygen > -H to hash names. > > I think that is very confusing.? I don't think it > would survive most > humans trying to execute those instructions. It should be put into plain English. This is a sketchy note. > > Better for most people is to verify the key fingerprint and > let the > software handle manipulating the known hosts information > for you.? I > know many ssh users who have used it (securely) for years > and have > never known about /etc/ssh/ssh_host*.pub keys.? I > wouldn't start a > user there.? But of course if at a site with many > systems locally then > maintaining a site ssh_known_hosts by the site > administrator makes > sense.? You caught me. But again that isn't usually where people > would start when > learning about ssh.? Site administrators are expected > to have a > familiarity with the operating system. Still, the manual should make sense. And I am neither a site administrator nor a dumb user. I am a user who wants to use ssh a bit more securely. And some site administrators are also beginners, and they should also read a sane manual. > > > These few lines took me three frustating days of hard > work, instead > > of two easy hours of learning, and I am still not sure > I guessed > > rightly. > > The format of man pages makes them good reference documents > but not so > good user manuals.? This has long been argued.? > HOWTO documents, > tutorials, user manuals, and FAQs really are better served > in a format > more specific to their needs.? There are many ssh > HOWTOs and tutorials > in the world.? I think what you are realy wanting is > to have ssh > include the best of them with the ssh suite instead of > having them be > independent works available elsewhere.? The problem is > that someone > would actually need to do the work and it would be a lot of > work. > > There are a lot of good Getting Started style user manuals > and HOWTOs > that are available on the web.? I would start there > when trying to > learn how to use ssh.? They are a lot easier than the > man pages.? And > if you try to change the man pages into a Gentle > Introduction to ssh > then they lose their value as man pages. No sir, the manual is incorrect. In fact, it is illogically presented. There is a difference between being concise, organized as a reference, and being incoherent. I only concentrated on file specification because it is so glaringly obvious. > > > I believe that this attitude makes Linux lose market > in favour of > > Windows servers. > > OpenSSH really doesn't relate to Linux market share.? > Natively OpenSSH > is part of OpenBSD which doesn't make use of Linux.? > GNU/Linux based > systems use OpenSSH from OpenBSD as a port.? (And we > are very > appreciative of it!)? Plus ssh runs on all kinds of > operating system > platforms including MS-Windows.? Someone trying to use > ssh on > MS-Windows could be just as frustrated and issue the same > statement > there too! Right, I did not know this, but still the manual is part of the OpenSSH project. And, by the way, Cygwin is more a virtual Unix on Windows, then Windows. > > > I still don't know if the encryption keys can be > regenerated, and I > > am not sure that every line sent from client to server > is > > authenticated, as it should. Also, I was surprised to > see that I can > > not limit the number of tries for passwords. That > config option is > > about logging of tries, not limiting them. > > When I think of encryption keys in conjuction with ssh > connections I > think of the session key used to encrypt the communication > between the > two hosts.? Yes, me too. Do the server ssh and client ssh software on one machine use the same key? This is handled automatically by > ssh.? You don't need to > manually re-key the connection.? However you may do so > with a newline > followed by "~R".? Terminal escape characters are > documented in the > ssh(1) manual where it says: > > ? ???~R? ? ? Request > rekeying of the connection (only useful for SSH protocol > ? ? ? ? ? > ???version 2 and if the peer supports it). > > The RekeyLimit is documented in the ssh_config(5) manual > and says: > > ? ???RekeyLimit > ? ? ? ? ? > ???Specifies the maximum amount of data that > may be transmitted > ? ? ? ? ? ???before > the session key is renegotiated.? The argument is the > num- > ? ? ? ? ? ???ber of > bytes, with an optional suffix of ?K?, ?M?, or > ?G? to > ? ? ? ? ? > ???indicate Kilobytes, Megabytes, or > Gigabytes, respectively.? The > ? ? ? ? ? > ???default is between ?1G? and ?4G?, > depending on the cipher.? This > ? ? ? ? ? ???option > applies to protocol version 2 only. So they are dynamically generated all the time. But /etc/ssh/ssh_host_[rd]sa_key /etc/ssh/ssh_host_[rd]sa_key.pub are rather constant, so you lost me here. > > But you are probably thinking about keys used for user > authentication. > You can change those keys too.? Of course if you do > then the previous > credentials are no longer valid and the new ones would need > to be > installed.? I do this every so often as a matter of > routine when I > move from one system to another during system upgrades. Not clear why. > > Or you may be talking about host keys used for host > identification. Probably these are in /etc/ssh/ssh_host_[rd]sa_key /etc/ssh/ssh_host_[rd]sa_key.pub. Please show me where are these keys explained in the manuals. There should be a list of used keys, like the list of used files. > Host keys can certainly be changed too but doing so will > appear to > users the same as if the host were being attacked with a > man in the > middle attack.? Therefore this type of change must be > communicated > such that the user can expect it and manually deal with the > change. > That would mean removing the old host key and verifying > the > fingerprint of the new host.? Fortunately changing > host keys isn't > often needed and so this isn't something routinely seen. > > Bob > Thank you for your answer. You certainly are more logical than the manuals. Please support my proposal to fully specify the location of files referred in the sshd manual. Doru From headset001 at yahoo.com Sun Apr 18 18:12:34 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Sun, 18 Apr 2010 01:12:34 -0700 (PDT) Subject: please decrypt your manuals In-Reply-To: Message-ID: <368137.82350.qm@web52304.mail.re2.yahoo.com> > In fact, there is no sutch terms as server/client machines. > Software > can be server (they have a "listen" system call), and > software could be > clients (they have a "connect" system call). The ssh manual says: "on the remote machine and contain a line con? taining the name of the client machine " By the way, the manual should use terms consistently, for example server for remote and client for client. Please. Doru From headset001 at yahoo.com Sun Apr 18 19:35:35 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Sun, 18 Apr 2010 02:35:35 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <153112.25339.qm@web52304.mail.re2.yahoo.com> > >> It's used by the client to maintain a list of > trusted hosts > >> keys. It's > >> like ~/.ssh/known_hosts, but set by the > administrator. > >>? ??? > > Where is this specified in the manual. I respect your > opinion, but this is not the subject of the post. The manual > does not fully specify the files it refers, this is the > subject of the post. > >??? > > "Host? keys? are stored? in > ~/.ssh/known_hosts in the user's home > directory.? Additionally, the file > /etc/ssh/ssh_known_hosts is > automatically checked for known hosts." Yes, but is it on the server or on the client? You may remember that the subject of this thread is the location of the /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts files referred under the SSH_KNOWN_HOSTS FILE FORMAT title in the sshd manual. I'm not sure that this location is specified in the sshd manual, directly or indirectly. > > Plus, are you sure that the server never uses > /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts, > according to sshd_config manual. If I guessed rightly, > because that manual also does not fully specify the files it > refers. > >??? > > That only applies to ssh v1 RhostsRSAAuthentication. You > shouldn't use > that (but it's a good point, anyway). You know this from the manuals? :-) > >> AFAIK the files are used only by the server. The > client > >> will receive > >> that public key from the handshake. You mean, client? Maybe the manual should say this. > >> You can regenerate them. Your users will get big > warnings > >> that someone > >> may be trying to pose as your machine, so I > recommend to > >> properly > >> publicise the change, or not to change them. > >>? ??? > > So the client uses another key for the encryption of > the messages it receives? > >??? > > They don't use the public key for message encryption. See > below. > > > > >> With ssh you open a secure tunnel between two > ends. > >> Anything passed > >> through it is secure. You authenticate that the > server is > >> not a deceiver > >> by checking that the provided key matches the one > you have > >> associated > >> with that host, which you would have supposedly > verified by > >> some > >> unspecified secure mean. > >>? ??? > > This procedure ensures that only the server can > decrypt messages from the client, but still the client can > receive messages from anybody in the middle and it can not > tell if they come from the server or from the > man-in-the-middle. So the server is not authenticated to the > client. It goes one way only, as you see, the server does > not supply any password or authentication key. I guess this > is less important, because the client only displays messages > from the server, it does not run commands from the server. > > I'm not the most qualified one to explain this but... here > I go. Anyone > is welcome to fix me should I say something wrong. > > - C connects to S > - They perform a Diffie-Hellman key exchange, and establish > a private > communication using a ephimeral key and a symmetrical > cipher. > > From this point on, they know they are talking to someone > other and the > connection cannot be read, or modified in any way. They may be talking with a man in the middle. > > - S signs a token with its private key, so that C can > verify that it is > really the server it wants to talk to. > Maybe the S's host key is used for authentication of S in front of C. Indeed (ssh man): /etc/ssh/ssh_host_key /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_rsa_key These three files contain the private parts of the host keys and are used for host-based authentication. So S is authenticated in front of C with a token, and this authentication is based on the human in front of C's console recognizing the hash (fingerprint) of the S's public host key. Thank you for your help. In case I got it right. Please support my proposal to have the ssh manuals fully specify the location of files they refer. From djm at mindrot.org Sun Apr 18 22:27:57 2010 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 Apr 2010 22:27:57 +1000 (EST) Subject: please decrypt your manuals In-Reply-To: <153112.25339.qm@web52304.mail.re2.yahoo.com> References: <153112.25339.qm@web52304.mail.re2.yahoo.com> Message-ID: > Please support my proposal to have the ssh manuals fully specify the > location of files they refer. You are welcome to submit a patch to our bug tracking system: https://bugzilla.mindrot.org/ Once you have come up with something concrete then we can discuss it. -d From keisial at gmail.com Mon Apr 19 07:00:18 2010 From: keisial at gmail.com (Keisial) Date: Sun, 18 Apr 2010 23:00:18 +0200 Subject: please decrypt your manuals In-Reply-To: <153112.25339.qm@web52304.mail.re2.yahoo.com> References: <153112.25339.qm@web52304.mail.re2.yahoo.com> Message-ID: <4BCB72E2.4020307@gmail.com> Doru Georgescu wrote: >>> Plus, are you sure that the server never uses >>> >> /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts, >> according to sshd_config manual. If I guessed rightly, >> because that manual also does not fully specify the files it >> refers. >> >>> >>> >> That only applies to ssh v1 RhostsRSAAuthentication. You >> shouldn't use >> that (but it's a good point, anyway). >> > You know this from the manuals? :-) > Yes. sshd_config(5) > IgnoreUserKnownHosts > Specifies whether sshd(8) should ignore the user's > ~/.ssh/known_hosts during RhostsRSAAuthentication or > HostbasedAuthentication. > The default is ``no''. > RhostsRSAAuthentication > Specifies whether rhosts or /etc/hosts.equiv > authentication together with successful RSA host authentication is > allowed. The > default is ``no''. This option applies to protocol > version 1 only. And seems I was wrong since I missed: > HostbasedAuthentication > Specifies whether rhosts or /etc/hosts.equiv > authentication together with successful public key client host > authentication is > allowed (host-based authentication). This option is > similar to RhostsRSAAuthentication and applies to protocol version > 2 only. > The default is ``no''. >>> This procedure ensures that only the server can >>> >> decrypt messages from the client, but still the client can >> receive messages from anybody in the middle and it can not >> tell if they come from the server or from the >> man-in-the-middle. So the server is not authenticated to the >> client. It goes one way only, as you see, the server does >> not supply any password or authentication key. I guess this >> is less important, because the client only displays messages >> from the server, it does not run commands from the server. >> >> I'm not the most qualified one to explain this but... here >> I go. Anyone >> is welcome to fix me should I say something wrong. >> >> - C connects to S >> - They perform a Diffie-Hellman key exchange, and establish >> a private >> communication using a ephimeral key and a symmetrical >> cipher. >> >> From this point on, they know they are talking to someone >> other and the >> connection cannot be read, or modified in any way. >> > They may be talking with a man in the middle. > Right. That's why I said "someone", not "the server". >> - S signs a token with its private key, so that C can >> verify that it is >> really the server it wants to talk to > Maybe the S's host key is used for authentication of S in front of C. > > Indeed (ssh man): > > /etc/ssh/ssh_host_key > /etc/ssh/ssh_host_dsa_key > /etc/ssh/ssh_host_rsa_key > These three files contain the private parts of the host keys and are used > for host-based authentication. > > So S is authenticated in front of C with a token, and this authentication is based on the human in front of C's console recognizing the hash (fingerprint) of the S's public host key. > Yes? The server says: I am server owning this private key Foo, and I prove it by signing this token. The human is used to confirm it is really the server. From misha680 at gmail.com Mon Apr 19 08:26:06 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Sun, 18 Apr 2010 17:26:06 -0500 Subject: OpenSSH with "resumable" functionality Message-ID: <4BCB86FE.3060207@gmail.com> Dear All: I was wondering if it might at all be possible to have the following functionality in OpenSSH: (i) upon "timeout" of connection (say 2-5 seconds) disconnect (ii) keep trying to reconnect (iii) upon reconnection, resume session exactly where started I realize GNU screen solves (iii), although I am interested in a slightly different purpose (nxssh vs openssh). However, I am confused as to (i). Any help much appreciated. Please reply-all Thank you Misha From dan at doxpara.com Mon Apr 19 09:37:49 2010 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 18 Apr 2010 19:37:49 -0400 Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCB86FE.3060207@gmail.com> References: <4BCB86FE.3060207@gmail.com> Message-ID: Misha-- You could wrap ssh in airhook, if this is being a problem. On Sun, Apr 18, 2010 at 6:26 PM, Misha Koshelev wrote: > Dear All: > > I was wondering if it might at all be possible to have the following > functionality in OpenSSH: > (i) upon "timeout" of connection (say 2-5 seconds) disconnect > (ii) keep trying to reconnect > (iii) upon reconnection, resume session exactly where started > > I realize GNU screen solves (iii), although I am interested in a slightly > different purpose (nxssh vs openssh). > > However, I am confused as to (i). > > Any help much appreciated. > > Please reply-all > > Thank you > Misha > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From misha680 at gmail.com Mon Apr 19 10:00:59 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Sun, 18 Apr 2010 19:00:59 -0500 Subject: OpenSSH with "resumable" functionality In-Reply-To: References: <4BCB86FE.3060207@gmail.com> Message-ID: <4BCB9D3B.1070605@gmail.com> Thank you. Looks to be defunct per http://airhook.ofb.net/ Dan Kaminsky wrote: > Misha-- > > You could wrap ssh in airhook, if this is being a problem. > > On Sun, Apr 18, 2010 at 6:26 PM, Misha Koshelev > wrote: > > Dear All: > > I was wondering if it might at all be possible to have the following > functionality in OpenSSH: > (i) upon "timeout" of connection (say 2-5 seconds) disconnect > (ii) keep trying to reconnect > (iii) upon reconnection, resume session exactly where started > > I realize GNU screen solves (iii), although I am interested in a > slightly different purpose (nxssh vs openssh). > > However, I am confused as to (i). > > Any help much appreciated. > > Please reply-all > > Thank you > Misha > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > From william at 25thandClement.com Mon Apr 19 10:46:04 2010 From: william at 25thandClement.com (William Ahern) Date: Sun, 18 Apr 2010 17:46:04 -0700 Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCB9D3B.1070605@gmail.com> References: <4BCB86FE.3060207@gmail.com> <4BCB9D3B.1070605@gmail.com> Message-ID: <20100419004604.GA29025@wilbur.25thandClement.com> On Sun, Apr 18, 2010 at 07:00:59PM -0500, Misha Koshelev wrote: > Thank you. Looks to be defunct per > http://airhook.ofb.net/ I used the library in a project a few years ago to create a multiplexed reverse RTSP proxy. You could stream your audio-video files from your home desktop, through any firewalls or NAT gateways, to generic cellphone handsets--i.e. no smart phone required, nor client application--using our servers as ingress/egress points. Everything worked flawlessly. The airhook protocol was far from ideal for this type application, but the code was well written and allowed me to move on with the gazillion other tasks that needed to be done, comfortable in the knowledge that I could return later to replace it if necessary, but no sooner. Not sure what the author meant by saying it was never implemented properly. I made a few optimizations, but not for correctness. The code is very clean and well designed. If the code has any failings, it's in copying data around too much. But it's not meant to--and because of the protocol never will--move data at gigabit rates. The author hasn't touched the code in years, but he never had to; it's entirely complete. I never made use of the command-line utility, however. It works, but it's meant as an example of API usage, so you can't really fault it. The library interface is well designed, but fairly low-level. To build anything sophisticated requires significant work, but that's no fault, either. From adrya1984 at gmail.com Mon Apr 19 16:03:05 2010 From: adrya1984 at gmail.com (Adriana Rodean) Date: Mon, 19 Apr 2010 09:03:05 +0300 Subject: SSH limits Message-ID: Hi, I have some questions about ssh server and Linux, hope someone can help me :) 1. Does Ssh server have a limit for the number of users that can connect ? 2. Does Ssh have restrictions about an username length? Or username format? We would like to use something like: foo_ ex: foo_ 5CEB80CF-150F-4ff0-8743-A6493FA200C1 3. Does Linux have a limit of user accounts? 4. Does Linux have restrictions about an username length? Or username format? We would like to use something like: foo_ ex: foo_ 5CEB80CF-150F-4ff0-8743-A6493FA200C1 Thank you, Adriana From headset001 at yahoo.com Mon Apr 19 17:06:33 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Mon, 19 Apr 2010 00:06:33 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <628476.50501.qm@web52308.mail.re2.yahoo.com> On Wed, Apr 07, 2010 at 09:24:57PM +0200, Peter Stuge wrote: > MITM is easy if the TCP session can be rerouted, but it's not > possible to perform undetected MITM attack without access to the > server host key. And if user authentication is done with public keys then a man in the middle attack isn't possible even if the attacker knows the private part of the host key. At least not unless the server or the client has been compromised in other ways, e.g. if it is using a broken random number generator. ---------------- If the attacker knows the server's private host key, and all public keys, then it could impersonate the server in front of the client. Why not? Doru From headset001 at yahoo.com Mon Apr 19 18:55:14 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Mon, 19 Apr 2010 01:55:14 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <814783.23384.qm@web52303.mail.re2.yahoo.com> Doru Georgescu wrote: > Yes, every file mentioned in the sshd manual should be fully > specified, that is, it should be always very clear if it lives > on the server or on the client. This must be clear enough indication that sshd is the server program. So anything you read in the sshd man page must be in the context of the server program. << This is logical enough, unfortunately the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual says that the public host key from /etc/ssh/ssh_host_key.pub (on the server, I guess) can be copied to /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts (on the client, I guess). Anyway, I don't believe that both files are supposed to be on the same machine, while both files are listed in the list of files. > Please show me clearly, step by step, how do you use the content of > the sshd manual to conclude that /etc/ssh/ssh_host_key.pub is on > the server. The man page sshd(8) documents the server part of OpenSSH. In the FILES section it is therefore clear that these files are relevant only for the server. Under FILES, there's this paragraph which I think is really clear: --8<-- ? ???/etc/ssh/ssh_host_key.pub ? ???/etc/ssh/ssh_host_dsa_key.pub ? ???/etc/ssh/ssh_host_rsa_key.pub ? ? ? ? ? ???These three files contain the public parts of the host keys. ? ? ? ? ? ???These files should be world-readable but writable only by root. ? ? ? ? ? ???Their contents should match the respective private parts.? These ? ? ? ? ? ???files are not really used for anything; they are provided for the ? ? ? ? ? ???convenience of the user so their contents can be copied to known ? ? ? ? ? ???hosts files.? These files are created using ssh-keygen(1). -->8-- So the file is a *host* key. Further, the instructions on permissions for these files is very strong indication that they are not intended for users to write. << This works for /etc/ssh/ssh_host_key.pub, which is listed in the sshd manual only, but not for /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, which are listed in both ssh and sshd manuals. How do you know that /etc/ssh/ssh_known_hosts mentioned in the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual is actually on the client, as I suspect. But you may answer that one does not expect to read about this server authentication procedure under the SSH_KNOWN_HOSTS FILE FORMAT title, anyway ... :-) In case this is a general authentication procedure, then still some files are on the authenticated machine and others on the authenticating machine. I hope that the English language survives this formulation. > but you can't assume that I know how did OpenSSH decide to protect > itself against man-in-the-middle attacks before I read the manual. Remember that there are two concepts in this discussion. First of all there's the SSH protocol, which is well documented in RFCs. Then there is OpenSSH, an implementation of the protocol. There are many security features already at the protocol level which make SSH an excellent choice for any secure communication. There are also some security features within OpenSSH that may or may not be unique, compared to other SSH implementations. It is still not completely clear to me which of the two entities you are talking about. As I already wrote, the SSH protocol uses message authentication for all communication. << I'm talking about the manuals only. While of course they deal with the OpenSSH implementation only, I believe that they should also contain some minimal information from RFC's, to provide a meaningful presentation. For example, the terminology could be well defined. That is, unique words for every basic concept, and some logical connections between basic concepts. A presentation of keys used, similar with the presentation of the files used, should not hurt anybody. << Anyway, let us just limit ourselves to the issue of the location of the /etc/ssh/ssh_host_key.pub (on the server, I guess) and /etc/ssh/ssh_known_hosts or ~/.ssh/known_hosts (on the client, I guess), which are mentioned in the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual. > Also, I'm a user who only wants to use keys instead of passwords > for authentication, for safety reasons, therefore I have no time to > read RFC, code etc. I'm not sure you stated this very clearly, which could certainly be reason for the kind of replies that you get. It's important to ask the right thing. It can be difficult to do so, there are great essays on the subject. Anyway, if your role is as a user then you shouldn't start with the sshd man page. Instead, start with the ssh man page. It explains what files OpenSSH uses for public key authentication: --8<-- ? ???~/.ssh/authorized_keys ? ? ? ? ? ???Lists the public keys (RSA/DSA) that can be used for logging in ? ? ? ? ? ???as this user.? The format of this file is described in the ? ? ? ? ? ???sshd(8) manual page.? This file is not highly sensitive, but the ? ? ? ? ? ???recommended permissions are read/write for the user, and not ? ? ? ? ? ???accessible by others. .. ? ???~/.ssh/identity ? ???~/.ssh/id_dsa ? ???~/.ssh/id_rsa ? ? ? ? ? ???Contains the private key for authentication.? These files contain ? ? ? ? ? ???sensitive data and should be readable by the user but not acces? ? ? ? ? ? ???sible by others (read/write/execute).? ssh will simply ignore a ? ? ? ? ? ???private key file if it is accessible by others.? It is possible ? ? ? ? ? ???to specify a passphrase when generating the key which will be ? ? ? ? ? ???used to encrypt the sensitive part of this file using 3DES. ? ???~/.ssh/identity.pub ? ???~/.ssh/id_dsa.pub ? ???~/.ssh/id_rsa.pub ? ? ? ? ? ???Contains the public key for authentication.? These files are not ? ? ? ? ? ???sensitive and can (but need not) be readable by anyone. -->8-- Now you know that you need to create an authorized_keys file. In fact, the first paragraph, on authorized_keys, should maybe not be in here at all since only the server looks at that file - but at least it has the reference to the sshd man page so that people can go there to get all the details on the file. << Excepting where it lives. And the first hint, that /etc/ssh/ssh_host_key.pub is on the server, is no longer acceptable. The list of files in a manual lists files mentioned in the manual, not the files directly used by the manual's software. In the sshd man page it says that you should copy your public key and into authorized_keys, and edit it to suit. Editing it is actually optional. > find out on what machine is /etc/ssh/ssh_host_key.pub > mentioned in the SSH_KNOWN_HOSTS FILE FORMAT paragraph of the sshd > manual. If nothing else is mentioned, you must assume that this file belongs to the server, since it's described in the sshd manual page. If this kind of logic does not come very naturally to you then there isn't much we can do to help. :\ << You can help a lot by supporting my proposition to specify the location of files referred in the manuals. > > Are you sure that those RFC's explain whether > > /etc/ssh/ssh_known_hosts is used by the client or by the > > server? Not at all. This suggests that you are (again?) confusing the protocol SSH with the implementation OpenSSH. The documentation relating to these two things will not neccessarily overlap very much, if at all. It's better for each entity to document it's own scope accurately, than for everyone to try to document everything. << Maybe the manuals are supposed, for every basic concept they use, to either explain it a little bit, or refer to some RFC section. I support the first solution, because a few words can save a lot of effort. > > I didn't find this name in those RFC's, but maybe I can deduce > > somehow what ssh_known_hosts is doing if I read them. You need to first read the OpenSSH manual page for ssh and then sshd to learn what /etc/ssh/ssh_known_hosts is used for. << I know what it does, I don't know what file the SSH_KNOWN_HOSTS FILE FORMAT of the sshd manual is referring to, the one on the server or the one on the client. > The manual does not fully specify the files it refers, Did you read all of the manual? It's really good to do so, but you should find a better time than 3am, if you are usually tired by then. << Well, if you failed to show me where does /etc/ssh/ssh_known_hosts live, I won't rely too much on the manual. > Plus, are you sure that the server never uses > /etc/ssh/ssh_known_hosts? It uses ~/.ssh/known_hosts, according to > sshd_config manual. If I guessed rightly, because that manual also > does not fully specify the files it refers. Are you looking at the IgnoreUserKnownHosts directive? That also explains circumstances when the file is used, giving you further things to look up, and learn about. > So the client uses another key for the encryption of the messages > it receives? As I wrote there are many keys involved in the SSH protocol. Now you are discussing something completely unrelated to OpenSSH and manuals in OpenSSH. I don't think it's too off-topic for the list, but please remember to keep the distinction between the protocol and the implementation. Really, to get the details of the SSH protocol, you should look at the RFCs. They are not too dense, and should be digestable in a day or two if you want to read them from start to end. << Bad manual. It should say that it does not make any sense before you read RFC's. It should make sense even if one does not read RFC's. It should define some basic terms and explain some simple procedures, like using /etc/ssh/ssh_known_hosts to perform authentication. > This procedure ensures that only the server can decrypt messages > from the client, but still the client can receive messages from > anybody in the middle and it can not tell if they come from the > server or from the man-in-the-middle. So the server is not > authenticated to the client. It goes one way only, as you see, the > server does not supply any password or authentication key. I guess > this is less important, because the client only displays messages > from the server, it does not run commands from the server. This assumption is incorrect. Look at the protocol RFCs to learn all about how SSH client and server authenticate each other. In short, the client verifies the host key. Once the host key is considered to be approved (by the user in case of OpenSSH) the client will then continue to try to authenticate the user to the server. Once authentication is complete, the message authentication protects against any MITM attack. << Thank you for this. The client verifies the public host key of the server. This sentence would look great in the manual. MITM is easy if the TCP session can be rerouted, but it's not possible to perform undetected MITM attack without access to the server host key. << that is the server's private host key, found in /etc/ssh/ssh_host_key and the other two similar files. > The client is authenticated to the server, No. The user authenticates to a server. The client is never authenticated. << Right, the client user, not the client machine authenticates to the server. This sentence would also make the manual too clear. Really, look at RFC 4251 and 4252. You may not even need to go into the details of 4252 to answer your questions. //Peter If you can't show me step by step reasoning, inside the sshd manual, or at least inside all the ssh manuals (which would be a treat), to prove that the /etc/ssh/ssh_known_hosts, the /.ssh/known_hosts and the /etc/ssh/ssh_host_key.pub files referred under the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual, are fully specified and you still claim that the manual is correct, then the problem we face is no longer technical but social or psychological, and I decline my competence, while I maintain my curiosity: Why would you do that? Doru From headset001 at yahoo.com Mon Apr 19 19:13:32 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Mon, 19 Apr 2010 02:13:32 -0700 (PDT) Subject: please decrypt your manuals In-Reply-To: <4BCB72E2.4020307@gmail.com> Message-ID: <513864.87826.qm@web52307.mail.re2.yahoo.com> --- On Sun, 4/18/10, Keisial wrote: > From: Keisial > Subject: Re: please decrypt your manuals > To: "Doru Georgescu" , openssh-unix-dev at mindrot.org > Date: Sunday, April 18, 2010, 5:00 PM > Doru Georgescu wrote: > >>> Plus, are you sure that the server never uses > >>>? ? ??? > >> /etc/ssh/ssh_known_hosts? It uses > ~/.ssh/known_hosts, > >> according to sshd_config manual. If I guessed > rightly, > >> because that manual also does not fully specify > the files it > >> refers. > >>? ??? > >>>? ? > >>>? ? ??? > >> That only applies to ssh v1 > RhostsRSAAuthentication. You > >> shouldn't use > >> that (but it's a good point, anyway). > >>? ??? > > You know this from the manuals? :-) > >??? > > Yes. sshd_config(5) > > IgnoreUserKnownHosts > >? ? ? ? ? ? > ???Specifies? whether? sshd(8) > should ignore the user's > > ~/.ssh/known_hosts during RhostsRSAAuthentication or > > HostbasedAuthentication. > >? ? ? ? ? ? > ???The default is ``no''. > > >? ???RhostsRSAAuthentication > >? ? ? ? ? ? > ???Specifies whether rhosts or > /etc/hosts.equiv > > authentication together with successful RSA? > host? authentication? is > > allowed.???The > >? ? ? ? ? ? > ???default is ``no''.? This option > applies to protocol > > version 1 only. I said that I am not sure about /etc/ssh/ssh_known_hosts. The sshd_config manual does mention ~/.ssh/known_hosts, as I said. > > > And seems I was wrong since I missed: > > HostbasedAuthentication > >? ? ? ? ? ? > ???Specifies? whether? rhosts? > or? /etc/hosts.equiv > > authentication together with successful public key > client host > > authentication is > >? ? ? ? ? ? > ???allowed (host-based authentication).? > This option is > > similar to RhostsRSAAuthentication and applies to > protocol? version > > 2? only. > >? ? ? ? ? ? > ???The default is ``no''. > > > ? ??? > > >>> This procedure ensures that only the server > can > >>>? ? ??? > >> decrypt messages from the client, but still the > client can > >> receive messages from anybody in the middle and it > can not > >> tell if they come from the server or from the > >> man-in-the-middle. So the server is not > authenticated to the > >> client. It goes one way only, as you see, the > server does > >> not supply any password or authentication key. I > guess this > >> is less important, because the client only > displays messages > >> from the server, it does not run commands from the > server. > >> > >> I'm not the most qualified one to explain this > but... here > >> I go. Anyone > >> is welcome to fix me should I say something > wrong. > >> > >> - C connects to S > >> - They perform a Diffie-Hellman key exchange, and > establish > >> a private > >> communication using a ephimeral key and a > symmetrical > >> cipher. > >> > >> From this point on, they know they are talking to > someone > >> other and the > >> connection cannot be read, or modified in any > way. > >>? ??? > > They may be talking with a man in the middle. > >??? > > Right. That's why I said "someone", not "the server". > > > >> - S signs a token with its private key, so that C > can > >> verify that it is > >> really the server it wants to talk to > > Maybe the S's host key is used for authentication of S > in front of C. > > > > Indeed (ssh man): > > > >? ? ? /etc/ssh/ssh_host_key > >? ? ? /etc/ssh/ssh_host_dsa_key > >? ? ? /etc/ssh/ssh_host_rsa_key > >? ? ? ? ? ? ? These > three files contain the private parts of the host keys and > are used > >? ? ? ? ? ? ? for > host-based authentication. > > > > So S is authenticated in front of C with a token, and > this authentication is based on the human in front of C's > console recognizing the hash (fingerprint) of the S's public > host key. > >??? > > Yes? > The server says: I am server owning this private key Foo, > and I prove it > by signing this token. The human is used to confirm it is > really the server. > I suppose that the server encrypts the token using his private host key, and sends this message to the client, who unencrypts it using the server's public host key and recognizes the token. All is very fine, but on what side are you? Do you claim that the ssh manuals fully specify the /etc/ssh/ssh_host_key.pub, the /etc/ssh/ssh_known_hosts and the ~/.ssh/known_hosts files mentioned in the SSH_KNOWN_HOSTS FILE FORMAT section of the sshd manual, or not? By full specification I mean: do they say where do those files reside, on the server, or on the client, on the authorized machine, or on the authorizing machine? Well? Doru From headset001 at yahoo.com Mon Apr 19 19:29:59 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Mon, 19 Apr 2010 02:29:59 -0700 (PDT) Subject: please decrypt your manuals In-Reply-To: Message-ID: <285154.95436.qm@web52302.mail.re2.yahoo.com> --- On Sun, 4/18/10, Damien Miller wrote: > From: Damien Miller > Subject: Re: please decrypt your manuals > To: "Doru Georgescu" > Cc: "Keisial" , "OpenSSH" > Date: Sunday, April 18, 2010, 8:27 AM > > Please support my proposal to > have the ssh manuals fully specify the > > location of files they refer. > > You are welcome to submit a patch to our bug tracking > system: > https://bugzilla.mindrot.org/ > > Once you have come up with something concrete then we can > discuss it. > > -d > I propose to add to every file mentioned in the ssh manuals the specification of whether it lives on the server machine or on the client machine, or whether it is used by the server software or by the client software, as it is the case. If all files in a manual are on one machine, this can be said in one place in that manual. If most files in a manual are on one machine, this can be again said in one place, and only those files residing on the other machine should be specified individually. If one file is used by both the server and the client, than this should be mentioned in the file explanation in the list of files, in all manuals where that respective file appears in the list of files, to avoid confusion. Also to avoid confusion, a few words explaining how do the client and the server use that specific file, should be added. I can submit a patch only with the cooperation and support of the people on this list. Doru From chris at qwirx.com Mon Apr 19 17:35:33 2010 From: chris at qwirx.com (Chris Wilson) Date: Mon, 19 Apr 2010 09:35:33 +0200 (CEST) Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCB86FE.3060207@gmail.com> References: <4BCB86FE.3060207@gmail.com> Message-ID: Hi Misha, On Sun, 18 Apr 2010, Misha Koshelev wrote: > I was wondering if it might at all be possible to have the following functionality in OpenSSH: > (i) upon "timeout" of connection (say 2-5 seconds) disconnect > (ii) keep trying to reconnect > (iii) upon reconnection, resume session exactly where started [...] > However, I am confused as to (i). It might reduce the confusion (yours and ours) if you defined exactly what you mean by "timeout"? If you mean "packet sent with no response from the remote side", you can do that (or something similar) with the TCPKeepAlive or ServerAliveInterval options to the client. You can do (ii) by wrapping the ssh command in a shell loop: while ! ssh user at host -o 'ServerAliveInterval 5' screen -d -RR; do true; done Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From markus.r.friedl at arcor.de Mon Apr 19 21:08:36 2010 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Mon, 19 Apr 2010 13:08:36 +0200 Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCB86FE.3060207@gmail.com> References: <4BCB86FE.3060207@gmail.com> Message-ID: <20100419110836.GA29169@folly> On Sun, Apr 18, 2010 at 05:26:06PM -0500, Misha Koshelev wrote: > I was wondering if it might at all be possible to have the following functionality in OpenSSH: > (i) upon "timeout" of connection (say 2-5 seconds) disconnect > (ii) keep trying to reconnect > (iii) upon reconnection, resume session exactly where started this is a work-in-progress, some parts are already commited to the released versions. other parts need to be reviewed. Andreas can provide details, I think -- and yes, I should look into reviewing the remaining patches....... -m From chris at qwirx.com Mon Apr 19 22:30:23 2010 From: chris at qwirx.com (Chris Wilson) Date: Mon, 19 Apr 2010 14:30:23 +0200 (CEST) Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCC4A9D.1020900@gmail.com> References: <4BCB86FE.3060207@gmail.com> <4BCC4A9D.1020900@gmail.com> Message-ID: Hi Misha, On Mon, 19 Apr 2010, Misha Koshelev wrote: > Chris Wilson wrote: >> On Sun, 18 Apr 2010, Misha Koshelev wrote: >> >>> I was wondering if it might at all be possible to have the following >>> functionality in OpenSSH: >>> (i) upon "timeout" of connection (say 2-5 seconds) disconnect >>> (ii) keep trying to reconnect >>> (iii) upon reconnection, resume session exactly where started >> [...] >>> However, I am confused as to (i). >> >> You can do (ii) by wrapping the ssh command in a shell loop: >> >> while ! ssh user at host -o 'ServerAliveInterval 5' screen -d -RR; >> do true; done > > Not sure this will work with my intended application (NoMachine NX). > Will have to think about it... You need to stop the NX server, clients and intermediate TCP connections from dying. If you have such an unreliable network, NX may not be the best choice. VNC allows you to keep the server running even with no clients connected, and clients can connect and resume sessions at any time. It's therefore a much better choice over highly unreliable networks in my view. If you must use NX, I'd suggest running it over a VPN (perhaps over SSH) so that clients are not killed when the session goes down. However they will suffer packet loss and need time to recover from it, and they will probably eventually time out anyway if the network goes down for long. > Also right now get.. > > Must be connected to a terminal. > > Any ideas? Sorry, I don't have any idea what that means. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From misha680 at gmail.com Mon Apr 19 22:20:45 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Mon, 19 Apr 2010 07:20:45 -0500 Subject: OpenSSH with "resumable" functionality In-Reply-To: References: <4BCB86FE.3060207@gmail.com> Message-ID: <4BCC4A9D.1020900@gmail.com> Chris Wilson wrote: > Hi Misha, > > On Sun, 18 Apr 2010, Misha Koshelev wrote: > >> I was wondering if it might at all be possible to have the following >> functionality in OpenSSH: >> (i) upon "timeout" of connection (say 2-5 seconds) disconnect >> (ii) keep trying to reconnect >> (iii) upon reconnection, resume session exactly where started > [...] >> However, I am confused as to (i). > > It might reduce the confusion (yours and ours) if you defined exactly > what you mean by "timeout"? > > If you mean "packet sent with no response from the remote side", you can > do that (or something similar) with the TCPKeepAlive or > ServerAliveInterval options to the client. > > You can do (ii) by wrapping the ssh command in a shell loop: > > while ! ssh user at host -o 'ServerAliveInterval 5' screen -d -RR; > do true; done > > Cheers, Chris. Thank you. Not sure this will work with my intended application (NoMachine NX). Will have to think about it... Also right now get.. Must be connected to a terminal. Any ideas? Thank you! Misha From keisial at gmail.com Tue Apr 20 00:09:10 2010 From: keisial at gmail.com (Keisial) Date: Mon, 19 Apr 2010 16:09:10 +0200 Subject: SSH limits In-Reply-To: References: Message-ID: <4BCC6406.1000403@gmail.com> Adriana Rodean wrote: > Hi, > > > I have some questions about ssh server and Linux, hope someone can help me :) > > 1. Does Ssh server have a limit for the number of users that can connect ? > You may have issues with MaxStartups if all those users try to connect at once. Otherwise, it should work. > 2. Does Ssh have restrictions about an username length? Or > username format? We would like to use something like: foo_ > > ex: foo_ 5CEB80CF-150F-4ff0-8743-A6493FA200C1 > OpenSSH accepts them without problems. > 3. Does Linux have a limit of user accounts? > On modern linux uid_t uses 4 bytes so you could have up to** 2^32 ****(about 4.300 thousand) ****accounts. **But to be efficient with thousands of accounts you should store the user database into a database instead of libnss_files. See nsswitch.conf(5) > 4. Does Linux have restrictions about an username length? Or > username format? We would like to use something like: foo_ > > ex: foo_ 5CEB80CF-150F-4ff0-8743-A6493FA200C1 > That seems to work. You may prefer to use foo_5ceb80cf-150f-4ff0-8743-a6493fa200c1 since unix names are usually lowercase and a few apps may not like uppercase letters. useradd(8) only accepts usernames up to 32 characters long, so you should create an alternative app to add them. From misha680 at gmail.com Tue Apr 20 01:07:17 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Mon, 19 Apr 2010 10:07:17 -0500 Subject: OpenSSH with "resumable" functionality In-Reply-To: References: <4BCB86FE.3060207@gmail.com> <4BCC4A9D.1020900@gmail.com> Message-ID: <4BCC71A5.6030605@gmail.com> Thank you so much for your thoughts and suggestions. Misha Chris Wilson wrote: > Hi Misha, > > On Mon, 19 Apr 2010, Misha Koshelev wrote: >> Chris Wilson wrote: >>> On Sun, 18 Apr 2010, Misha Koshelev wrote: >>> >>>> I was wondering if it might at all be possible to have the following >>>> functionality in OpenSSH: >>>> (i) upon "timeout" of connection (say 2-5 seconds) disconnect >>>> (ii) keep trying to reconnect >>>> (iii) upon reconnection, resume session exactly where started >>> [...] >>>> However, I am confused as to (i). >>> >>> You can do (ii) by wrapping the ssh command in a shell loop: >>> >>> while ! ssh user at host -o 'ServerAliveInterval 5' screen -d -RR; >>> do true; done >> >> Not sure this will work with my intended application (NoMachine NX). >> Will have to think about it... > > You need to stop the NX server, clients and intermediate TCP connections > from dying. > > If you have such an unreliable network, NX may not be the best choice. > VNC allows you to keep the server running even with no clients > connected, and clients can connect and resume sessions at any time. It's > therefore a much better choice over highly unreliable networks in my view. > > If you must use NX, I'd suggest running it over a VPN (perhaps over SSH) > so that clients are not killed when the session goes down. However they > will suffer packet loss and need time to recover from it, and they will > probably eventually time out anyway if the network goes down for long. > >> Also right now get.. >> >> Must be connected to a terminal. >> >> Any ideas? > > Sorry, I don't have any idea what that means. > > Cheers, Chris. From dkg at fifthhorseman.net Tue Apr 20 01:18:08 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Apr 2010 11:18:08 -0400 Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCC4A9D.1020900@gmail.com> References: <4BCB86FE.3060207@gmail.com> <4BCC4A9D.1020900@gmail.com> Message-ID: <4BCC7430.7010402@fifthhorseman.net> On 04/19/2010 08:20 AM, Misha Koshelev wrote: > Chris Wilson wrote: >> while ! ssh user at host -o 'ServerAliveInterval 5' screen -d -RR; >> do true; done > > Also right now get.. > > Must be connected to a terminal. This is probably because screen must be run while connected to a tty (or pseudo-tty) on the host machine, and if you supply a command argument to ssh, it will not ask sshd to allocate a tty by default. You can use the -t flag to override this behavior. This would make the command: while ! ssh -t user at host -o 'ServerAliveInterval 5' screen -d -RR; do true; done Hope this helps, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From imorgan at nas.nasa.gov Tue Apr 20 04:13:11 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 19 Apr 2010 11:13:11 -0700 Subject: revised cert format and deprecation schedule In-Reply-To: References: Message-ID: <20100419181311.GJ1314@linux55.nas.nasa.gov> On Fri, Apr 16, 2010 at 01:29:06 -0500, Damien Miller wrote: > There are basically three goals: > > 1) Develop OpenSSH certificates until they solve enough of the use-cases > to be a compelling substitute for X.509 certs for a substantial > number of users. This may require occasional backwards-incompatible > changes. > > 2) Don't burn our early adopters by breaking their working > configurations without ample warning. > > 3) Avoid having to be stuck with maintaining backwards compatibility > code in perpetuity. This is for both workload and security reasons; > more twisty compat code == more bugs. > > So my working, self-imposed policy is to retain backwards compatibility > support for at least 13 months after the release that includes an > incompatible change. This duration is intended to let users sign certs > of one year duration and know that an OpenSSH release won't break them > in their life time. A corollary of this is that you shouldn't sign certs > that have an expiry date more than one year in the future if you want to > be able to upgrade to the latest version at will. > > As an example, our next release will include the above incompatible > change and will likely be made some time around July. Following this > plan, I'll remove support for the v00 certificate format in the next > release after August 2011. > > Hopefully this provides enough clarity for people to start using this > certificate support with some confidence that we won't break it at > random. > > Naturally this policy is open for discussion, but I'd prefer that the > discussion happen *now* rather than when we are preparing for the > release in late 2011. So have at it :) > > -d > Hi Damien, For now this seems like a reasonable policy, particularly as the certificate support has only been recently been introduced. However, I'm a little concerned as to what will happen when OS vendors start to adopt versions of OpenSSH with this support. For example, one vendor might ship an OS with 5.5p1 while another vendor might ship 5.9p1. These two versions would presumably have mutually incompatible certificate support. It's conceivable that in a heterogeneous environment there may be several versions of OpenSSH in use and the version supplied by vendor X may ben incompatible (with regards to the certificate support) with the version supplied by vendor Y. The desire to remove support for obsolete formats is understandable and laudable, but I suspect that at some point you may need to extend the timeframe from 13 months to something more on the order of two or three years. Hopefully there won't be a need for frequent revisions to the format, so this may be a moot point. In any case, I imagine you've already considered this. Regards -- Iain Morgan From Susan.Diller at PAETEC.com Tue Apr 20 04:18:24 2010 From: Susan.Diller at PAETEC.com (Diller, Susan (Sue)) Date: Mon, 19 Apr 2010 14:18:24 -0400 Subject: logging details In-Reply-To: References: Message-ID: Shouldn't the subsystem be set to internel-sftp? Or, can the Subsystem and ForceCommand options be different? -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, April 16, 2010 5:46 PM To: Diller, Susan (Sue) Cc: openssh-unix-dev at mindrot.org Subject: Re: logging details On Fri, 16 Apr 2010, Diller, Susan (Sue) wrote: > Are there plans to expand the logging capabilities in OpenSSH, so that > the details of what files were moved using sftp is included? If not, > does anyone know of a good way to capture this information? sftp-server has supported this for a while. Try specifying: Subsystem sftp /usr/libexec/sftp-server -l VERBOSE in sshd_config (you might need a different path to sftp-server). -d From dkg at fifthhorseman.net Tue Apr 20 04:48:00 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 19 Apr 2010 14:48:00 -0400 Subject: choice of fingerprint display upon new host access Message-ID: <4BCCA560.5020803@fifthhorseman.net> When a user encounters a new ssh host, the VisualHostKey option makes ssh display the visual fingerprint of the host's key. ssh-keygen also supports BubbleBabble fingerprinting, but i don't see a way to indicate that ssh should display the bubblebabble fingerprint upon encountering a new host key. It seems like it would be nice to make OpenSSH configurable about its choice of fingerprinting scheme without adding a new option for every possible flavor of fingerprinting. In particular, i'm not proposing that we include a BubbleBabbleHostKey option to ssh_config. What do people think of the following approach for ssh_config: HostKeyFingerprint is an option which takes a comma-separated set of fingerprint styles to display to the user upon seeing a new host key. Supported options are: "hex", "bubblebabble", "visual" The default is: hex For backward compatibility, -oVisualHostKey=yes implicitly adds "visual" to this set if it is not already present. If people think this is a good idea, i'll open a bugzilla ticket about it. I'm also interested to hear if people have any objections to the idea. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From misha680 at gmail.com Tue Apr 20 05:23:06 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Mon, 19 Apr 2010 14:23:06 -0500 Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCC7430.7010402@fifthhorseman.net> References: <4BCB86FE.3060207@gmail.com> <4BCC4A9D.1020900@gmail.com> <4BCC7430.7010402@fifthhorseman.net> Message-ID: <4BCCAD9A.9030701@gmail.com> Daniel Kahn Gillmor wrote: > On 04/19/2010 08:20 AM, Misha Koshelev wrote: >> Chris Wilson wrote: >>> while ! ssh user at host -o 'ServerAliveInterval 5' screen -d -RR; >>> do true; done >> Also right now get.. >> >> Must be connected to a terminal. > > This is probably because screen must be run while connected to a tty (or > pseudo-tty) on the host machine, and if you supply a command argument to > ssh, it will not ask sshd to allocate a tty by default. You can use the > -t flag to override this behavior. > > This would make the command: > > while ! ssh -t user at host -o 'ServerAliveInterval 5' screen -d -RR; > do true; done > > Hope this helps, > > --dkg > Thank you. I have made a very simple prototype: misha at misha-d630:~$ more /usr/NX/bin/nxssh #!/bin/bash /usr/NX/bin/mxssh misha-i1525 -tt -o "ServerAliveInterval 5" "screen -d -RR -s /home/misha/bin/nxlogin" misha at misha-d630:~$ more /home/misha/bin/nxlogin #!/bin/bash ssh -i /usr/NX/share/keys/server.id_dsa.key -t nx at localhost misha at misha-d630:~$ This seems to _almost_ work, except screen garbles some characters. I think I might try my hand at making a very very simple screen-like utility with less functionality (one shot), unless something like this is available already? i.e. a program that: i) if no session, makes new "detachable" session that runs some command - no control chars, nothing ii) if a session exists, reattaches Any clues? Thank you Misha From andreas at zzlevo.net Tue Apr 20 05:23:43 2010 From: andreas at zzlevo.net (Andreas Gunnarsson) Date: Mon, 19 Apr 2010 21:23:43 +0200 Subject: OpenSSH with "resumable" functionality In-Reply-To: <20100419110836.GA29169@folly> References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly> Message-ID: <20100419192343.GA26131@zzlevo.net> > On Sun, Apr 18, 2010 at 05:26:06PM -0500, Misha Koshelev wrote: > > I was wondering if it might at all be possible to have the following functionality in OpenSSH: > > (i) upon "timeout" of connection (say 2-5 seconds) disconnect > > (ii) keep trying to reconnect > > (iii) upon reconnection, resume session exactly where started On Mon, Apr 19, 2010 at 01:08:36PM +0200, Markus Friedl wrote: > this is a work-in-progress, some parts are already commited to > the released versions. other parts need to be reviewed. > > Andreas can provide details, I think -- and yes, I should > look into reviewing the remaining patches....... I've made the patch available here: http://www.zzlevo.net/ssh-roaming.diff This is a diff against OpenBSD-current which adds "roaming" to allow an ssh session to be suspended (i.e. terminate the TCP session) and then resumed over a new TCP session. The client may resume from the same or a new IP address. A solution which just sets up a new ssh session would tear down open port forwarded TCP sessions. This patch keeps the client and server processes running, and applications that use port forwards will not notice that the ssh session has been suspended and resumed. The session is not resumed automatically (the user has to press return) but that could be a possible enhancement once this is committed. The patch is based on code written by Martin Forss?n and donated by my previous employer, AppGate. I haven't made a version for portable OpenSSH but anyone who wants to will probably be able to do that with minimal effort. As Markus said, this hasn't been fully audited yet. It does touch the preauth and privsep parts of the code so use on your own risk. :) Andreas From jbasney at ncsa.uiuc.edu Tue Apr 20 05:46:20 2010 From: jbasney at ncsa.uiuc.edu (Jim Basney) Date: Mon, 19 Apr 2010 14:46:20 -0500 Subject: daemon() before bind() Message-ID: <4BCCB30C.7000800@ncsa.uiuc.edu> Hello OpenSSH developers, I hope you won't mind confirming something for me. Recently an OpenSSH user objected to me about the sshd exiting with status 0 when the bind to port 22 fails ("Address already in use"), because it makes it not obvious to the init script that something went wrong in sshd startup. As I understand it, this behavior is due to the sshd calling daemon() before socket() and bind(), thereby returning control to the parent process before seeing if the bind succeeds or fails. Furthermore, the sshd makes the calls in this order because daemon() will close the first three file descriptors, and we don't want the socket() file descriptor to be closed by the daemon() call in case the file descriptor happens to be one of the first three. Would you consider a patch that moved the daemon() call after the socket() and bind() calls? Clearly the patch would need to be careful about the first three file descriptors, possibly using dup() to move open file descriptors to higher values before the daemon() call. The benefit being that more startup errors would return non-zero exit statuses, with the drawback of adding complexity to the sshd startup code. I'm guessing such a patch would not be accepted, but I wanted to ask to be sure. In any case, thanks for all your work on OpenSSH. -Jim From andreas at zzlevo.net Tue Apr 20 05:59:24 2010 From: andreas at zzlevo.net (Andreas Gunnarsson) Date: Mon, 19 Apr 2010 21:59:24 +0200 Subject: please decrypt your manuals In-Reply-To: <628476.50501.qm@web52308.mail.re2.yahoo.com> References: <628476.50501.qm@web52308.mail.re2.yahoo.com> Message-ID: <20100419195924.GC26131@zzlevo.net> > And if user authentication is done with public keys then a man in the > middle attack isn't possible even if the attacker knows the private > part of the host key.[...] On Mon, Apr 19, 2010 at 12:06:33AM -0700, Doru Georgescu wrote: > If the attacker knows the server's private host key, and all public > keys, then it could impersonate the server in front of the client. Why > not? It can impersonate the server, but not perform a man in the middle attack. Simplified, it's because it can't forge the Diffie-Hellman exchange which affects the session ID which is signed by the user's key. See the RFCs (4252 and 4253 I think) for a detailed explanation how it works. Of course, this is probably mostly of interest in theory since a compromised private server key may be an indication that the entire server is compromised. Andreas From hans at atbas.org Tue Apr 20 06:31:01 2010 From: hans at atbas.org (Hans Harder) Date: Mon, 19 Apr 2010 22:31:01 +0200 Subject: no logging in auth.log when using wrong ssh keys Message-ID: I have in the sshd_config the following to disable password authentication Match Group dummies PasswordAuthentication no KbdInteractive no Normally I use denyhosts to detect incorrect logins, but it seems that failed sshkey logins are not logged in auth.log And I really like to have them in order to detect them and use the denyhosts script. Looked in the last nightly builds, but it seems that only method ' password' is being logged. So I added one line, so that also failed publickey logins are being logged in auth.log hans at Draakje:~/src/openssh$ diff -u auth.c auth_new.c --- auth.c 2010-03-07 01:57:00.000000000 +0100 +++ auth_new.c 2010-04-19 19:58:21.564550068 +0200 @@ -263,6 +263,7 @@ if (authenticated == 1 || !authctxt->valid || authctxt->failures >= options.max_authtries / 2 || + strcmp(method, "publickey") == 0 || strcmp(method, "password") == 0) authlog = logit; Perhaps there is a better way to log the failed sshkey logins, but I couldn't find it (my lack of knowledge probably). So any comments are welcome.... Hans -------- ech`echo xiun|tr nu oc|sed'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol. From djm at mindrot.org Tue Apr 20 07:41:17 2010 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Apr 2010 07:41:17 +1000 (EST) Subject: logging details In-Reply-To: References: Message-ID: You can pass commandline arguments to internal-sftp and via ForceCommand too. -d On Mon, 19 Apr 2010, Diller, Susan (Sue) wrote: > > Shouldn't the subsystem be set to internel-sftp? Or, can the Subsystem and ForceCommand options be different? > > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Friday, April 16, 2010 5:46 PM > To: Diller, Susan (Sue) > Cc: openssh-unix-dev at mindrot.org > Subject: Re: logging details > > On Fri, 16 Apr 2010, Diller, Susan (Sue) wrote: > > > Are there plans to expand the logging capabilities in OpenSSH, so that > > the details of what files were moved using sftp is included? If not, > > does anyone know of a good way to capture this information? > > sftp-server has supported this for a while. Try specifying: > > Subsystem sftp /usr/libexec/sftp-server -l VERBOSE > > in sshd_config (you might need a different path to sftp-server). > > -d > From djm at mindrot.org Tue Apr 20 07:45:57 2010 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Apr 2010 07:45:57 +1000 (EST) Subject: choice of fingerprint display upon new host access In-Reply-To: <4BCCA560.5020803@fifthhorseman.net> References: <4BCCA560.5020803@fifthhorseman.net> Message-ID: On Mon, 19 Apr 2010, Daniel Kahn Gillmor wrote: > When a user encounters a new ssh host, the VisualHostKey option makes > ssh display the visual fingerprint of the host's key. > > ssh-keygen also supports BubbleBabble fingerprinting, but i don't see a > way to indicate that ssh should display the bubblebabble fingerprint > upon encountering a new host key. > > It seems like it would be nice to make OpenSSH configurable about its > choice of fingerprinting scheme without adding a new option for every > possible flavor of fingerprinting. In particular, i'm not proposing > that we include a BubbleBabbleHostKey option to ssh_config. > > What do people think of the following approach for ssh_config: > > HostKeyFingerprint is an option which takes a comma-separated set of > fingerprint styles to display to the user upon seeing a new host key. > Supported options are: "hex", "bubblebabble", "visual" > > The default is: hex > > For backward compatibility, -oVisualHostKey=yes implicitly adds "visual" > to this set if it is not already present. > > If people think this is a good idea, i'll open a bugzilla ticket about > it. I'm also interested to hear if people have any objections to the idea. Amusingly a brand new bug entry requests the option to display bubblebabble fingerprints. Fell free to repurpose it to your proposal (which I think is fine). https://bugzilla.mindrot.org/show_bug.cgi?id=1759 -d From djm at mindrot.org Tue Apr 20 07:48:28 2010 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Apr 2010 07:48:28 +1000 (EST) Subject: no logging in auth.log when using wrong ssh keys In-Reply-To: References: Message-ID: On Mon, 19 Apr 2010, Hans Harder wrote: > I have in the sshd_config the following to disable password authentication > Match Group dummies > PasswordAuthentication no > KbdInteractive no > > Normally I use denyhosts to detect incorrect logins, but it seems that > failed sshkey logins are not logged in auth.log > And I really like to have them in order to detect them and use the > denyhosts script. > > Looked in the last nightly builds, but it seems that only method ' > password' is being logged. > So I added one line, so that also failed publickey logins are being > logged in auth.log You could just use loglevel=vebose From misha680 at gmail.com Tue Apr 20 07:48:39 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Mon, 19 Apr 2010 16:48:39 -0500 Subject: OpenSSH with "resumable" functionality In-Reply-To: <20100419192343.GA26131@zzlevo.net> References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly> <20100419192343.GA26131@zzlevo.net> Message-ID: <4BCCCFB7.3080309@gmail.com> Andreas Gunnarsson wrote: >> On Sun, Apr 18, 2010 at 05:26:06PM -0500, Misha Koshelev wrote: >>> I was wondering if it might at all be possible to have the following functionality in OpenSSH: >>> (i) upon "timeout" of connection (say 2-5 seconds) disconnect >>> (ii) keep trying to reconnect >>> (iii) upon reconnection, resume session exactly where started > > On Mon, Apr 19, 2010 at 01:08:36PM +0200, Markus Friedl wrote: >> this is a work-in-progress, some parts are already commited to >> the released versions. other parts need to be reviewed. >> >> Andreas can provide details, I think -- and yes, I should >> look into reviewing the remaining patches....... > > I've made the patch available here: > > http://www.zzlevo.net/ssh-roaming.diff > > This is a diff against OpenBSD-current which adds "roaming" to allow an > ssh session to be suspended (i.e. terminate the TCP session) and then > resumed over a new TCP session. The client may resume from the same or a > new IP address. > > A solution which just sets up a new ssh session would tear down open > port forwarded TCP sessions. This patch keeps the client and server > processes running, and applications that use port forwards will not > notice that the ssh session has been suspended and resumed. > > The session is not resumed automatically (the user has to press return) > but that could be a possible enhancement once this is committed. The > patch is based on code written by Martin Forss?n and donated by my > previous employer, AppGate. I haven't made a version for portable > OpenSSH but anyone who wants to will probably be able to do that with > minimal effort. > > As Markus said, this hasn't been fully audited yet. It does touch the > preauth and privsep parts of the code so use on your own risk. :) > > Andreas Thank you all. I am trying to implement something much simple than GNU screen, but am not very familiar with Unix IPC and am having the hardest time. Perhaps you might have some suggestions? Thank you Misha -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-csrc Size: 1338 bytes Desc: not available URL: From imorgan at nas.nasa.gov Tue Apr 20 10:00:20 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 19 Apr 2010 17:00:20 -0700 Subject: Hostbased authentication and certificates Message-ID: <20100420000020.GK1314@linux55.nas.nasa.gov> Hi, Based on some experimentation with 5.4p1 and a cursory examination of the source code, it doesn't look like hostbased authentication takes advantage of certificates other than to authenticate the server. Is that correct? In cluster environments, hostbased authentication is still useful but the size of the ssh_known_hosts file can become unwieldy in large clusters. As an example, a few months back a colleague mentioned that in some cases where the node being logged into was under a high load, the login grace time had expired before the ssh_known_hosts file had been fully parsed. In cases where compute nodes use the same boot image and thus have the same host keys, some reduction in the size of the ssh_known_hosts file can be accomplished by using globbing. This assumes a regular naming pattern for hosts, which is probably the case in a large cluster. An appealing alternative would be to use host certificates with hostbased authentication, but support for that does not seem to be present. Are there any plans to add such support, or are there technical or security reasons to not do so? Thanks -- Iain Morgan From jmknoble at pobox.com Tue Apr 20 15:22:13 2010 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 19 Apr 2010 22:22:13 -0700 Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCCCFB7.3080309@gmail.com> References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly> <20100419192343.GA26131@zzlevo.net> <4BCCCFB7.3080309@gmail.com> Message-ID: <9E476E61-E293-4CA1-8B5D-AF3B2643E435@pobox.com> On Apr 19, 2010, at 14:48, Misha Koshelev wrote: > Thank you all. I am trying to implement something much simple than > GNU screen, but am not very familiar with Unix IPC and am having the > hardest time. > > Perhaps you might have some suggestions? http://dtach.sourceforge.net/ http://tmux.sourceforge.net/ -- jim knoble | jmknoble at pobox.com From djm at mindrot.org Tue Apr 20 16:33:27 2010 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Apr 2010 16:33:27 +1000 (EST) Subject: OpenSSH with "resumable" functionality In-Reply-To: <4BCCCFB7.3080309@gmail.com> References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly> <20100419192343.GA26131@zzlevo.net> <4BCCCFB7.3080309@gmail.com> Message-ID: On Mon, 19 Apr 2010, Misha Koshelev wrote: > Thank you all. I am trying to implement something much simple than > GNU screen, but am not very familiar with Unix IPC and am having the > hardest time. > > Perhaps you might have some suggestions? There are quite a few things wrong with your example, such as: using blocking IO, failing to deal with stdio closure or errors, spinning instead of using select() or poll(). There are probably more problems, I only glanced over it. You should run to your nearest library, borrow and read the entirety of W. Richard Stevens' "Advanced Programming in the UNIX Environment" before writing another line of code. Also, check out libevent: http://www.monkey.org/~provos/libevent/ -d From djm at mindrot.org Tue Apr 20 16:37:46 2010 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Apr 2010 16:37:46 +1000 (EST) Subject: Hostbased authentication and certificates In-Reply-To: <20100420000020.GK1314@linux55.nas.nasa.gov> References: <20100420000020.GK1314@linux55.nas.nasa.gov> Message-ID: On Mon, 19 Apr 2010, Iain Morgan wrote: > Hi, > > Based on some experimentation with 5.4p1 and a cursory examination of > the source code, it doesn't look like hostbased authentication takes > advantage of certificates other than to authenticate the server. Is that > correct? Correct, I haven't implemented certificate authentication in hostbased mostly because I wasn't quite sure of how it should flow. I have only ever used hostbased auth for testing, so I'm not so familiar with how people use it in the real world and didn't feel comfortable in designing extensions to it. > In cluster environments, hostbased authentication is still useful but > the size of the ssh_known_hosts file can become unwieldy in large > clusters. As an example, a few months back a colleague mentioned that in > some cases where the node being logged into was under a high load, the > login grace time had expired before the ssh_known_hosts file had been > fully parsed. > > In cases where compute nodes use the same boot image and thus have the > same host keys, some reduction in the size of the ssh_known_hosts file > can be accomplished by using globbing. This assumes a regular naming > pattern for hosts, which is probably the case in a large cluster. An > appealing alternative would be to use host certificates with hostbased > authentication, but support for that does not seem to be present. > > Are there any plans to add such support, or are there technical or > security reasons to not do so? I don't have any plans to implement it, but I don't have any objections either. If you can come up with a good proposal as to how certs could fit into hostbased then it wouldn't be much to implement it and I'd probably be happy to do it. -d From headset001 at yahoo.com Tue Apr 20 17:43:14 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Tue, 20 Apr 2010 00:43:14 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <892548.62229.qm@web52303.mail.re2.yahoo.com> --- On Mon, 4/19/10, Doru Georgescu wrote: > From: Doru Georgescu > Subject: please decrypt your manuals > To: "OpenSSH" > Date: Monday, April 19, 2010, 4:55 AM > Doru Georgescu wrote: > Not at all. This suggests that you are (again?) confusing > the > protocol SSH with the implementation OpenSSH. > > The documentation relating to these two things will not > neccessarily > overlap very much, if at all. It's better for each entity > to document > it's own scope accurately, than for everyone to try to > document > everything. > Really, look at RFC 4251 and 4252. You may not even need to > go into > the details of 4252 to answer your questions. > Really, to get the details of the SSH protocol, you should > look at > the RFCs. They are not too dense, and should be digestable > in a day > or two if you want to read them from start to end. I believe that we can reach the conclusion that you consider the ssh manuals as a support for ssh developers, while I consider that the ssh manuals should be a support for the users of ssh. From your point of view, the ssh manuals should contain sketches of ideas that a ssh developer would need to remember, while I expect a coherent and self sufficient (but not complete) functional description of ssh. As a user, I need to use it, so I expect to see its functions described in the manual. As a developer, you need to remember some name of a configuration option in the sshd_config file. It looks strange to see such an important application like ssh without a user's manual, but I understand that the developers are not motivated to write it, so this is an economical problem, not a technical one. Thank you all for your support, which I fully appreciate, and it did help me very much. > << Right, the client user, not the client machine > authenticates to the server. This sentence would also make > the manual too clear. Maybe it should be: the "client user account" is authenticated to the server. Doru > //Peter From lars.curator at gmail.com Tue Apr 20 17:48:38 2010 From: lars.curator at gmail.com (Lars Nooden) Date: Tue, 20 Apr 2010 10:48:38 +0300 (EEST) Subject: please decrypt your manuals In-Reply-To: <892548.62229.qm@web52303.mail.re2.yahoo.com> References: <892548.62229.qm@web52303.mail.re2.yahoo.com> Message-ID: On Tue, 20 Apr 2010, Doru Georgescu wrote: > I believe that ... Let's not have speculation. The scope for openssh manual pages is to address the components specific to the openssh suite. The manuals are not remedial tutorials to cover the basics of system administration. There are already whole websites dedicated to that level of training even if it might no longer be available at college. You can submit a patch to the manuals or the source code if you have the skill to make changes and make a diff of your changes. What happens to that patch after being submitted is a whole different matter. (*) /Lars * FOSS projects are under no obligation to accept or integrate patches from random e-yobs regardless of how many Microsoft partners tell you otherwise at their pseudo-conferences, -seminars or other marketing functions. Either the patch fits with the projects goals and quality guidelines or it does not. If it does not, either the idea it is illustrating fits with the project goals or does not. From peter at stuge.se Tue Apr 20 18:10:14 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 20 Apr 2010 10:10:14 +0200 Subject: please decrypt your manuals In-Reply-To: <892548.62229.qm@web52303.mail.re2.yahoo.com> References: <892548.62229.qm@web52303.mail.re2.yahoo.com> Message-ID: <20100420081014.14099.qmail@stuge.se> Hi Doru, Doru Georgescu wrote: > > Really, to get the details of the SSH protocol, you should > > look at the RFCs. > > I believe that we can reach the conclusion that you consider the > ssh manuals as a support for ssh developers, while I consider that > the ssh manuals should be a support for the users of ssh. You have been asking questions all over the map here. For your questions about the use of OpenSSH I've mostly tried to answer and point out how you might benefit from existing documentation. For your questions about very low-level aspects of the SSH protocol I told you that you should not expect to find answers in OpenSSH documentation, but that you should rather go to the canonical specification for the SSH protocols, namely the RFCs. > From your point of view, the ssh manuals should contain sketches of > ideas that a ssh developer would need to remember, Please don't put words in my mouth. > while I expect a coherent and self sufficient (but not complete) > functional description of ssh. As a user, I need to use it, so I > expect to see its functions described in the manual. ssh user at host allows you to log in as user on a host. Since you need more detailed information you have to spend some time with the documentation, and I would recommend doing so when your are feeling focused, ready to analyze and eager to learn. OpenSSH does many more things for many others than you and me, and it tries to document everything. In some places the documentation is not as good as the implementation, but I'm sure you also prefer that over the opposite. If the documentation does not explain something sufficiently well then you can always experiment, or even read the source code, to learn what the programs are actually doing. When you've done so, please send patches for the documentation, maybe first to mailing list for review, then into bugzilla. > As a developer, you need to remember some name of a configuration > option in the sshd_config file. There are several manual pages. Some document programs, other document configuration options. > It looks strange to see such an important application like ssh > without a user's manual, but I understand that the developers are > not motivated to write it, so this is an economical problem, not a > technical one. Maybe you already know how difficult it is to find excellent technical writers. And again - if I have to choose between a developer producing working code and one producing documentation, I will always go for the code. People can run *and* study code. Documentation is simply less important. > Thank you all for your support, which I fully appreciate, and it > did help me very much. Since I'm discussing with you in "spare" time you should be prepared for very high jitter in the response times. //Peter From misha680 at gmail.com Tue Apr 20 22:07:35 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Tue, 20 Apr 2010 07:07:35 -0500 Subject: OpenSSH with "resumable" functionality In-Reply-To: References: <4BCB86FE.3060207@gmail.com> <20100419110836.GA29169@folly> <20100419192343.GA26131@zzlevo.net> <4BCCCFB7.3080309@gmail.com> Message-ID: <4BCD9907.2080402@gmail.com> Damien Miller wrote: > On Mon, 19 Apr 2010, Misha Koshelev wrote: > >> Thank you all. I am trying to implement something much simple than >> GNU screen, but am not very familiar with Unix IPC and am having the >> hardest time. >> >> Perhaps you might have some suggestions? > > There are quite a few things wrong with your example, such as: using > blocking IO, failing to deal with stdio closure or errors, spinning > instead of using select() or poll(). There are probably more problems, > I only glanced over it. > > You should run to your nearest library, borrow and read the entirety > of W. Richard Stevens' "Advanced Programming in the UNIX Environment" > before writing another line of code. Also, check out libevent: > http://www.monkey.org/~provos/libevent/ > > -d Thank you. Apparently, among other things, I flipped the parameters to dup2. I have also switched to a poll() based method. Thank you! Misha From Susan.Diller at PAETEC.com Tue Apr 20 23:09:50 2010 From: Susan.Diller at PAETEC.com (Diller, Susan (Sue)) Date: Tue, 20 Apr 2010 09:09:50 -0400 Subject: logging details In-Reply-To: References: Message-ID: I cannot get sftp to log the file name. And, depending on who I ask, some say it works and others say it doesn't. I was hoping someone at openssh.org could know for sure, and be able to tell me how, if it does. - Sue >From sshd_config: # $OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $ Protocol 2 SyslogFacility local5 LogLevel debug3 #verbose #AuthorizedKeysFile %h/.ssh/authorized_keys ChallengeResponseAuthentication yes Banner /etc/issue X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes MaxStartups 50 #Subsyste sftp /usr/local/libexec/sftp-server -l VERBOSE Subsystem sftp internal-sftp -l VERBOSE Match Group sftpcust ChrootDirectory /asp/sftp/%u AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE PasswordAuthentication yes >From sftplog - Apr 20 08:57:50 ftproc sshd[13252]: [ID 800047 local5.debug] debug3: safely_chro ot: checking '/asp/sftp/ca004' Apr 20 08:57:50 ftproc sshd[13250]: [ID 800047 local5.info] User child is on pid 13252 Apr 20 08:57:50 ftproc sshd[13250]: [ID 800047 local5.debug] debug3: mm_request_ receive entering Apr 20 08:58:17 ftproc sshd[13250]: [ID 800047 local5.debug] debug3: monitor_rea d: checking request 58 Apr 20 08:58:17 ftproc sshd[13250]: [ID 800047 local5.debug] debug3: mm_answer_t erm: tearing down sessions Action taken: sftp> ls . .. zzz sftp> get zzz Fetching /reports/zzz to zzz sftp> quit >From xferlog, using ftp: Tue Apr 20 08:57:00 2010 1 uxrp999 0 /asp/ftp/ca001/daily/zzz b _ o r ca001 ftp 0 * c -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Monday, April 19, 2010 5:41 PM To: Diller, Susan (Sue) Cc: openssh-unix-dev at mindrot.org Subject: RE: logging details You can pass commandline arguments to internal-sftp and via ForceCommand too. -d On Mon, 19 Apr 2010, Diller, Susan (Sue) wrote: > > Shouldn't the subsystem be set to internel-sftp? Or, can the Subsystem and ForceCommand options be different? > > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Friday, April 16, 2010 5:46 PM > To: Diller, Susan (Sue) > Cc: openssh-unix-dev at mindrot.org > Subject: Re: logging details > > On Fri, 16 Apr 2010, Diller, Susan (Sue) wrote: > > > Are there plans to expand the logging capabilities in OpenSSH, so > > that the details of what files were moved using sftp is included? If > > not, does anyone know of a good way to capture this information? > > sftp-server has supported this for a while. Try specifying: > > Subsystem sftp /usr/libexec/sftp-server -l VERBOSE > > in sshd_config (you might need a different path to sftp-server). > > -d > From headset001 at yahoo.com Wed Apr 21 00:17:41 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Tue, 20 Apr 2010 07:17:41 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <114454.55000.qm@web52306.mail.re2.yahoo.com> > And if user authentication is done with public keys then a man in the > middle attack isn't possible even if the attacker knows the private > part of the host key.[...] On Mon, Apr 19, 2010 at 12:06:33AM -0700, Doru Georgescu wrote: > If the attacker knows the server's private host key, and all public > keys, then it could impersonate the server in front of the client. Why > not? It can impersonate the server, but not perform a man in the middle attack. Simplified, it's because it can't forge the Diffie-Hellman exchange which affects the session ID which is signed by the user's key. See the RFCs (4252 and 4253 I think) for a detailed explanation how it works. Of course, this is probably mostly of interest in theory since a compromised private server key may be an indication that the entire server is compromised. Andreas --------------- The attacker does not have some private decryption key? Anyway, this is too involved for me now, but thank you anyway. Doru From headset001 at yahoo.com Wed Apr 21 00:32:18 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Tue, 20 Apr 2010 07:32:18 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <898616.93887.qm@web52301.mail.re2.yahoo.com> --- On Tue, 4/20/10, Lars Nooden wrote: > From: Lars Nooden > Subject: Re: please decrypt your manuals > To: "Doru Georgescu" > Cc: "OpenSSH" > Date: Tuesday, April 20, 2010, 3:48 AM > On Tue, 20 Apr 2010, Doru Georgescu > wrote: > > I believe that ... > > Let's not have speculation. > It has been said several times in this thread that the manual is good enough for those who already know ssh. And it is. This is not speculation. > The scope for openssh manual pages is to address the > components specific to the openssh suite. I won't argue on that. > The manuals are not remedial tutorials to cover the basics > of system administration. There are already whole > websites dedicated to that level of training even if it > might no longer be available at college. The manuals are not many things. > You can submit a patch to the manuals or the source code if > you have the skill to make changes and make a diff of your > changes. What happens to that patch after being > submitted is a whole different matter. (*) Precisely because ssh is the work of a community, it is largely meaningless for me to write a manual alone, without tight cooperation with that community. The manual should transmit information from developers to users. For this to happen, a language (symbols, terminology, structure, logical implication rules) should be developed. The very idea that I can do this alone, outside the developers' community, is absurd. Of course such a manual would be rejected, because it would not make any sense to the developers. Plus, I completely lack the resources for such a work. Doru > > /Lars > > * FOSS projects are under no obligation to accept or > integrate patches from random e-yobs regardless of how many > Microsoft partners tell you otherwise at their > pseudo-conferences, -seminars or other marketing > functions. Either the patch fits with the projects > goals and quality guidelines or it does not. If it > does not, either the idea it is illustrating fits with the > project goals or does not. > From peter at stuge.se Wed Apr 21 02:42:16 2010 From: peter at stuge.se (Peter Stuge) Date: Tue, 20 Apr 2010 18:42:16 +0200 Subject: please decrypt your manuals In-Reply-To: <898616.93887.qm@web52301.mail.re2.yahoo.com> References: <898616.93887.qm@web52301.mail.re2.yahoo.com> Message-ID: <20100420164216.30142.qmail@stuge.se> Doru Georgescu wrote: > Precisely because ssh is the work of a community, it is largely > meaningless for me to write a manual alone, without tight > cooperation with that community. The manual should transmit > information from developers to users. I disagree. I don't think this is the only way to produce a good manual. Users can, and should, educate themselves, and then they can write documentation with insight. Not all users are good writers, but maybe one user here and there (you!) is a good enough writer to feel strongly about the issue, and make a contribution. > For this to happen, a language (symbols, terminology, structure, > logical implication rules) should be developed. The very idea that > I can do this alone, outside the developers' community, is absurd. So there is a bootstrapping problem. You mean that you need to know more about SSH and OpenSSH before you can work on improving the documentation for OpenSSH - and you can't learn enough from the existing documentation. I disagree again - you can always work on *parts* of the documentation. And if you really want to bridge developers and users then you need to drill down into particular points, to really learn the high level aspects of the concept (but not all the details in the code) - so as to distill it into user digestable format. This is not trivial. Again, there aren't many really great technical writers. :\ > Of course such a manual would be rejected, because it would not > make any sense to the developers. Oh I don't know. I think there are many opportunities for you to publish material about OpenSSH. Even if your contribution does not end up in a man page, maybe it will be hosted on a web server somewhere as a tutorial. > Plus, I completely lack the resources for such a work. Aha. But you request resources of others to do it. As you already pointed out - others also lack resources. //Peter From keisial at gmail.com Wed Apr 21 04:20:31 2010 From: keisial at gmail.com (Keisial) Date: Tue, 20 Apr 2010 20:20:31 +0200 Subject: please decrypt your manuals In-Reply-To: <114454.55000.qm@web52306.mail.re2.yahoo.com> References: <114454.55000.qm@web52306.mail.re2.yahoo.com> Message-ID: <4BCDF06F.3090704@gmail.com> Doru Georgescu wrote: > The attacker does not have some private decryption key? Anyway, this is too involved for me now, but thank you anyway. > > Doru > No. The server private key [for the connection] is only held on the server memory. That's the reason sshd has a "long" startup time and is unsuitable to spawn a sshd on each connection from inetd. Moreover, the server ephemeral key (on ssh v1) is changed each KeyRegenerationInterval econds, and on ssh v2 RekeyLimit establishes after how much data transferred the session key (the key used connecting with this user) is renegotiated. It is designed in such way that even if the attacker dumps all the network packets, and later it is able to compromise the machine, it still cannot figure out the contents of the transmission (this doesn't include logs of user actions as .bash_history, breaking in the machine with a "later" time so short that it can read the daemon memory...). > Precisely because ssh is the work of a community, it is largely meaningless for me to write a manual alone, without tight cooperation with that community. The manual should transmit information from developers to users. For this to happen, a language (symbols, terminology, structure, logical implication rules) should be developed. The very idea that I can do this alone, outside the developers' community, is absurd. Of course such a manual would be rejected, because it would not make any sense to the developers. > You can improve per sections, so you get immediate feedback on how you are doing, can correct easier and spend less resources if doing bad. Being smaller changes, it also eases review. Summarising sparse explanations given in a mailing list from the /cognoscenti/ is a good way of creating documentation. But yes, it requires quite a bit of struggling to find the right information before "the perfect manual" can be made. From djm at mindrot.org Wed Apr 21 08:59:52 2010 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Apr 2010 08:59:52 +1000 (EST) Subject: logging details In-Reply-To: References: Message-ID: sftp-server doesn't log to xferlog, you can control which syslog facility it uses with the -f flag. Also, if you are using ChrootDirectory, you might need to arrange syslog to listen inside your chroot at (relative) /dev/log On Tue, 20 Apr 2010, Diller, Susan (Sue) wrote: > I cannot get sftp to log the file name. And, depending on who I ask, some say it works and others say it doesn't. I was hoping someone at openssh.org could know for sure, and be able to tell me how, if it does. - Sue > > From sshd_config: > # $OpenBSD: sshd_config,v 1.81 2009/10/08 14:03:41 markus Exp $ > Protocol 2 > SyslogFacility local5 > LogLevel debug3 #verbose > #AuthorizedKeysFile %h/.ssh/authorized_keys > ChallengeResponseAuthentication yes > Banner /etc/issue > X11Forwarding yes > X11DisplayOffset 10 > X11UseLocalhost yes > MaxStartups 50 > #Subsyste sftp /usr/local/libexec/sftp-server -l VERBOSE > Subsystem sftp internal-sftp -l VERBOSE > Match Group sftpcust > ChrootDirectory /asp/sftp/%u > AllowTcpForwarding no > ForceCommand internal-sftp -l VERBOSE > PasswordAuthentication yes > > From sftplog - > Apr 20 08:57:50 ftproc sshd[13252]: [ID 800047 local5.debug] debug3: safely_chro > ot: checking '/asp/sftp/ca004' > Apr 20 08:57:50 ftproc sshd[13250]: [ID 800047 local5.info] User child is on pid > 13252 > Apr 20 08:57:50 ftproc sshd[13250]: [ID 800047 local5.debug] debug3: mm_request_ > receive entering > Apr 20 08:58:17 ftproc sshd[13250]: [ID 800047 local5.debug] debug3: monitor_rea > d: checking request 58 > Apr 20 08:58:17 ftproc sshd[13250]: [ID 800047 local5.debug] debug3: mm_answer_t > erm: tearing down sessions > > Action taken: > sftp> ls > . > .. > zzz > sftp> get zzz > Fetching /reports/zzz to zzz > sftp> quit > > From xferlog, using ftp: > > Tue Apr 20 08:57:00 2010 1 uxrp999 0 /asp/ftp/ca001/daily/zzz b _ o r ca001 ftp > 0 * c > > -----Original Message----- > From: Damien Miller [mailto:djm at mindrot.org] > Sent: Monday, April 19, 2010 5:41 PM > To: Diller, Susan (Sue) > Cc: openssh-unix-dev at mindrot.org > Subject: RE: logging details > > You can pass commandline arguments to internal-sftp and via ForceCommand too. > > -d > > On Mon, 19 Apr 2010, Diller, Susan (Sue) wrote: > > > > > Shouldn't the subsystem be set to internel-sftp? Or, can the Subsystem and ForceCommand options be different? > > > > -----Original Message----- > > From: Damien Miller [mailto:djm at mindrot.org] > > Sent: Friday, April 16, 2010 5:46 PM > > To: Diller, Susan (Sue) > > Cc: openssh-unix-dev at mindrot.org > > Subject: Re: logging details > > > > On Fri, 16 Apr 2010, Diller, Susan (Sue) wrote: > > > > > Are there plans to expand the logging capabilities in OpenSSH, so > > > that the details of what files were moved using sftp is included? If > > > not, does anyone know of a good way to capture this information? > > > > sftp-server has supported this for a while. Try specifying: > > > > Subsystem sftp /usr/libexec/sftp-server -l VERBOSE > > > > in sshd_config (you might need a different path to sftp-server). > > > > -d > > > From misha680 at gmail.com Wed Apr 21 10:37:59 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Tue, 20 Apr 2010 19:37:59 -0500 Subject: ServerAliveInterval exit code? Message-ID: <4BCE48E7.1000009@gmail.com> Dear Sirs: Thank you so much for your help. I have now created both the client and server for resumable nx sessions using the ServerAliveInterval option to disconnect after several seconds of server inaccessibility. I am now working on an nxssh "substitute", which at this point seems fairly straightforward. However, when I spawn ssh, I need to know whether: (a) it exited because of ServerAliveInterval, and I should re-connect or (b) it exited for some other reason (session finished). Is there, by any chance, some way I could detect this, perhaps by an exit code? Thank you Please reply all Sincerely yours Misha Koshelev From headset001 at yahoo.com Wed Apr 21 22:31:06 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Wed, 21 Apr 2010 05:31:06 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <375697.78725.qm@web52301.mail.re2.yahoo.com> > As you already pointed out - others also lack resources. //Peter This is inefficient from the point of view of the project. Developers work outside a well written documentation, which should define what they are supposed to do. Developers work without a good reference at hand, defining what was already done. One of them did not know that ~/.ssh/known_hosts can be used by the server under version 2 of the protocol. It is not his fault. It is easy for a developer to document his work incrementally, while he knows what he did. A newcomer has to read the code. How would you feel to have to read the code of Linux, or at least bash, before you use it? For some out this world reason, developers provided a long list of absurd arguments in favour of the idea that the manual is very good as it is. The effort spent by them and by me with this sterile argumentation would have made the manual to be well organized at a high level already. ssh developers prefer to have 105 code and 15 manual instead of 100 code and 100 manual. In the end, some documentation still has to be written, to provide efficient transmission of information about the functionality of ssh. It is extremely costly to transmit it verbally, on an individual basis, or by the means of reading the code. In the meantime, we all waste the meager resources we have. Doru From headset001 at yahoo.com Wed Apr 21 21:58:29 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Wed, 21 Apr 2010 04:58:29 -0700 (PDT) Subject: please decrypt your manuals In-Reply-To: <4BCDF06F.3090704@gmail.com> Message-ID: <608793.65859.qm@web52303.mail.re2.yahoo.com> --- On Tue, 4/20/10, Keisial wrote: > From: Keisial > Subject: Re: please decrypt your manuals > To: "Doru Georgescu" , openssh-unix-dev at mindrot.org > Date: Tuesday, April 20, 2010, 2:20 PM > Doru Georgescu wrote: > > The attacker does not have some private decryption > key? Anyway, this is too involved for me now, but thank you > anyway. > > > > Doru > >??? > > No. The server private key [for the connection] is only > held on the > server memory. That's the reason sshd has a "long" startup > time and is > unsuitable to spawn a sshd on each connection from inetd. > Moreover, the server ephemeral key (on ssh v1) is changed > each > KeyRegenerationInterval econds, and on ssh v2 RekeyLimit > establishes > after how much data transferred the session key (the key > used connecting > with this user) is renegotiated. > > It is designed in such way that even if the attacker dumps > all the > network packets, and later it is able to compromise the > machine, it > still cannot figure out the contents of the transmission > (this doesn't > include logs of user actions as .bash_history, breaking in > the machine > with a "later" time so short that it can read the daemon > memory...). The ephemeral key is what I called the private decryption key, which is used to decrypt messages received by the host (server in this case), right? > > > > Precisely because ssh is the work of a community, it > is largely meaningless for me to write a manual alone, > without tight cooperation with that community. The manual > should transmit information from developers to users. For > this to happen, a language (symbols, terminology, structure, > logical implication rules) should be developed. The very > idea that I can do this alone, outside the developers' > community, is absurd. Of course such a manual would be > rejected, because it would not make any sense to the > developers. > >??? > You can improve per sections, so you get immediate feedback > on how you > are doing, can correct easier and spend less resources if > doing bad. > Being smaller changes, it also eases review. > > Summarising sparse explanations given in a mailing list > from the > /cognoscenti/ is a good way of creating documentation. But > yes, it > requires quite a bit of struggling to find the right > information before > "the perfect manual" can be made. > I am doing this. :) > From Susan.Diller at PAETEC.com Wed Apr 21 23:09:31 2010 From: Susan.Diller at PAETEC.com (Diller, Susan (Sue)) Date: Wed, 21 Apr 2010 09:09:31 -0400 Subject: logging details In-Reply-To: References: Message-ID: Lars - 5.5 does not seem to be available, yet. I am running OpenSSH_5.4p1. Damien - The xferlog was from an ftp session. I was just using it to show that ftp can tell me the file which was transferred. I moved the sftp log under the chroot /dev area. It still logs everything, except the file name. I understand that the filename and directory information will be coming across the network encrypted. But, there must be a way the server can figure out what file was transferred. It knows the PID of the connecting process. Does the logfile need to be writable by the accounts doing the transfers? - Sue -----Original Message----- From: Lars Nooden [mailto:lars.curator at gmail.com] Sent: Wednesday, April 21, 2010 4:48 AM To: Damien Miller Cc: Diller, Susan (Sue); openssh-unix-dev at mindrot.org Subject: RE: logging details On Wed, 21 Apr 2010, Damien Miller wrote: > Also, if you are using ChrootDirectory, you might need to arrange > syslog to listen inside your chroot at (relative) /dev/log That burden seems to have been removed starting with OpenSSH 5.5, and the following does logging with the specified log level and faclity code without needing a socket in the chroot: ChrootDirectory /altroot/foo/ Subsystem sftp internal-sftp -f LOCAL0 -l VERBOSE ForceCommand internal-sftp /Lars From misha680 at gmail.com Wed Apr 21 22:17:35 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Wed, 21 Apr 2010 07:17:35 -0500 Subject: prototype of simple NX client with auto-resuming ssh session Message-ID: <4BCEECDF.4060503@gmail.com> Dear All: --- Summary, especially for openssh list (to test/reproduce): THANK YOU for all your help. Please extract into /home/username/nx on both host and client. cp ssh to a file named mxssh in that directory. Run (with an _n_ below) Start server on the remote host by typing ./server & Now do: ./nxssh hostname If you killall client on the remote end, it reconnects "seamlessly" (I am using this to simulate ServerAliveInterval). However, if I do this from _within_ the nxclient program it _detects_ my disconnect even though the thread is still running (I believe). Any ideas? Thank you Misha p.s. Also right now I have functionality to spawn the server directly from the client, but somehow the signal(SIGHUP,SIG_HUP) command causes _both_ the server and client to ignore SIGHUP, even though it is called _only_ in the client. Any ideas? Thank you! --- Thank you so much for your help. I have put my current prototype on the Web at: people.hnl.bcm.edu/misha/tmp/nx.zip Includes source code, and binary executables for amd64. Right now, expects to live in the /home/username/nx folder on the remote machine (machine being connected to). Expects nx certificates in right places (/usr/NX). The nxssh requires an ssh executable to be in the same directory called mxssh (say original nxssh from NoMachine or even plain old ssh for command line testing). Currently, I (1) get a _seamless_ connection from the command line however (2) nxclient somehow detects intermediate disconnects Note the NX part works until a disconnect (I just do killall cient). Thank you! Misha From lars.curator at gmail.com Wed Apr 21 18:47:46 2010 From: lars.curator at gmail.com (Lars Nooden) Date: Wed, 21 Apr 2010 11:47:46 +0300 (EEST) Subject: logging details In-Reply-To: References: Message-ID: On Wed, 21 Apr 2010, Damien Miller wrote: > Also, if you are using ChrootDirectory, you might need to arrange syslog > to listen inside your chroot at (relative) /dev/log That burden seems to have been removed starting with OpenSSH 5.5, and the following does logging with the specified log level and faclity code without needing a socket in the chroot: ChrootDirectory /altroot/foo/ Subsystem sftp internal-sftp -f LOCAL0 -l VERBOSE ForceCommand internal-sftp /Lars From headset001 at yahoo.com Wed Apr 21 21:49:59 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Wed, 21 Apr 2010 04:49:59 -0700 (PDT) Subject: please decrypt your manuals Message-ID: <340451.64785.qm@web52305.mail.re2.yahoo.com> I include my current knowledge of ssh. The //server/ and //client/ notations are wrong, I kept them for convenience only. I use the word "machine" instead of "host" in a few places. This is wrong. Please get over it. Some file permissions are restricted too much, but still functional. This is not important right now. The information is very incomplete, but it covers most used authentication techniques. Please tell me if you agree with it. ssh is the client sshd is the server Communication is fully encrypted and authenticated in both directions. The encryption keys are regenerated during communication (~R in man ssh, RekeyLimit in man ssh_config). The authenticated machine's (usually the server) host authentication keys are used to authenticate it in front of other machines or user accounts. These keys are memorized on the authenticated machine: /etc/ssh/ssh_host_[rd]sa_key /etc/ssh/ssh_host_[rd]sa_key.pub ssh-keygen - authentication key generation and management The authenticating machine or user account (usually the client) can memorize known machines' public host keys in /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts. Authentication of the server machine in front of the client user account: the client verifies that the server's public host key is known: a. with a stupid question to the unknowing human at the client's console b. verifying the server's public host key against the lists of servers' public host keys in: //client/etc/ssh/ssh_known_hosts and //client/~/.ssh/known_hosts you can copy and paste the key from //server/etc/ssh/ssh_host_rsa_key.pub to //client/~/.ssh/known_hosts, minus username at server at the end, plus username at server at the beginning, with blanks as separators. ssh-keygen -H to hash names. Authentication of the client user account in front of the server machine: a. the client provides its password b. the client provides an authentication key: + private part in //client/~/.ssh/id_rsa + public part in //server/~/.ssh/authorized_keys with chmod 700 .ssh; chmod 600 authorized_keys the authentication key is created on the client with: ssh-keygen -t rsa ll gives: -rw------- 1 dave dave 526 Nov 3 01:21 id_rsa -rw-r--r-- 1 dave dave 330 Nov 3 01:21 id_rsa.pub and can be copied from the client with (just a direct copy from //client/~/.ssh/id_rsa.pub to //server/~/.ssh/authorized_keys, or append to preserve other keys): ssh-copy-id username at server see mans ssh, sshd, ssh_config, sshd_config From keisial at gmail.com Thu Apr 22 01:22:42 2010 From: keisial at gmail.com (Keisial) Date: Wed, 21 Apr 2010 17:22:42 +0200 Subject: please decrypt your manuals In-Reply-To: <340451.64785.qm@web52305.mail.re2.yahoo.com> References: <340451.64785.qm@web52305.mail.re2.yahoo.com> Message-ID: <4BCF1842.8020409@gmail.com> Doru Georgescu wrote: > Developers work without a good reference at hand, defining what was already done. One of them did not know that ~/.ssh/known_hosts can be used by the server under version 2 of the protocol. It is not his fault. > Do not count me as a ssh developer. I am not. I just happen to know a little more than you, but you should still take my opinions on how it works with a grain of salt. > The encryption keys are regenerated during communication (~R in man ssh, RekeyLimit in man ssh_config). > They are generated at the beginning, and may be regenerated during communication. It is worth to make explicit that it is different than the authentication key mentioned below. > The authenticated machine's (usually the server) host authentication keys are used to authenticate it in front of other machines or user accounts. These keys are memorized on the authenticated machine: > /etc/ssh/ssh_host_[rd]sa_key > /etc/ssh/ssh_host_[rd]sa_key.pub > ssh-keygen - authentication key generation and management > > The authenticating machine or user account (usually the client) can memorize known machines' public host keys in /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts. > > Authentication of the server machine in front of the client user account: > > the client verifies that the server's public host key is known: > > a. with a stupid question to the unknowing human at the client's console > b. verifying the server's public host key against the lists of servers' public host keys in: > //client/etc/ssh/ssh_known_hosts and //client/~/.ssh/known_hosts > Step b done before a. > the authentication key is created on the client with: > ssh-keygen -t rsa > ll gives: > -rw------- 1 dave dave 526 Nov 3 01:21 id_rsa > -rw-r--r-- 1 dave dave 330 Nov 3 01:21 id_rsa.pub > and can be copied from the client with (just a direct copy from //client/~/.ssh/id_rsa.pub to //server/~/.ssh/authorized_keys, or append to preserve other keys): > ssh-copy-id username at server > ssh-keygen -t rsa generates a rsa key. Other acceptable values for -t are rsa1 and dsa. I would just note that they are created by ssh-keygen, and let people check ssh-keygen(1) for more information. From misha680 at gmail.com Thu Apr 22 08:12:01 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Wed, 21 Apr 2010 17:12:01 -0500 Subject: prototype of simple NX client with auto-resuming ssh session In-Reply-To: <4BCF15A3.4080602@gmail.com> References: <4BCEECDF.4060503@gmail.com> <4BCF15A3.4080602@gmail.com> Message-ID: <4BCF7831.7070405@gmail.com> Keisial wrote: > Misha Koshelev wrote: >> p.s. Also right now I have functionality to spawn the server directly from the client, but somehow the signal(SIGHUP,SIG_HUP) command causes _both_ the server and client to ignore SIGHUP, even though it is called _only_ in the client. Any ideas? Thank you! >> > (I assume you mean SIG_IGN, not SIG_HUP) > > The server inherits the ignoring of SIGHUP. From signal(7) >> A child created via fork(2) inherits a copy of its >> parent's signal dispositions. During an >> execve(2), the dispositions of handled signals are reset to the >> default; the dispositions of ignored >> signals are left unchanged. > > Perform signal(SIGHUP, SIG_DFL); after the fork but before the execv (or > simply set SIGHUP to whatever you want in the server). In other words - this does not actually happen. In fact, I do _nothing_ to signals at all in the client, but when I spawn the server _from_ the client ssh will not disconnect even if the client dies... Any ideas? Maybe its not a signal issue at all. Thank you! Misha From misha680 at gmail.com Thu Apr 22 08:08:48 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Wed, 21 Apr 2010 17:08:48 -0500 Subject: prototype of simple NX client with auto-resuming ssh session In-Reply-To: <4BCF15A3.4080602@gmail.com> References: <4BCEECDF.4060503@gmail.com> <4BCF15A3.4080602@gmail.com> Message-ID: <4BCF7770.2020802@gmail.com> Keisial wrote: > Misha Koshelev wrote: >> p.s. Also right now I have functionality to spawn the server directly from the client, but somehow the signal(SIGHUP,SIG_HUP) command causes _both_ the server and client to ignore SIGHUP, even though it is called _only_ in the client. Any ideas? Thank you! >> > (I assume you mean SIG_IGN, not SIG_HUP) > > The server inherits the ignoring of SIGHUP. From signal(7) >> A child created via fork(2) inherits a copy of its >> parent's signal dispositions. During an >> execve(2), the dispositions of handled signals are reset to the >> default; the dispositions of ignored >> signals are left unchanged. > > Perform signal(SIGHUP, SIG_DFL); after the fork but before the execv (or > simply set SIGHUP to whatever you want in the server). > I am sorry. Not sure what I was on when writing my email this morning ;) What I meant is the following. I have machine A from which I am connecting, machine B _to_ which I am connecting. Two scenarios: i) I start server on machine B. Then, from machine A, I do ssh B nx/client. Now, on machine B, I do killall client. SIGHUP is sent, client dies, ssh session from machine A ends. ii) I ssh B nx/client; the _client_ spawns the server. Now, on machine B, when I do killall client, the client dies but SSH DOES NOT DISCONNECT! Why would this be? Thank you Misha Koshelev p.s. The other problem is as follows: in the "nxssh" executable, I have a while (1) loop where I _fork_ to start a child process, and then execl ssh. The parent simply has a wait(NULL) call. Now, from the command line, this creates the illusion of a seamless SSH session after disconnects. However, nxclient somehow detects this. Any ideas? From philipp_subx at redfish-solutions.com Thu Apr 22 13:20:40 2010 From: philipp_subx at redfish-solutions.com (Philip A. Prindeville) Date: Wed, 21 Apr 2010 21:20:40 -0600 Subject: QoS marking for Openssh In-Reply-To: References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BC7537E.2010003@redfish-solutions.com> Message-ID: <4BCFC088.10704@redfish-solutions.com> I tried sending the patch upstream to the BSD folks, but didn't hear back. Well, except for Todd's comment offline. On 04/15/2010 01:39 PM, Ben Lindstrom wrote: > > "p" releases beyond "p1" are normally used to fix portable issues. Since this is a feature add I suspect the soonest (if accepted) it will get it will be 5.6. Since it may have to go upstream to OpenBSD. > > - Ben > > On Apr 15, 2010, at 12:57 PM, Philip A. Prindeville wrote: > >> On 03/24/2010 12:45 PM, Philip A. Prindeville wrote: >>> Anyone want to code review: >>> >>> https://bugzilla.mindrot.org/show_bug.cgi?id=1733 >>> >>> >>> There's a patch attached. We're currently using it on astlinux. >>> >>> Thanks. >>> >>> >> >> >> We're using it now. Works great. >> >> I've built Fedora scratch images and posted those, and haven't gotten >> any negative feedback from anyone using them. >> >> What do we need to do at this point to get it committed? >> >> I'm hoping it can make 5.5p2? Maybe?? >> >> Thanks. From peter at stuge.se Thu Apr 22 14:31:29 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 22 Apr 2010 06:31:29 +0200 Subject: please decrypt your manuals In-Reply-To: <375697.78725.qm@web52301.mail.re2.yahoo.com> References: <375697.78725.qm@web52301.mail.re2.yahoo.com> Message-ID: <20100422043129.18627.qmail@stuge.se> Doru Georgescu wrote: > How would you feel to have to read the code of Linux, or at least > bash, before you use it? The fact that I am invited to do so is why I love open source. //Peter From peter at stuge.se Thu Apr 22 14:34:16 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 22 Apr 2010 06:34:16 +0200 Subject: please decrypt your manuals In-Reply-To: <375697.78725.qm@web52301.mail.re2.yahoo.com> References: <375697.78725.qm@web52301.mail.re2.yahoo.com> Message-ID: <20100422043416.19148.qmail@stuge.se> Doru Georgescu wrote: > Developers .. > One of them did not know that ~/.ssh/known_hosts can be used by the > server under version 2 of the protocol. It is not his fault. Eh? Are you sure that was a developer? Anyway, my impression from the 10-or-so years on this mailing list is that host-based authentication is one of the less commonly used features of OpenSSH, so I understand if it isn't completely understood by all developers. (I don't know the details either. I don't need to.) //Peter From peter at stuge.se Thu Apr 22 14:40:31 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 22 Apr 2010 06:40:31 +0200 Subject: please decrypt your manuals In-Reply-To: <20100422043416.19148.qmail@stuge.se> References: <375697.78725.qm@web52301.mail.re2.yahoo.com> <20100422043416.19148.qmail@stuge.se> Message-ID: <20100422044031.20070.qmail@stuge.se> Peter Stuge wrote: > Doru Georgescu wrote: > > Developers > .. > > One of them did not know that ~/.ssh/known_hosts can be used by the > > server under version 2 of the protocol. It is not his fault. > > Eh? Are you sure that was a developer? > > Anyway, my impression from the 10-or-so years on this mailing list is > that host-based authentication is one of the less commonly used > features of OpenSSH, so I understand if it isn't completely > understood by all developers. (I don't know the details either. > I don't need to.) I doubt if you can consider me a developer here. Too low patch count. But I hang around and try to help if I can. //Peter From headset001 at yahoo.com Thu Apr 22 17:10:56 2010 From: headset001 at yahoo.com (Doru Georgescu) Date: Thu, 22 Apr 2010 00:10:56 -0700 (PDT) Subject: please decrypt your manuals In-Reply-To: <4BCF1842.8020409@gmail.com> Message-ID: <255158.43509.qm@web52301.mail.re2.yahoo.com> Thank you for the check and for the corrections. I finally got it right, Doru --- On Wed, 4/21/10, Keisial wrote: > From: Keisial > Subject: Re: please decrypt your manuals > To: "Doru Georgescu" , openssh-unix-dev at mindrot.org > Date: Wednesday, April 21, 2010, 11:22 AM > > The encryption keys are regenerated during > communication (~R in man ssh, RekeyLimit in man ssh_config). > > >??? > They are generated at the beginning, and may be regenerated > during > communication. It is worth to make explicit that it is > different than > the authentication key mentioned below. > > > > The authenticated machine's (usually the server) host > authentication keys are used to authenticate it in front of > other machines or user accounts. These keys are memorized on > the authenticated machine: > > /etc/ssh/ssh_host_[rd]sa_key > > /etc/ssh/ssh_host_[rd]sa_key.pub > > ssh-keygen - authentication key generation and > management > > > > The authenticating machine or user account (usually > the client) can memorize known machines' public host keys in > /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts. > > > > Authentication of the server machine in front of the > client user account: > > > >? ???the client verifies that the > server's public host key is known: > > > >? ???a. with a stupid question to > the unknowing human at the client's console > >? ???b. verifying the server's > public host key against the lists of servers' public host > keys in: > >? ? ? > ???//client/etc/ssh/ssh_known_hosts and > //client/~/.ssh/known_hosts > >??? > Step b done before a. > > > > > >? ? ? the authentication key is created > on the client with: > >? ? ? ssh-keygen -t rsa > >? ? ? ll gives: > >? ? ? -rw-------? ? 1 > dave? ???dave? ? ? ? > ? 526 Nov? 3 01:21 id_rsa > >? ? ? -rw-r--r--? ? 1 > dave? ???dave? ? ? ? > ? 330 Nov? 3 01:21 id_rsa.pub > >? ? ? and can be copied from the client > with (just a direct copy from //client/~/.ssh/id_rsa.pub to > //server/~/.ssh/authorized_keys, or append to preserve other > keys): > >? ? ? ssh-copy-id username at server > >??? > > ssh-keygen -t rsa generates a rsa key. Other acceptable > values for -t > are rsa1 and dsa. I would just note that they are created > by ssh-keygen, > and let people check > > ssh-keygen(1) for more information. > > > From Susan.Diller at PAETEC.com Sat Apr 24 05:48:40 2010 From: Susan.Diller at PAETEC.com (Diller, Susan (Sue)) Date: Fri, 23 Apr 2010 15:48:40 -0400 Subject: logging details In-Reply-To: References: Message-ID: I am back to my original question. Are there plans to improve the logging so that it reports which file was transferred ? I can get lots of information in the log, but not what I need. - Sue Susan K. Diller UNIX Systems Administration PAETEC Communications, Inc. 600 WillowBrook Office Park Fairport, New York 14450 (585) 413-2320 * susan.diller at paetec.com From lars.curator at gmail.com Sat Apr 24 23:56:36 2010 From: lars.curator at gmail.com (Lars Nooden) Date: Sat, 24 Apr 2010 16:56:36 +0300 (EEST) Subject: logging details In-Reply-To: References: Message-ID: On Fri, 23 Apr 2010, Diller, Susan (Sue) wrote: > ... Are there plans to improve the logging so that it reports which > file was transferred ? I can get lots of information in the log, but > not what I need. Currently, looking at OpenSSH_5.5, OpenSSL 0.9.8k from 25 Mar 2009, setting the log level to VERBOSE will show the file transfered. Here is one way to get that level of detail: Subsystem sftp internal-sftp -f LOCAL0 -l VERBOSE The ForceCommand directive must also have log facility and log level set explicitly if it is used: ForceCommnand internal-sftp -f LOCAL0 -l VERBOSE Regards /Lars Apr 24 16:22:00 yeeloong sshd[11426]: Accepted password for foobar from foo.example.org port 45334 ssh2 Apr 24 16:22:00 yeeloong sshd[12866]: subsystem request for sftp Apr 24 16:22:00 yeeloong internal-sftp[19013]: session opened for local user foobar from [foo.example.org] Apr 24 16:22:00 yeeloong internal-sftp[19013]: received client version 3 Apr 24 16:22:00 yeeloong internal-sftp[19013]: realpath "." Apr 24 16:22:02 yeeloong internal-sftp[19013]: lstat name "/home/foobar/xx" Apr 24 16:22:02 yeeloong internal-sftp[19013]: stat name "/home/foobar/xx" Apr 24 16:22:02 yeeloong internal-sftp[19013]: open "/home/foobar/xx" flags READ mode 0666 Apr 24 16:22:02 yeeloong internal-sftp[19013]: close "/home/foobar/xx" bytes read 30 written 0 From misha680 at gmail.com Sun Apr 25 01:11:19 2010 From: misha680 at gmail.com (Misha Koshelev) Date: Sat, 24 Apr 2010 10:11:19 -0500 Subject: Update on "non-dying" nx connections over unreliable network Message-ID: <4BD30A17.2090107@gmail.com> Dear Sirs & Madams: Thank you so much for your help. To remind, my situation is a wireless connection that is unreliable, where: (a) upon disconnect, !M's nxclient does not recognize connection death (b) after I manually kill nxssh and reconnect, reconnection takes some time. My idea: intercept myself in between NX client and server - detect connection drop, and reconnect. This is proving quite difficult. My prototype is here. For now, I have dropped all encryption. http://people.hnl.bcm.edu/misha/tmp/nx.zip You will find: nx/comps - compiles server (setuid root currently) nx/compc - compiles client (moves old one to mxssh and replaces) Host name and port are hardcoded at the moment. To test: ssh server cd nx ./server Then connect on the client using !M's client. Unfortunately, I seem to have ended up with a glorified way of peeking at the NX authentication connection (please see included logs in ZIP file, password is masked). I am guessing at this point, the proxy connection is probably launched. However, I am not quite clear what part nxssh actually plays in making this proxy connection on the client side (as opposed to nxclient; in other words, even if my NX server connected to proxy port right away on the server, would this do any good?) Perhaps someone could point me to a more detailed explanation of the protocol? Also, I remember someone suggested to simply use VNC. Is there a good way to run VNC so that I can connect to my actual NX session via VNC? I am sorry I am new at this... but willing to learn :) Thank you Thank you Misha From gorhas at gmail.com Sun Apr 25 04:47:44 2010 From: gorhas at gmail.com (Goran Hasse) Date: Sat, 24 Apr 2010 20:47:44 +0200 Subject: Update on "non-dying" nx connections over unreliable network In-Reply-To: <4BD30A17.2090107@gmail.com> References: <4BD30A17.2090107@gmail.com> Message-ID: A little note. TCP was constructed to coop with unreliable networks. ;-) In the past if every link dropt between you and your peer and then came back agin. The connection still was there. So in my opinion your nxclient is doing the right thing. How should it know that your wireless link has gone away? Who should send "client gone". In the old days an FTP transfer could handle about an hour of lost link and then resume. But this was in the old days. 2010/4/24 Misha Koshelev : > Dear Sirs & Madams: > > Thank you so much for your help. To remind, my situation is a wireless connection that is unreliable, where: > (a) upon disconnect, !M's nxclient does not recognize connection death > (b) after I manually kill nxssh and reconnect, reconnection takes some time. > > My idea: > intercept myself in between NX client and server - detect connection drop, and reconnect. This is proving quite difficult. > > My prototype is here. For now, I have dropped all encryption. > > http://people.hnl.bcm.edu/misha/tmp/nx.zip > > You will find: > nx/comps - compiles server (setuid root currently) > nx/compc - compiles client (moves old one to mxssh and replaces) > > Host name and port are hardcoded at the moment. To test: > > ssh server > cd nx > ./server > > Then connect on the client using !M's client. > > Unfortunately, I seem to have ended up with a glorified way of peeking at the NX authentication connection (please see included logs in > ZIP file, password is masked). > > I am guessing at this point, the proxy connection is probably launched. However, I am not quite clear what part nxssh actually plays in making this proxy connection on the client side (as opposed to nxclient; in other words, even if my NX server connected to proxy port right away on the server, would this do any good?) Perhaps someone could point me to a more detailed explanation of the protocol? > > Also, I remember someone suggested to simply use VNC. Is there a good way to run VNC so that I can connect to my actual NX session via VNC? I am sorry I am new at this... but willing to learn :) > > Thank you > > Thank you > Misha > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- gorhas at gmail.com Mob: 070-5530148 From mcc21371 at gmail.com Sun Apr 25 05:14:39 2010 From: mcc21371 at gmail.com (mark clarkson) Date: Sat, 24 Apr 2010 12:14:39 -0700 Subject: siham oukili Message-ID: http://vgassociates.org/default/index.php From adrya1984 at gmail.com Mon Apr 26 17:28:18 2010 From: adrya1984 at gmail.com (Adriana Rodean) Date: Mon, 26 Apr 2010 10:28:18 +0300 Subject: allow multiple users Message-ID: Hi, I have user A that connects to ssh successfully through public key authentication. I created on server user B, but ssh doesn't allow user B to connect through PKI. Both users use the same key to connect, for user A works, for user B doesn't. Here is the fail message: "trying public key file /home/A/glassfish/domains/domain1/config/authorized_keys debug1: fd 4 clearing O_NONBLOCK Authentication refused: bad ownership or modes for file /home/A/glassfish/domains/domain1/config/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1008/1000 (e=0/0) debug1: trying public key file /home/A/glassfish/domains/domain1/config/authorized_keys debug1: fd 4 clearing O_NONBLOCK Authentication refused: bad ownership or modes for file /home/A/glassfish/domains/domain1/config/authorized_keys " The access rights to authorized_keys are 755, owner A group A. User B is also in group A, so theoretically should work. I guess the access rights are wrong or owner... So what access rights / owner should have authorized_keys so both users can connect? Hope someone can help me :) Thanks, Adriana From eitanadlerlist at gmail.com Mon Apr 26 18:43:22 2010 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Mon, 26 Apr 2010 11:43:22 +0300 Subject: allow multiple users In-Reply-To: References: Message-ID: > Authentication refused: bad ownership or modes for file > /home/A/glassfish/domains/domain1/config/authorized_keys This tells you the problem. Every single folder in that path must not have world or group write permission. From eitanadlerlist at gmail.com Mon Apr 26 18:44:33 2010 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Mon, 26 Apr 2010 11:44:33 +0300 Subject: allow multiple users In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 11:43 AM, Eitan Adler wrote: >> Authentication refused: bad ownership or modes for file >> /home/A/glassfish/domains/domain1/config/authorized_keys > This tells you the problem. > Every single folder in that path must not have world or group write permission. > and the file must be owned by the user trying to connect.... From adrya1984 at gmail.com Mon Apr 26 21:34:48 2010 From: adrya1984 at gmail.com (Adriana Rodean) Date: Mon, 26 Apr 2010 14:34:48 +0300 Subject: allow multiple users In-Reply-To: References: Message-ID: Thanks :) How should i configure openssh server in order for multiple users to connect to it? And user A to be able to write in user B authorized_keys file? Right now i have this option in sshd_config: AuthorizedKeysFile: /home/A/glassfish/domains/domain1/config/authorized_keys On Mon, Apr 26, 2010 at 11:44, Eitan Adler wrote: > On Mon, Apr 26, 2010 at 11:43 AM, Eitan Adler wrote: >>> Authentication refused: bad ownership or modes for file >>> /home/A/glassfish/domains/domain1/config/authorized_keys >> This tells you the problem. >> Every single folder in that path must not have world or group write permission. >> > and the file must be owned by the user trying to connect.... > From eitanadlerlist at gmail.com Mon Apr 26 22:26:23 2010 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Mon, 26 Apr 2010 15:26:23 +0300 Subject: allow multiple users In-Reply-To: References: Message-ID: On Mon, Apr 26, 2010 at 2:34 PM, Adriana Rodean wrote: > Thanks :) > > How should i configure openssh server in order for multiple users to > connect to it? Multiple users *can* connect ;). If you want multiple users to use the same key you need to copy the key to each users authorized_key file. > > And user A to be able to write in user B authorized_keys file? This is the exact scenario the "invalid permissions" error is trying to prevent. One way for you to allow user A to write to user B's files without changing B's permissions to write a setuid program which will only let you add/change/delete a key in authorized_keys. Another option is to add "StrictModes no" to sshd_config. > > Right now i have this option in sshd_config: > AuthorizedKeysFile: /home/A/glassfish/domains/domain1/config/authorized_keys > From chris at qwirx.com Mon Apr 26 22:32:34 2010 From: chris at qwirx.com (Chris Wilson) Date: Mon, 26 Apr 2010 14:32:34 +0200 (CEST) Subject: allow multiple users In-Reply-To: References: Message-ID: Hi all, On Mon, 26 Apr 2010, Eitan Adler wrote: > On Mon, Apr 26, 2010 at 2:34 PM, Adriana Rodean wrote: >> And user A to be able to write in user B authorized_keys file? > > This is the exact scenario the "invalid permissions" error is trying to > prevent. One way for you to allow user A to write to user B's files > without changing B's permissions to write a setuid program which will > only let you add/change/delete a key in authorized_keys. > > Another option is to add "StrictModes no" to sshd_config. > >> Right now i have this option in sshd_config: >> AuthorizedKeysFile: /home/A/glassfish/domains/domain1/config/authorized_keys Another option is to have the authorized_keys file, and all its parent directories, owned by root, and not writable by anyone else. E.g. put it into /etc/ssh/domains/domain1/config/authorized_keys. If user B really needs to write to user A's keys file, they could use sudo to do so. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From jf114b at att.com Tue Apr 27 00:41:29 2010 From: jf114b at att.com (FELLIN, JEFF (ATTSI)) Date: Mon, 26 Apr 2010 10:41:29 -0400 Subject: openbsd-compat regression tests Message-ID: The snprintftest.c regression test in openbsd-compat/regress has a buffer overflow error, and an argument error in the calls to snprintf(), and vsnprintf(). On line 49 of snprintftest.c, the character buffer, b, is allocated at 5 bytes. However, in the calls to snprintf and vsnprintf, on lines 68 and 77 respectively, it is expected to place 11 bytes of data into the buffer. Which will result in buffer overflow. The second error is in the arguments to snprintf and vsnprintf in the size argument to those functions. The size value is 1, indicating the buffer is only 1 btye in length, this is according to the Open Group specification of snprintf, and vsnprintf. Hence the test for the return value being 11 should always fail. Which it did on my system, Linux 2.6.18-164.15.1.el5 GNU/Linux X86_64. Jeff Fellin AT&T Labs From jf114b at att.com Tue Apr 27 02:14:31 2010 From: jf114b at att.com (FELLIN, JEFF (ATTSI)) Date: Mon, 26 Apr 2010 12:14:31 -0400 Subject: openbsd-compat regression tests Message-ID: Sorry for my mistake I read the wrong lines in the Open Group spec for the behavior of snprintf and vsnprintf. I had read the lines for sprint and vsprintf. Please accept my apologies for this mistake. Sincerely, Jeff Fellin AT&T Labs From peter at stuge.se Tue Apr 27 02:36:03 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 26 Apr 2010 18:36:03 +0200 Subject: openbsd-compat regression tests In-Reply-To: References: Message-ID: <20100426163603.5754.qmail@stuge.se> Hi Jeff, FELLIN, JEFF (ATTSI) wrote: > The snprintftest.c regression test in openbsd-compat/regress has a > buffer overflow error, and an argument error in the calls to snprintf(), > and vsnprintf(). Thanks for the bug report. Did you already fix these issues? Could you send a patch against the current source code? //Peter From adrya1984 at gmail.com Tue Apr 27 19:10:38 2010 From: adrya1984 at gmail.com (Adriana Rodean) Date: Tue, 27 Apr 2010 12:10:38 +0300 Subject: allow multiple users In-Reply-To: References: Message-ID: Thanks a lot :) StrictModes no did the trick ;) On Mon, Apr 26, 2010 at 15:26, Eitan Adler wrote: > On Mon, Apr 26, 2010 at 2:34 PM, Adriana Rodean wrote: >> Thanks :) >> >> How should i configure openssh server in order for multiple users to >> connect to it? > > Multiple users *can* connect ;). If you want multiple users to use the > same key you need to copy the key to each users authorized_key file. > >> >> And user A to be able to write in user B authorized_keys file? > This is the exact scenario the "invalid permissions" error is trying > to prevent. One way for you to allow user A to write to user B's files > without changing B's permissions to write a setuid program which will > only let you add/change/delete a key in authorized_keys. > > Another option is to add "StrictModes no" to sshd_config. > >> >> Right now i have this option in sshd_config: >> AuthorizedKeysFile: /home/A/glassfish/domains/domain1/config/authorized_keys >> > From postbus111 at gmail.com Wed Apr 28 04:49:19 2010 From: postbus111 at gmail.com (Hans) Date: Tue, 27 Apr 2010 20:49:19 +0200 Subject: ssh certificate usage Message-ID: I am trying to find out how I can use the new self-signed certificates So what I read in the man pages, it should be something like: client: 1) ssh-keygen -f ca_rsa # generate a ssh keypair for use as a certificate Server(s): 2) make sure your /etc/ssh/sshd_config has TrustedUserCAKeys assigned TrustedUserCAKeys /etc/ssh/sshcakeys # or whatever name or location you like 3) edit /etc/ssh/sshcakeys and add the contents of ca_rsa.pub in it Client: 4) for a user generate a certificate of its public key ssh-keygen -s ca_rsa -I keyid -n user id_rsa.pub This will generate an id_rsa-cert.pub certificate file Client: 5) ssh user at server # connect to server using the certificate Is this correct or did I miss something ? Is it also possible to disable the plain public key authentication and only accept certificate authentication (can't find an option for this in sshd_config) thx Hans From imorgan at nas.nasa.gov Wed Apr 28 07:51:34 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 27 Apr 2010 14:51:34 -0700 Subject: ssh certificate usage In-Reply-To: References: Message-ID: <20100427215134.GB32290@linux55.nas.nasa.gov> On Tue, Apr 27, 2010 at 13:49:19 -0500, Hans wrote: > I am trying to find out how I can use the new self-signed certificates > So what I read in the man pages, it should be something like: > > client: > 1) ssh-keygen -f ca_rsa # generate a ssh keypair for use as a certificate > > Server(s): > 2) make sure your /etc/ssh/sshd_config has TrustedUserCAKeys assigned > TrustedUserCAKeys /etc/ssh/sshcakeys # or whatever name or > location you like TrustedUserCAKeys is really intended for specifying system-wide CA keys such as you would use if your organization were generating certs for users. For user-generated certs, you would simply add the appropriate entry to the user's ~/.ssh/authorized_keys file on the servers. Note that using TrustedUserCAKeys also impacts how the user certificate is generated. If you use TrustedUserCAKeys, the certificates MUST have a principal specified. > > 3) edit /etc/ssh/sshcakeys and add the contents of ca_rsa.pub in it > > Client: > 4) for a user generate a certificate of its public key > ssh-keygen -s ca_rsa -I keyid -n user id_rsa.pub > This will generate an id_rsa-cert.pub certificate file > > Client: > 5) ssh user at server # connect to server using the certificate > > Is this correct or did I miss something ? Other than the comment above regarding the use of TrustedUserCAKeys, this looks reasonable. Note that with user-generated certs, the CA should really be listed in the user's ~/.ssh/authorized_keys file and should have the 'cert-authority' tag. > > Is it also possible to disable the plain public key authentication and > only accept certificate authentication (can't find an option for this > in sshd_config) Since certificate-based authentication is really just an extension to classic public-key authentication, you can't turn off public-key auth without also turning off certificate support. However, if you are using a centralized CA (and thus TrustedUserCAKeys), you could effectively disable classic pubkey auth by specifying a different path for the authorized_keys file, i.e.: AuthorizedKeysFile /dev/null or AuthorizedKeysFile /etc/ssh/authorized_keys/%u The latter would make it possible to have exceptions to the general case. > > thx > > Hans > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From djm at mindrot.org Wed Apr 28 14:34:46 2010 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Apr 2010 14:34:46 +1000 (EST) Subject: openbsd-compat regression tests In-Reply-To: <20100426163603.5754.qmail@stuge.se> References: <20100426163603.5754.qmail@stuge.se> Message-ID: On Mon, 26 Apr 2010, Peter Stuge wrote: > Hi Jeff, > > FELLIN, JEFF (ATTSI) wrote: > > The snprintftest.c regression test in openbsd-compat/regress has a > > buffer overflow error, and an argument error in the calls to snprintf(), > > and vsnprintf(). > > Thanks for the bug report. Did you already fix these issues? Could > you send a patch against the current source code? No, as Jeff has no doubt already realised, snprintf should return the size of the string that it would have created had the supplied buffer been large enough. This allows the caller to reliably check for truncation by comparing the return value to the supplied length (one still needs to check for a -1 return, which can happen in some obscure cases). -d From djm at mindrot.org Wed Apr 28 14:41:30 2010 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Apr 2010 14:41:30 +1000 (EST) Subject: ssh certificate usage In-Reply-To: References: Message-ID: On Tue, 27 Apr 2010, Hans wrote: > I am trying to find out how I can use the new self-signed certificates > So what I read in the man pages, it should be something like: > > client: > 1) ssh-keygen -f ca_rsa # generate a ssh keypair for use as a certificate > > Server(s): > 2) make sure your /etc/ssh/sshd_config has TrustedUserCAKeys assigned > TrustedUserCAKeys /etc/ssh/sshcakeys # or whatever name or > location you like > > 3) edit /etc/ssh/sshcakeys and add the contents of ca_rsa.pub in it > > Client: > 4) for a user generate a certificate of its public key > ssh-keygen -s ca_rsa -I keyid -n user id_rsa.pub > This will generate an id_rsa-cert.pub certificate file > > Client: > 5) ssh user at server # connect to server using the certificate > > Is this correct or did I miss something ? That is it in a nutshell. You should specify a validity period for the certificates in step #3. Since our revocation implementation is weak at the moment, it is best to use short-lived certificates that are refreshed frequently (and hopefully through an easy process for the user). Also, if you want to try out certificates without touching sshd_config (e.g. if you don't have superuser access), then you can specify trusted CA keys on a per-user basis in authorized_keys using the "cert-authority" key option: cert-authority ssh-rsa AAA..... > Is it also possible to disable the plain public key authentication and > only accept certificate authentication (can't find an option for this > in sshd_config) You can set AuthorizedKeysFile to /dev/null, so sshd will never find any regular keys there. This can be done on a per-user/group/address basis using the Match keyword. As you are probably aware, the certificate support is very new and I'd love to hear any feedback or criticism you may have. -d From peter at stuge.se Wed Apr 28 16:28:39 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 28 Apr 2010 08:28:39 +0200 Subject: openbsd-compat regression tests In-Reply-To: References: <20100426163603.5754.qmail@stuge.se> Message-ID: <20100428062839.27920.qmail@stuge.se> Damien Miller wrote: > > > The snprintftest.c regression test in openbsd-compat/regress > > > has a buffer overflow error, and an argument error in the calls > > > to snprintf(), and vsnprintf(). > > > > Thanks for the bug report. Did you already fix these issues? > > Could you send a patch against the current source code? > > No, as Jeff has no doubt already realised, snprintf should return > the size of the string that it would have created had the supplied > buffer been large enough. Nod, I've even used it before. Too quick review there. :\ Thanks! //Peter From postbus111 at gmail.com Wed Apr 28 17:35:12 2010 From: postbus111 at gmail.com (Hans) Date: Wed, 28 Apr 2010 09:35:12 +0200 Subject: ssh certificate usage In-Reply-To: References: Message-ID: >> Is this correct or did I miss something ? > > That is it in a nutshell. You should specify a validity period for the > certificates in step #3. Since our revocation implementation is weak at > the moment, it is best to use short-lived certificates that are refreshed > frequently Yes, I kept the example as simple as possiible without any of the other possible restrictions. > (and hopefully through an easy process for the user). that will be a challenge... But the advantage for using certificates is that you can add restrictions to them and even better you don't have to distribute the public keys to the correct system for each user. Only the ca puiblic key should be once put in the TrustedUserCAKeys file > You can set AuthorizedKeysFile to /dev/null, so sshd will never find > any regular keys there. This can be done on a per-user/group/address > basis using the Match keyword. That is the one I missed, otherwise users could connect once using the certificate, put there plain public key in the .ssh/authorized_keys2 and remove their cert pub key and make connections without the restrictions. So it looks mandatory to me if you use TrustedUserCAKeys to disable also AuthorizedKeysFile for the selected users or groups. > As you are probably aware, the certificate support is very new and I'd > love to hear any feedback or criticism you may have. Until so far I like it :) Have to check still the possible restrictions and how the ssh-agent is handling the cert pub keys Hans From djm at mindrot.org Wed Apr 28 18:40:42 2010 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Apr 2010 18:40:42 +1000 (EST) Subject: ssh certificate usage In-Reply-To: References: Message-ID: On Wed, 28 Apr 2010, Hans wrote: > > You can set AuthorizedKeysFile to /dev/null, so sshd will never find > > any regular keys there. This can be done on a per-user/group/address > > basis using the Match keyword. > > That is the one I missed, otherwise users could connect once using the > certificate, > put there plain public key in the .ssh/authorized_keys2 and remove > their cert pub key and make connections without the restrictions. oops, it seems I'm mistaken about selecting AuthorizedKeysFile through Match - it isn't supported. I just filed https://bugzilla.mindrot.org/show_bug.cgi?id=1764 to add it. > > As you are probably aware, the certificate support is very new and I'd > > love to hear any feedback or criticism you may have. > > Until so far I like it :) > Have to check still the possible restrictions and how the ssh-agent is > handling the cert pub keys ssh-agent should accept add requests for certified keys and should sign them correctly. Certified keys should be added automatically by ssh-add if they are named XXX-cert.pub to a corresponding private key file. This is essentially the same way that ssh(1) uses them. -d From postbus111 at gmail.com Wed Apr 28 20:29:22 2010 From: postbus111 at gmail.com (Hans Harder) Date: Wed, 28 Apr 2010 12:29:22 +0200 Subject: ssh certificate usage In-Reply-To: References: Message-ID: > > oops, it seems I'm mistaken about selecting AuthorizedKeysFile through > Match - it isn't supported. I just filed > https://bugzilla.mindrot.org/show_bug.cgi?id=1764 to add it. > Thx The principals now only support user and host (or a list of) Is it possible that the principal can also be used for a user group Hans From djm at mindrot.org Thu Apr 29 08:32:05 2010 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Apr 2010 08:32:05 +1000 (EST) Subject: ssh certificate usage In-Reply-To: References: Message-ID: On Wed, 28 Apr 2010, Hans Harder wrote: > > > > oops, it seems I'm mistaken about selecting AuthorizedKeysFile through > > Match - it isn't supported. I just filed > > https://bugzilla.mindrot.org/show_bug.cgi?id=1764 to add it. > > The principals now only support user and host (or a list of) > Is it possible that the principal can also be used for a user group How would you invisage that would work? -d From postbus111 at gmail.com Thu Apr 29 17:46:26 2010 From: postbus111 at gmail.com (Hans Harder) Date: Thu, 29 Apr 2010 09:46:26 +0200 Subject: ssh certificate usage In-Reply-To: References: Message-ID: >> The principals now only support user and host (or a list of) >> Is it possible that the principal can also be used for a user group > > How would you invisage that would work? Same as the match group in sshd_config That way I can assign the users to a special group which uses certificates only In the sshd_config I then can use the match group to deny kbinteractive and set the AuthorizedKeysFile to null with one line. Otherwise I will keep on changing the sshd_config and need to add new certificates in the TrustedUserCAKeys file on all the systems for new people. I want to do as less changes to the sshd configuration Hans From karim.belem at safenet-inc.com Fri Apr 30 04:55:08 2010 From: karim.belem at safenet-inc.com (Belem,Karim) Date: Thu, 29 Apr 2010 14:55:08 -0400 Subject: OpenSSH 5.4p1- scp sending extra "--" Message-ID: <4116A6E0AAD1D34F947F76AB6883695D023B66B260@BEL1EXCH02.amer.sfnt.local> Hi, I found that in older versions of OpenSSH up to 5.3 when I type "scp @: ." internally the command sent to the is scp -f but with OpenSSH 5.4 the internal command is now scp -f -- . I believe the same thing was propagated to OpenSSH 5.5 since the same thing was seen with it. The problem is that the server side does not understand the new "--" before the filename. Is there a workaround or a fix to avoid the "--" to be sent internally? Thanks, Karim The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. From philipp_subx at redfish-solutions.com Fri Apr 30 11:48:56 2010 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 29 Apr 2010 19:48:56 -0600 Subject: QoS marking for Openssh (review wanted) In-Reply-To: <4BAA5DD3.6020004@redfish-solutions.com> References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> Message-ID: <4BDA3708.1040307@redfish-solutions.com> On 3/24/10 12:45 PM, Philip A. Prindeville wrote: > Anyone want to code review: > > https://bugzilla.mindrot.org/show_bug.cgi?id=1733 > > There's a patch attached. We're currently using it on astlinux. > > Thanks. > Still looking to get a code-review and approval. Thanks. From djm at mindrot.org Fri Apr 30 12:03:43 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Apr 2010 12:03:43 +1000 (EST) Subject: QoS marking for Openssh (review wanted) In-Reply-To: <4BDA3708.1040307@redfish-solutions.com> References: <4B931780.9010200@employees.org> <4B96EB48.3030204@employees.org> <4B96F506.7060106@employees.org> <4BAA5DD3.6020004@redfish-solutions.com> <4BDA3708.1040307@redfish-solutions.com> Message-ID: we'll get to it - please be patient. On Thu, 29 Apr 2010, Philip Prindeville wrote: > On 3/24/10 12:45 PM, Philip A. Prindeville wrote: > > Anyone want to code review: > > > > https://bugzilla.mindrot.org/show_bug.cgi?id=1733 > > > > There's a patch attached. We're currently using it on astlinux. > > > > Thanks. > > > > Still looking to get a code-review and approval. > > Thanks. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >