From wfdawson at bellsouth.net Thu Nov 3 17:50:46 2011 From: wfdawson at bellsouth.net (wfdawson) Date: Wed, 2 Nov 2011 23:50:46 -0700 (PDT) Subject: Help with CA Certificates for user authentication? Message-ID: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> As background, I read: http://therowes.net/~greg/2011/03/23/ssh-trusted-ca-key/ http://www.ibm.com/developerworks/aix/library/au-sshsecurity/ http://bryanhinton.com/blog/openssh-security http://www.linuxhowtos.org/manpages/5/sshd_config.htm http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=4164814&prodTypeId=18964&objectID=c02838205 http://www.gossamer-threads.com/lists/openssh/users/50165 I'm to use SSH CA certificate for user authentication, but not getting quite "there." I created a signing cert and used it to sign the test user's public key: ssh-keygen -s /etc/ssh/ca_rsa -I test -n test at 172.31.43.3 -z 3 /home/test/.ssh/id_rsa.pub On my test server, the sshd_config details: Port 2022 HostKey /etc/sshtest/ssh_host_key HostKey /etc/sshtest/ssh_host_rsa_key HostKey /etc/sshtest/ssh_host_dsa_key HostKey /etc/sshtest/ssh_host_ecdsa_key MaxAuthTries 3 AuthorizedKeysFile????? /etc/sshtest/authorized_keys PasswordAuthentication no X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes UseDNS no Subsystem?????? sftp??? /home1/test/usr/local/libexec/sftp-server TrustedUserCAKeys?????? /etc/sshtest/ssh_cakeys AuthorizedPrincipalsFile??????? /etc/sshtest/authorized_principals The /etc/sshtest/authorized_principals file contains one line: test at 172.31.43.3 I attempt to connect to the target server from the test client: $ ssh -vvv -Y -p 2022 -l test 172.31.44.115 There is verbose output, which mostly seems right until (on the client): debug1: ssh_rsa_verify: signature correct debug2: input_userauth_pk_ok: fp c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab debug3: sign_and_send_pubkey: RSA-CERT c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab debug1: read PEM private key begin debug1: key_parse_private_pem: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/home/test/.ssh/id_rsa': ...and, correspondingly on the server: debug1: KEX done debug1: userauth-request for user test service ssh-connection method none debug1: attempt 0 failures 0 debug1: userauth-request for user test service ssh-connection method publickey debug1: attempt 1 failures 0 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 63203/54000 (e=0/0) debug1: trying public key file /etc/sshtest/authorized_keys debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 63203/54000 (e=0/0) debug1: trying public key file /etc/sshtest/authorized_keys debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 Failed publickey for test from 172.31.43.3 port 2991 ssh2 debug1: userauth-request for user test service ssh-connection method publickey debug1: attempt 2 failures 1 debug1: ssh_rsa_verify: signature correct debug1: test whether pkalg/pkblob are acceptable debug1: ssh_rsa_verify: signature correct debug1: temporarily_use_uid: 63203/54000 (e=0/0) debug1: trying authorized principals file /etc/sshtest/authorized_principals debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 Certificate does not contain an authorized principal debug1: temporarily_use_uid: 63203/54000 (e=0/0) debug1: trying public key file /etc/sshtest/authorized_keys debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 63203/54000 (e=0/0) debug1: trying public key file /etc/sshtest/authorized_keys debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 Failed publickey for test from 172.31.43.3 port 2991 ssh2 debug1: userauth-request for user test service ssh-connection method publickey debug1: attempt 3 failures 2 debug1: ssh_rsa_verify: signature correct debug1: test whether pkalg/pkblob are acceptable debug1: ssh_rsa_verify: signature correct debug1: temporarily_use_uid: 63203/54000 (e=0/0) debug1: trying authorized principals file /etc/sshtest/authorized_principals debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 Accepted certificate ID "test" signed by RSA CA e5:04:98:2c:95:d3:b2:21:01:f3:5c:16:63:99:67:db via /etc/sshtest/ssh_cakeys Postponed publickey for test from 172.31.43.3 port 2991 ssh2 At this point, I have to enter the test user's passphrase.? This is not what I expect... I was rather hoping to avoid entering credentials... Any suggestions? From imorgan at nas.nasa.gov Fri Nov 4 04:35:58 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 3 Nov 2011 10:35:58 -0700 Subject: Help with CA Certificates for user authentication? In-Reply-To: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> References: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> Message-ID: <20111103173558.GA5573@linux124.nas.nasa.gov> Hello, What happens if you set the principal in the certificate to simply be the username of the test account? I suspect that you have a permissions issue with your authorized_principals file. Remember that it is read using the user's permissions and thus must be readable by the user. -- Iain Morgan On Thu, Nov 03, 2011 at 01:50:46 -0500, wfdawson wrote: > As background, I read: > > http://therowes.net/~greg/2011/03/23/ssh-trusted-ca-key/ > http://www.ibm.com/developerworks/aix/library/au-sshsecurity/ > http://bryanhinton.com/blog/openssh-security > http://www.linuxhowtos.org/manpages/5/sshd_config.htm > http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=4164814&prodTypeId=18964&objectID=c02838205 > http://www.gossamer-threads.com/lists/openssh/users/50165 > > > I'm to use SSH CA certificate for user authentication, but not getting quite "there." > > I created a signing cert and used it to sign the test user's public key: > > ssh-keygen -s /etc/ssh/ca_rsa -I test -n test at 172.31.43.3 -z 3 /home/test/.ssh/id_rsa.pub > > On my test server, the sshd_config details: > > Port 2022 > HostKey /etc/sshtest/ssh_host_key > HostKey /etc/sshtest/ssh_host_rsa_key > HostKey /etc/sshtest/ssh_host_dsa_key > HostKey /etc/sshtest/ssh_host_ecdsa_key > MaxAuthTries 3 > AuthorizedKeysFile????? /etc/sshtest/authorized_keys > PasswordAuthentication no > X11Forwarding yes > X11DisplayOffset 10 > X11UseLocalhost yes > UseDNS no > Subsystem?????? sftp??? /home1/test/usr/local/libexec/sftp-server > TrustedUserCAKeys?????? /etc/sshtest/ssh_cakeys > AuthorizedPrincipalsFile??????? /etc/sshtest/authorized_principals > > The /etc/sshtest/authorized_principals file contains one line: > > test at 172.31.43.3 > > I attempt to connect to the target server from the test client: > > $ ssh -vvv -Y -p 2022 -l test 172.31.44.115 > > > There is verbose output, which mostly seems right until (on the client): > > > debug1: ssh_rsa_verify: signature correct > debug2: input_userauth_pk_ok: fp c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab > debug3: sign_and_send_pubkey: RSA-CERT c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab > debug1: read PEM private key begin > debug1: key_parse_private_pem: PEM_read_PrivateKey failed > debug1: read PEM private key done: type > Enter passphrase for key '/home/test/.ssh/id_rsa': > > ...and, correspondingly on the server: > > debug1: KEX done > debug1: userauth-request for user test service ssh-connection method none > debug1: attempt 0 failures 0 > debug1: userauth-request for user test service ssh-connection method publickey > debug1: attempt 1 failures 0 > debug1: test whether pkalg/pkblob are acceptable > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Failed publickey for test from 172.31.43.3 port 2991 ssh2 > debug1: userauth-request for user test service ssh-connection method publickey > debug1: attempt 2 failures 1 > debug1: ssh_rsa_verify: signature correct > debug1: test whether pkalg/pkblob are acceptable > debug1: ssh_rsa_verify: signature correct > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying authorized principals file /etc/sshtest/authorized_principals > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Certificate does not contain an authorized principal > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Failed publickey for test from 172.31.43.3 port 2991 ssh2 > debug1: userauth-request for user test service ssh-connection method publickey > debug1: attempt 3 failures 2 > debug1: ssh_rsa_verify: signature correct > debug1: test whether pkalg/pkblob are acceptable > debug1: ssh_rsa_verify: signature correct > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying authorized principals file /etc/sshtest/authorized_principals > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Accepted certificate ID "test" signed by RSA CA e5:04:98:2c:95:d3:b2:21:01:f3:5c:16:63:99:67:db via /etc/sshtest/ssh_cakeys > Postponed publickey for test from 172.31.43.3 port 2991 ssh2 > > At this point, I have to enter the test user's passphrase.? This is not what I expect... I was rather hoping to avoid entering credentials... > > > Any suggestions? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From wfdawson at bellsouth.net Fri Nov 4 14:00:52 2011 From: wfdawson at bellsouth.net (wfdawson) Date: Thu, 3 Nov 2011 20:00:52 -0700 (PDT) Subject: Help with CA Certificates for user authentication? In-Reply-To: <20111103173558.GA5573@linux124.nas.nasa.gov> References: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> <20111103173558.GA5573@linux124.nas.nasa.gov> Message-ID: <1320375652.58886.YahooMailNeo@web181206.mail.ne1.yahoo.com> Hi, Thanks for your feedback. I tried setting the principal in the cert to be simply the username of the test account.? I also set the AuthorizedPrincipalsFile to point to the users' .ssh/authorized_principals rather than a system-wide file, and confirmed the file permissions on the test user's .ssh/authorized_principals file.? Still, no success. I found the instructions here on authenticating ssh server host key to be helpful: http://justanothergeek.chdir.org/2011/07/howto-authenticate-ssh-server-through.html Here's a link to some notes about my testing.? I would be most happy if anyone would give some advice after viewing it.? I appreciate, it is not an easy read. http://pastebin.com/91tV8Pii An interesting tidbit from the server session: Authentication tried for test with correct key but not from a permitted host (host=172.31.43.3, ip=172.31.43.3). I found someone else with this issue (or similar): https://bugzilla.redhat.com/show_bug.cgi?id=666977 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607602 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607369 Though that seems important, I'm able to get past it.? If I make ~test/.ssh/authorized_principals simple so that it contains a single line consisting simple of: test ... corresponding to the actual principal in the user's certificate signature, the result is cleaner, but still not successful in authenticating the test user with only the CA cert signed public signature file: debug1: trying authorized principals file /home1/test/.ssh/authorized_principals debug1: fd 5 clearing O_NONBLOCK debug1: restore_uid: 0/0 Accepted certificate ID "test" signed by RSA CA e5:04:98:2c:95:d3:b2:21:01:f3:5c:16:63:99:67:db via /etc/sshtest/ssh_cakeys Postponed publickey for test from 172.31.43.3 port 1866 ssh2 At that point, the user is presented with a prompt to provide his private key passphrase: debug3: key_from_blob(..., ...) ktype=ssh-rsa debug1: ssh_rsa_verify: signature correct debug2: input_userauth_pk_ok: fp 25:cb:6b:60:d6:19:ff:ac:8d:62:21:fa:c0:96:bc:0f debug3: sign_and_send_pubkey: RSA-CERT 25:cb:6b:60:d6:19:ff:ac:8d:62:21:fa:c0:96:bc:0f debug1: read PEM private key begin debug1: key_parse_private_pem: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/home/test/.ssh/id_rsa': So, I'm stuck here... :-( ... as my goal is to authenticate the user without his needing to enter his private key passphrase. I'm beginning to believe I have misread or misunderstood the functionality that I thought was here...? is this possible (to authenticate based on the user's public key having been signed by a trusted CA, or must the user also provide his private key passphrase just as was the case before OpenSSH CA Certificates? ________________________________ From: Iain Morgan To: wfdawson Cc: "openssh-unix-dev at mindrot.org" Sent: Thursday, November 3, 2011 1:35 PM Subject: Re: Help with CA Certificates for user authentication? Hello, What happens if you set the principal in the certificate to simply be the username of the test account? I suspect that you have a permissions issue with your authorized_principals file. Remember that it is read using the user's permissions and thus must be readable by the user. -- Iain Morgan On Thu, Nov 03, 2011 at 01:50:46 -0500, wfdawson wrote: > As background, I read: > > http://therowes.net/~greg/2011/03/23/ssh-trusted-ca-key/ > http://www.ibm.com/developerworks/aix/library/au-sshsecurity/ > http://bryanhinton.com/blog/openssh-security > http://www.linuxhowtos.org/manpages/5/sshd_config.htm > http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=4164814&prodTypeId=18964&objectID=c02838205 > http://www.gossamer-threads.com/lists/openssh/users/50165 > > > I'm to use SSH CA certificate for user authentication, but not getting quite "there." > > I created a signing cert and used it to sign the test user's public key: > > ssh-keygen -s /etc/ssh/ca_rsa -I test -n test at 172.31.43.3 -z 3 /home/test/.ssh/id_rsa.pub > > On my test server, the sshd_config details: > > Port 2022 > HostKey /etc/sshtest/ssh_host_key > HostKey /etc/sshtest/ssh_host_rsa_key > HostKey /etc/sshtest/ssh_host_dsa_key > HostKey /etc/sshtest/ssh_host_ecdsa_key > MaxAuthTries 3 > AuthorizedKeysFile????? /etc/sshtest/authorized_keys > PasswordAuthentication no > X11Forwarding yes > X11DisplayOffset 10 > X11UseLocalhost yes > UseDNS no > Subsystem?????? sftp??? /home1/test/usr/local/libexec/sftp-server > TrustedUserCAKeys?????? /etc/sshtest/ssh_cakeys > AuthorizedPrincipalsFile??????? /etc/sshtest/authorized_principals > > The /etc/sshtest/authorized_principals file contains one line: > > test at 172.31.43.3 > > I attempt to connect to the target server from the test client: > > $ ssh -vvv -Y -p 2022 -l test 172.31.44.115 > > > There is verbose output, which mostly seems right until (on the client): > > > debug1: ssh_rsa_verify: signature correct > debug2: input_userauth_pk_ok: fp c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab > debug3: sign_and_send_pubkey: RSA-CERT c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab > debug1: read PEM private key begin > debug1: key_parse_private_pem: PEM_read_PrivateKey failed > debug1: read PEM private key done: type > Enter passphrase for key '/home/test/.ssh/id_rsa': > > ...and, correspondingly on the server: > > debug1: KEX done > debug1: userauth-request for user test service ssh-connection method none > debug1: attempt 0 failures 0 > debug1: userauth-request for user test service ssh-connection method publickey > debug1: attempt 1 failures 0 > debug1: test whether pkalg/pkblob are acceptable > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Failed publickey for test from 172.31.43.3 port 2991 ssh2 > debug1: userauth-request for user test service ssh-connection method publickey > debug1: attempt 2 failures 1 > debug1: ssh_rsa_verify: signature correct > debug1: test whether pkalg/pkblob are acceptable > debug1: ssh_rsa_verify: signature correct > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying authorized principals file /etc/sshtest/authorized_principals > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Certificate does not contain an authorized principal > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying public key file /etc/sshtest/authorized_keys > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Failed publickey for test from 172.31.43.3 port 2991 ssh2 > debug1: userauth-request for user test service ssh-connection method publickey > debug1: attempt 3 failures 2 > debug1: ssh_rsa_verify: signature correct > debug1: test whether pkalg/pkblob are acceptable > debug1: ssh_rsa_verify: signature correct > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > debug1: trying authorized principals file /etc/sshtest/authorized_principals > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Accepted certificate ID "test" signed by RSA CA e5:04:98:2c:95:d3:b2:21:01:f3:5c:16:63:99:67:db via /etc/sshtest/ssh_cakeys > Postponed publickey for test from 172.31.43.3 port 2991 ssh2 > > At this point, I have to enter the test user's passphrase.? This is not what I expect... I was rather hoping to avoid entering credentials... > > > Any suggestions? > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From imorgan at nas.nasa.gov Sat Nov 5 03:30:43 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 4 Nov 2011 09:30:43 -0700 Subject: Help with CA Certificates for user authentication? In-Reply-To: <1320375652.58886.YahooMailNeo@web181206.mail.ne1.yahoo.com> References: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> <20111103173558.GA5573@linux124.nas.nasa.gov> <1320375652.58886.YahooMailNeo@web181206.mail.ne1.yahoo.com> Message-ID: <20111104163043.GB5573@linux124.nas.nasa.gov> Using certificates does not bypass the need for a passphrase. For both certificate and public-key authentication, the candidate key or certificate is first presented to the server to see if it will be accepted. If the server is willing to accept the key or cert, you then move on to the stage where an actual signature is required. Note that just as with conventional public-key authentication, you can use ssh-agent to avoid having to enter the passphrase every time. On Thu, Nov 03, 2011 at 22:00:52 -0500, wfdawson wrote: > Hi, > > Thanks for your feedback. > > > I tried setting the principal in the cert to be simply the username of the test account. I also set the AuthorizedPrincipalsFile to point to the users' .ssh/authorized_principals rather than a system-wide file, and confirmed the file permissions on the test user's .ssh/authorized_principals file. Still, no success. > > I found the instructions here on authenticating ssh server host key to be helpful: > > http://justanothergeek.chdir.org/2011/07/howto-authenticate-ssh-server-through.html > > Here's a link to some notes about my testing. I would be most happy if anyone would give some advice after viewing it. I appreciate, it is not an easy read. > > http://pastebin.com/91tV8Pii > > An interesting tidbit from the server session: > > Authentication tried for test with correct key but not from a permitted host (host=172.31.43.3, ip=172.31.43.3). > > I found someone else with this issue (or similar): > > https://bugzilla.redhat.com/show_bug.cgi?id=666977 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607602 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607369 > > > Though that seems important, I'm able to get past it. If I make ~test/.ssh/authorized_principals simple so that it contains a single line consisting simple of: > > test > > ... corresponding to the actual principal in the user's certificate signature, the result is cleaner, but still not successful in authenticating the test user with only the CA cert signed public signature file: > > debug1: trying authorized principals file /home1/test/.ssh/authorized_principals > debug1: fd 5 clearing O_NONBLOCK > debug1: restore_uid: 0/0 > Accepted certificate ID "test" signed by RSA CA e5:04:98:2c:95:d3:b2:21:01:f3:5c:16:63:99:67:db via /etc/sshtest/ssh_cakeys > Postponed publickey for test from 172.31.43.3 port 1866 ssh2 > > > At that point, the user is presented with a prompt to provide his private key passphrase: > > debug3: key_from_blob(..., ...) ktype=ssh-rsa > debug1: ssh_rsa_verify: signature correct > debug2: input_userauth_pk_ok: fp 25:cb:6b:60:d6:19:ff:ac:8d:62:21:fa:c0:96:bc:0f > debug3: sign_and_send_pubkey: RSA-CERT 25:cb:6b:60:d6:19:ff:ac:8d:62:21:fa:c0:96:bc:0f > debug1: read PEM private key begin > debug1: key_parse_private_pem: PEM_read_PrivateKey failed > debug1: read PEM private key done: type > Enter passphrase for key '/home/test/.ssh/id_rsa': > > > > So, I'm stuck here... :-( ... as my goal is to authenticate the user without his needing to enter his private key passphrase. > > I'm beginning to believe I have misread or misunderstood the functionality that I thought was here... is this possible (to authenticate based on the user's public key having been signed by a trusted CA, or must the user also provide his private key passphrase just as was the case before OpenSSH CA Certificates? > > > > > ________________________________ > From: Iain Morgan > To: wfdawson > Cc: "openssh-unix-dev at mindrot.org" > Sent: Thursday, November 3, 2011 1:35 PM > Subject: Re: Help with CA Certificates for user authentication? > > Hello, > > What happens if you set the principal in the certificate to simply be > the username of the test account? > > I suspect that you have a permissions issue with your > authorized_principals file. Remember that it is read using the user's > permissions and thus must be readable by the user. > > -- > Iain Morgan > > On Thu, Nov 03, 2011 at 01:50:46 -0500, wfdawson wrote: > > As background, I read: > > > > http://therowes.net/~greg/2011/03/23/ssh-trusted-ca-key/ > > http://www.ibm.com/developerworks/aix/library/au-sshsecurity/ > > http://bryanhinton.com/blog/openssh-security > > http://www.linuxhowtos.org/manpages/5/sshd_config.htm > > http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=4164814&prodTypeId=18964&objectID=c02838205 > > http://www.gossamer-threads.com/lists/openssh/users/50165 > > > > > > I'm to use SSH CA certificate for user authentication, but not getting quite "there." > > > > I created a signing cert and used it to sign the test user's public key: > > > > ssh-keygen -s /etc/ssh/ca_rsa -I test -n test at 172.31.43.3 -z 3 /home/test/.ssh/id_rsa.pub > > > > On my test server, the sshd_config details: > > > > Port 2022 > > HostKey /etc/sshtest/ssh_host_key > > HostKey /etc/sshtest/ssh_host_rsa_key > > HostKey /etc/sshtest/ssh_host_dsa_key > > HostKey /etc/sshtest/ssh_host_ecdsa_key > > MaxAuthTries 3 > > AuthorizedKeysFile????? /etc/sshtest/authorized_keys > > PasswordAuthentication no > > X11Forwarding yes > > X11DisplayOffset 10 > > X11UseLocalhost yes > > UseDNS no > > Subsystem?????? sftp??? /home1/test/usr/local/libexec/sftp-server > > TrustedUserCAKeys?????? /etc/sshtest/ssh_cakeys > > AuthorizedPrincipalsFile??????? /etc/sshtest/authorized_principals > > > > The /etc/sshtest/authorized_principals file contains one line: > > > > test at 172.31.43.3 > > > > I attempt to connect to the target server from the test client: > > > > $ ssh -vvv -Y -p 2022 -l test 172.31.44.115 > > > > > > There is verbose output, which mostly seems right until (on the client): > > > > > > debug1: ssh_rsa_verify: signature correct > > debug2: input_userauth_pk_ok: fp c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab > > debug3: sign_and_send_pubkey: RSA-CERT c9:42:44:91:48:04:45:b2:ee:93:12:3f:e5:89:13:ab > > debug1: read PEM private key begin > > debug1: key_parse_private_pem: PEM_read_PrivateKey failed > > debug1: read PEM private key done: type > > Enter passphrase for key '/home/test/.ssh/id_rsa': > > > > ...and, correspondingly on the server: > > > > debug1: KEX done > > debug1: userauth-request for user test service ssh-connection method none > > debug1: attempt 0 failures 0 > > debug1: userauth-request for user test service ssh-connection method publickey > > debug1: attempt 1 failures 0 > > debug1: test whether pkalg/pkblob are acceptable > > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > > debug1: trying public key file /etc/sshtest/authorized_keys > > debug1: fd 5 clearing O_NONBLOCK > > debug1: restore_uid: 0/0 > > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > > debug1: trying public key file /etc/sshtest/authorized_keys > > debug1: fd 5 clearing O_NONBLOCK > > debug1: restore_uid: 0/0 > > Failed publickey for test from 172.31.43.3 port 2991 ssh2 > > debug1: userauth-request for user test service ssh-connection method publickey > > debug1: attempt 2 failures 1 > > debug1: ssh_rsa_verify: signature correct > > debug1: test whether pkalg/pkblob are acceptable > > debug1: ssh_rsa_verify: signature correct > > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > > debug1: trying authorized principals file /etc/sshtest/authorized_principals > > debug1: fd 5 clearing O_NONBLOCK > > debug1: restore_uid: 0/0 > > Certificate does not contain an authorized principal > > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > > debug1: trying public key file /etc/sshtest/authorized_keys > > debug1: fd 5 clearing O_NONBLOCK > > debug1: restore_uid: 0/0 > > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > > debug1: trying public key file /etc/sshtest/authorized_keys > > debug1: fd 5 clearing O_NONBLOCK > > debug1: restore_uid: 0/0 > > Failed publickey for test from 172.31.43.3 port 2991 ssh2 > > debug1: userauth-request for user test service ssh-connection method publickey > > debug1: attempt 3 failures 2 > > debug1: ssh_rsa_verify: signature correct > > debug1: test whether pkalg/pkblob are acceptable > > debug1: ssh_rsa_verify: signature correct > > debug1: temporarily_use_uid: 63203/54000 (e=0/0) > > debug1: trying authorized principals file /etc/sshtest/authorized_principals > > debug1: fd 5 clearing O_NONBLOCK > > debug1: restore_uid: 0/0 > > Accepted certificate ID "test" signed by RSA CA e5:04:98:2c:95:d3:b2:21:01:f3:5c:16:63:99:67:db via /etc/sshtest/ssh_cakeys > > Postponed publickey for test from 172.31.43.3 port 2991 ssh2 > > > > At this point, I have to enter the test user's passphrase.? This is not what I expect... I was rather hoping to avoid entering credentials... > > > > > > Any suggestions? > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > Iain Morgan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From keisial at gmail.com Sat Nov 5 05:25:55 2011 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 04 Nov 2011 19:25:55 +0100 Subject: Help with CA Certificates for user authentication? In-Reply-To: <20111104163043.GB5573@linux124.nas.nasa.gov> References: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> <20111103173558.GA5573@linux124.nas.nasa.gov> <1320375652.58886.YahooMailNeo@web181206.mail.ne1.yahoo.com> <20111104163043.GB5573@linux124.nas.nasa.gov> Message-ID: <4EB42E33.5040100@gmail.com> Iain Morgan wrote: > Using certificates does not bypass the need for a passphrase. For both > certificate and public-key authentication, the candidate key or > certificate is first presented to the server to see if it will be > accepted. If the server is willing to accept the key or cert, you then > move on to the stage where an actual signature is required. > > Note that just as with conventional public-key authentication, you can > use ssh-agent to avoid having to enter the passphrase every time. I guess it should be equally possible to use a passwordless file... From imorgan at nas.nasa.gov Sat Nov 5 08:07:27 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Fri, 4 Nov 2011 14:07:27 -0700 Subject: Help with CA Certificates for user authentication? In-Reply-To: <4EB42E33.5040100@gmail.com> References: <1320303046.8521.YahooMailNeo@web181216.mail.ne1.yahoo.com> <20111103173558.GA5573@linux124.nas.nasa.gov> <1320375652.58886.YahooMailNeo@web181206.mail.ne1.yahoo.com> <20111104163043.GB5573@linux124.nas.nasa.gov> <4EB42E33.5040100@gmail.com> Message-ID: <20111104210727.GC5573@linux124.nas.nasa.gov> Quite true, but that's not something that should be encouraged for general user authentication. Of course, if sufficient restrictions are placed on the cert, it may be a reasonable option. On Fri, Nov 04, 2011 at 13:25:55 -0500, ?ngel Gonz?lez wrote: > Iain Morgan wrote: > > Using certificates does not bypass the need for a passphrase. For both > > certificate and public-key authentication, the candidate key or > > certificate is first presented to the server to see if it will be > > accepted. If the server is willing to accept the key or cert, you then > > move on to the stage where an actual signature is required. > > > > Note that just as with conventional public-key authentication, you can > > use ssh-agent to avoid having to enter the passphrase every time. > > I guess it should be equally possible to use a passwordless file... > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Iain Morgan From wfdawson at bellsouth.net Sat Nov 5 22:42:28 2011 From: wfdawson at bellsouth.net (Willard Dawson) Date: Sat, 5 Nov 2011 07:42:28 -0400 Subject: FW: Help with CA Certificates for user authentication? Message-ID: <000801cc9baf$ff6716f0$fe3544d0$@net> My apologies to the list for inadvertently taking this offline. As info: -----Original Message----- From: Iain Morgan [mailto:Iain.Morgan at nasa.gov] Sent: Friday, November 04, 2011 8:15 PM To: wfdawson at bellsouth.net Subject: Re: Help with CA Certificates for user authentication? On Fri, Nov 04, 2011 at 11:53:25 -0500, wfdawson at bellsouth.net wrote: > > Thanks for the clarification. I started to suspect that I was misreading the intent of sigs for user auth keys as I reread those articles. What got me down the wrong path was my interpretation of the recent "what's new in openssh" slide deck. > > I care about batch mode sftp from unix systems but have to also architect key mgt. Null passphrase private keys are mostly not acceptable in our org, though trusting a key that has been signed by our own CA for auth, even if there is no "user password" applied, would likely get a "pass." > > For us, the compromise position that may be acceptable would be to use openssh CA trust applied to null passphrase user keys, tightened down to allow specific file transfer scripts on the server side. > Right, One of the advantages of using certificates is that the restrictions are assigned at the point where the cert is generated, rather than relying upon the user to put appropriate restrictions in an authorized_keys file. And, you can also limit the lifetime of the cert. > Now that I better understand the auth limitations, I know where to focus this effort. > > Thanks, again. Glad to be of help. -- Iain > > Sent via BlackBerry by AT&T > > -----Original Message----- > From: Iain Morgan > Date: Fri, 4 Nov 2011 09:30:43 > To: wfdawson > Cc: openssh-unix-dev at mindrot.org > Subject: Re: Help with CA Certificates for user authentication? > > Using certificates does not bypass the need for a passphrase. For both > certificate and public-key authentication, the candidate key or > certificate is first presented to the server to see if it will be > accepted. If the server is willing to accept the key or cert, you then > move on to the stage where an actual signature is required. > > Note that just as with conventional public-key authentication, you can > use ssh-agent to avoid having to enter the passphrase every time. From loganaden at gmail.com Mon Nov 7 00:03:36 2011 From: loganaden at gmail.com (Loganaden Velvindron) Date: Sun, 6 Nov 2011 18:03:36 +0500 Subject: PermitOpen none option diff Message-ID: Hi, After reading the previous thread. I decided to give it a try. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543683 Here's the diff (written against openbsd -current): https://bugzilla.mindrot.org/attachment.cgi?id=2104 What I did was filling list of permitted sockets with NULL. When this list is compared against the list of connections, The local port fowardings are rejected. Any idea to improve the diff would be nice :-) -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light ! From linux at razik.name Mon Nov 7 22:28:33 2011 From: linux at razik.name (Lukas Razik) Date: Mon, 7 Nov 2011 11:28:33 +0000 (GMT) Subject: Strange behaviour of ssh Message-ID: <1320665313.15296.YahooMailNeo@web24704.mail.ird.yahoo.com> Hello together! I've Debian 6.0.3 with OpenSSH_5.5p1 and problem with the execution of remote commands via ssh. It seems as if the first command isn't looked up in all "$PATH" dirs. Here normally I should get the version information of mpirun twice but the first one fails: $ ssh cluster2 mpirun --version ; mpirun --version bash: mpirun: command not found mpirun (Open MPI) 1.4.3 Here I should get the place of "mpirun" twice but the first "which" doesn't find an "mpirun" and prints nothing: $ ssh cluster2 which mpirun ; which mpirun /usr/mpi/gcc/openmpi-1.4.3/bin/mpirun The echo command prints the right "$PATH": $ ssh cluster2 echo "$PATH" /usr/mpi/gcc/openmpi-1.4.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games So, does anyone of you have an idea what there could be wrong? And does anyone know which shell scripts are loaded remotely by ssh? Is it .bashrc or .profile or/and another one? Many thanks for any answer! Regards, Lukas From philipp.marek at linbit.com Mon Nov 7 23:28:38 2011 From: philipp.marek at linbit.com (Philipp Marek) Date: Mon, 7 Nov 2011 13:28:38 +0100 Subject: Strange behaviour of ssh In-Reply-To: <1320665313.15296.YahooMailNeo@web24704.mail.ird.yahoo.com> References: <1320665313.15296.YahooMailNeo@web24704.mail.ird.yahoo.com> Message-ID: <201111071328.38772.philipp.marek@linbit.com> Hello Lukas! On Monday 07 November 2011, Lukas Razik wrote: > I've Debian 6.0.3 with OpenSSH_5.5p1 and problem with the execution of > remote commands via ssh. ... > Here normally I should get the version information of mpirun twice but > the first one fails: $ ssh cluster2 mpirun --version ; mpirun --version > bash: mpirun: command not found > mpirun (Open MPI) 1.4.3 > > Here I should get the place of "mpirun" twice but the first "which" > doesn't find an "mpirun" and prints nothing: $ ssh cluster2 which mpirun > ; which mpirun > /usr/mpi/gcc/openmpi-1.4.3/bin/mpirun > > The echo command prints the right "$PATH": > $ ssh cluster2 echo "$PATH" > /usr/mpi/gcc/openmpi-1.4.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/ga > mes:/usr/games > > So, does anyone of you have an idea what there could be wrong? yes. The ";" is parsed by the _local_ shell, ssh only transmits the first part to the remote host - the rest is run locally. And "$PATH" is expanded locally, too - try with '$PATH'. To run multiple commands remotely you could try ssh cluster2 /bin/sh -c 'mpirun ; mpirun ; which mpirun; echo $PATH' Regards, Phil From linux at razik.name Tue Nov 8 00:38:17 2011 From: linux at razik.name (Lukas Razik) Date: Mon, 7 Nov 2011 13:38:17 +0000 (GMT) Subject: Strange behaviour of ssh In-Reply-To: <201111071328.38772.philipp.marek@linbit.com> References: <1320665313.15296.YahooMailNeo@web24704.mail.ird.yahoo.com> <201111071328.38772.philipp.marek@linbit.com> Message-ID: <1320673097.68591.YahooMailNeo@web24712.mail.ird.yahoo.com> Hello Philipp! I see: I've done something strange - not ssh... :-/ Many thanks for the explanation! Regards and have a nice day! Lukas Philipp Marek wrote: >Hello Lukas! > >On Monday 07 November 2011, Lukas Razik wrote: >> I've Debian 6.0.3 with OpenSSH_5.5p1 and problem with the execution of >> remote commands via ssh. >... >> Here normally I should get the version information of mpirun twice but >> the first one fails: $ ssh cluster2 mpirun --version ; mpirun --version >> bash: mpirun: command not found >> mpirun (Open MPI) 1.4.3 >> >> Here I should get the place of "mpirun" twice but the first "which" >> doesn't find an "mpirun" and prints nothing: $ ssh cluster2 which mpirun >> ; which mpirun >> /usr/mpi/gcc/openmpi-1.4.3/bin/mpirun >> >> The echo command prints the right "$PATH": >> $ ssh cluster2 echo "$PATH" >> /usr/mpi/gcc/openmpi-1.4.3/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/ga >> mes:/usr/games >> >> So, does anyone of you have an idea what there could be wrong? >yes. The ";" is parsed by the _local_ shell, ssh only transmits the first >part to the remote host - the rest is run locally. > >And "$PATH" is expanded locally, too - try with '$PATH'. > > >To run multiple commands remotely you could try >? ? ssh cluster2? /bin/sh -c 'mpirun ; mpirun ; which mpirun; echo $PATH' > > >Regards, > >Phil From mike.mackintosh at angrystatic.com Sat Nov 12 03:57:55 2011 From: mike.mackintosh at angrystatic.com (mike.mackintosh at angrystatic.com) Date: Fri, 11 Nov 2011 10:57:55 -0600 Subject: SCP fails to locate remote file: '-- ' Message-ID: <20111111105755.58236tyd6061d89f@angrystatic.com> I am not sure if many people have run into this, but recently working with some non-standard SSH capable devices, Routers, Firewalls and Switches, I noticed SCP failed on many of them. Looking through logs I saw: SCP unable to find file: '-- config' When looking through the verbose output from the issued command, it was passing: scp -v -f -- config I am not sure why the -- is needed in this command. I have attached a patch for scp.c to fix this functionality in the event anyone else runs into this. -------------- next part -------------- A non-text attachment was scrubbed... Name: scp.patch Type: text/x-diff Size: 1272 bytes Desc: not available URL: From des at des.no Sun Nov 13 23:49:20 2011 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sun, 13 Nov 2011 13:49:20 +0100 Subject: SCP fails to locate remote file: '-- ' In-Reply-To: <20111111105755.58236tyd6061d89f@angrystatic.com> (mike mackintosh's message of "Fri, 11 Nov 2011 10:57:55 -0600") References: <20111111105755.58236tyd6061d89f@angrystatic.com> Message-ID: <867h34tcfj.fsf@ds4.des.no> mike.mackintosh at angrystatic.com writes: > I am not sure if many people have run into this, but recently working > with some non-standard SSH capable devices, Routers, Firewalls and > Switches, I noticed SCP failed on many of them. Looking through logs I > saw: > > SCP unable to find file: '-- config' > > When looking through the verbose output from the issued command, it > was passing: > > scp -v -f -- config > > I am not sure why the -- is needed in this command. Because the filename might begin with a dash, and -- tells getopt to stop parsing options. This is a bug in the router / firewall / switch, not in OpenSSH. DES -- Dag-Erling Sm?rgrav - des at des.no From dtucker at zip.com.au Mon Nov 14 11:37:03 2011 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 14 Nov 2011 11:37:03 +1100 Subject: SCP fails to locate remote file: '-- ' In-Reply-To: <867h34tcfj.fsf@ds4.des.no> References: <20111111105755.58236tyd6061d89f@angrystatic.com> <867h34tcfj.fsf@ds4.des.no> Message-ID: <4EC062AF.8080200@zip.com.au> On 13/11/11 11:49 PM, Dag-Erling Sm?rgrav wrote: > mike.mackintosh at angrystatic.com writes: [...] >> scp -v -f -- config >> >> I am not sure why the -- is needed in this command. > > Because the filename might begin with a dash, and -- tells getopt to > stop parsing options. > > This is a bug in the router / firewall / switch, not in OpenSSH. True, but sadly common. Damien added some code to try to work around it where possible[1] but it's not made it into a release yet. Mike: please try a snapshot from http://www.mindrot.org/openssh_snap/ and let us know if it works or not. [1] http://anoncvs.mindrot.org/index.cgi/openssh/scp.c?revision=1.189 http://anoncvs.mindrot.org/index.cgi/openssh/scp.c?r1=1.188&r2=1.189 -- 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 carson at taltos.org Mon Nov 14 15:28:20 2011 From: carson at taltos.org (Carson Gaspar) Date: Sun, 13 Nov 2011 20:28:20 -0800 Subject: SCP fails to locate remote file: '-- ' In-Reply-To: <4EC062AF.8080200@zip.com.au> References: <20111111105755.58236tyd6061d89f@angrystatic.com> <867h34tcfj.fsf@ds4.des.no> <4EC062AF.8080200@zip.com.au> Message-ID: <4EC098E4.4070008@taltos.org> On 11/13/2011 4:37 PM, Darren Tucker wrote: > On 13/11/11 11:49 PM, Dag-Erling Sm?rgrav wrote: >> mike.mackintosh at angrystatic.com writes: > [...] >>> scp -v -f -- config >>> >>> I am not sure why the -- is needed in this command. >> >> Because the filename might begin with a dash, and -- tells getopt to >> stop parsing options. >> >> This is a bug in the router / firewall / switch, not in OpenSSH. > > True, but sadly common. Damien added some code to try to work around it > where possible[1] but it's not made it into a release yet. > > Mike: please try a snapshot from http://www.mindrot.org/openssh_snap/ > and let us know if it works or not. > > [1] http://anoncvs.mindrot.org/index.cgi/openssh/scp.c?revision=1.189 > http://anoncvs.mindrot.org/index.cgi/openssh/scp.c?r1=1.188&r2=1.189 An alternative to prepending '-- ' is prepending './' instead. But I have no idea how a windows-based implementation would handle that... -- Carson From Paul-Ebermann at gmx.de Tue Nov 15 04:40:43 2011 From: Paul-Ebermann at gmx.de (Paul Ebermann) Date: Mon, 14 Nov 2011 18:40:43 +0100 Subject: Is there a documentation of the key file formats? Message-ID: <4EC1529B.3070506@gmx.de> Hello, part of a usual OpenSSH installation are quite some files containing key material, like private keys (id_rsa, id_dsa, id_ecdsa) and the corresponding public keys (id_rsa.pub, id_dsa.pub, id_ecdsa.pub). Inspired by a recent question on Stack Overflow [1], I had a look at the OpenSSH documentation to see what format these key files have. The sshd man page [2] contains some paragraphs about the authorized_keys file, but it says (for the case interesting me) only: Protocol 2 public key consist of: options, keytype, base64-encoded key, comment. Without any details on how the keys (for the different available types) are actually encoded. The known_hosts file format description (which should actually be in the documentation for the client, not the daemon, I think) actually doesn't say anything about protocol 2 keys: Each line in these files contains the following fields: markers (optional), hostnames, bits, exponent, modulus, comment. The fields are separated by spaces. This doesn't match the format in my ~/.ssh/known_hosts file at all (other than the hostnames). There is also no explanation on how the hashed format works. I didn't find anything about the format of the private key files, yet there are other tools which manage to use them (PuTTY has a converter, JSch can use them for authentication). So, my question: Is there any specification of the format of these files, other than reading the OpenSSH source code which reads and writes these files? Thanks Pa?lo [1] "What are the key file formats of JSch and sharpSSH?" http://stackoverflow.com/q/8114903/600500 [2] http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 From aris at 0xbadc0de.be Wed Nov 16 23:08:23 2011 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Wed, 16 Nov 2011 13:08:23 +0100 Subject: Is there a documentation of the key file formats? In-Reply-To: <4EC1529B.3070506@gmx.de> References: <4EC1529B.3070506@gmx.de> Message-ID: <4EC3A7B7.3020103@0xbadc0de.be> Hi, This is described in RFC 4716 (https://www.ietf.org/rfc/rfc4716.txt ) This is basically PEM + a few custom extensions. Aris Le 14/11/11 18:40, Paul Ebermann a ?crit : > Hello, > > part of a usual OpenSSH installation are quite some files containing key material, > like private keys (id_rsa, id_dsa, id_ecdsa) and the corresponding public keys > (id_rsa.pub, id_dsa.pub, id_ecdsa.pub). > > Inspired by a recent question on Stack Overflow [1], I had a look at the > OpenSSH documentation to see what format these key files have. > > The sshd man page [2] contains some paragraphs about the authorized_keys file, > but it says (for the case interesting me) only: > > Protocol 2 public key consist of: options, keytype, base64-encoded key, > comment. > > Without any details on how the keys (for the different available types) are > actually encoded. > > The known_hosts file format description (which should actually be in the > documentation for the client, not the daemon, I think) actually doesn't say > anything about protocol 2 keys: > > Each line in these files contains the following fields: markers > (optional), hostnames, bits, exponent, modulus, comment. The fields are > separated by spaces. > > This doesn't match the format in my ~/.ssh/known_hosts file at all (other > than the hostnames). There is also no explanation on how the hashed format > works. > > I didn't find anything about the format of the private key files, yet there > are other tools which manage to use them (PuTTY has a converter, JSch can > use them for authentication). > > So, my question: Is there any specification of the format of these files, > other than reading the OpenSSH source code which reads and writes these > files? > > > Thanks > Pa?lo > > > [1] "What are the key file formats of JSch and sharpSSH?" > http://stackoverflow.com/q/8114903/600500 > [2] http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&sektion=8 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Paul-Ebermann at gmx.de Fri Nov 18 13:41:17 2011 From: Paul-Ebermann at gmx.de (Paul Ebermann) Date: Fri, 18 Nov 2011 03:41:17 +0100 Subject: Is there a documentation of the key file formats? In-Reply-To: <4EC3A7B7.3020103@0xbadc0de.be> References: <4EC1529B.3070506@gmx.de> <4EC3A7B7.3020103@0xbadc0de.be> Message-ID: <4EC5C5CD.2070404@gmx.de> Thanks for the answer, and sorry for replying only now. Aris Adamantiadis skribis: > This is described in RFC 4716 (https://www.ietf.org/rfc/rfc4716.txt ) > This is basically PEM + a few custom extensions. Sorry, but no. RFC 4716 defines a format for public keys which looks like this (copied from the RFC, page 6): ---- BEGIN SSH2 PUBLIC KEY ---- Subject: me Comment: 1024-bit rsa, created by me at example.com Mon Jan 15 \ 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- My id_rsa.pub looks like this (in one line): ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA07kVI7xHv7sVvUH+f8KXTxfP4mFNC0 etjAh8ArbyX8D5sMsXAshEw1RBw2v2U+r4GebB0IOyA+G8zTcIXPm2yUp3mhrp1c/t ldLocKV0KftW4tp7Umk47l5AVgA7VB7tBdDvUNbo4A8lHYk+nPf4RePwJBTjUS5WBP dTQIVMEGT1WVyZ9Sei+pAbr95uiREhNZOCMsqMO1rSHbemlrOtkGoLSyU/Qsxi9H99 lYT/86RZqI3PGK6qEpSHB22ywkpdZ8q7owejQzySX5qHGJl4g8Z8JB3eC96BT+ay11 UCGPyXNpBYYS/7a2eGZkZBYun7UcWxKEYzoiFkQxFU4XX9gQ== paulo at heribert This is obviously not the same format (and I think this is intentional, so the authorized_keys and known_hosts files can have one key per line). RFC 4716 defines the format used by SSH Inc's implementation, and is supported by ssh-keygen's import/export options (-i / -o), but it is not the same format as the one used internally in the .pub files. Still, at least the actual base64 data of the public keys looks similar (both start with AAAAB3NzaC1yc2EAAAAB), thus I assume they are using the same internal format. RFC 4716 refers to the RFC 4253 (SSH Transport Layer protocol), section 6.6, for the format of this base64-encoded part, which actually defines how the public key is transmitted in binary form in the protocol, as a sequence of: - the string "ssh-rsa", - a multiprecision integer e (encryption exponent), - a multiprecision integer n (modulus). (Both strings and MP integers are prefixed with a 32-bit (4 byte) value indicating the length of the following byte sequence in bytes. AAAAB3NzaC1yc2EA just decodes to 0x00000007 + "ssh-rsa" + the first zero byte of the prefix to e.) I think this fact (that this is simply the public key as defined in the SSH protocol (RFC 4253), base64-encoded) should be somewhere documented (if it isn't already). (I can write a patch if someone has a proposal in which file this should go.) The private key file id_rsa looks like this: -----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEAx4YpszY1+d+jEdIvvCLLumgDYmLy95SIqzeS1SV+ggUUn9u+ [... 22 more lines like these ...] Mv5Y4J3hWBkk+NfD6yzHPFaHfaWXFTlELfN3vZXAEYFIKzKhLrR7DG6rg7qUk/s2 eIh8COO5+h8mnyP/MRV9ceYmvmNs8R5Ng6Lmfi/owXIdbIQafuuUIA== -----END RSA PRIVATE KEY----- (No, this is not my real key, but a dummy one I just generated.) The RSA standard (PKCS#1) defines in appendix A.1.2 an ASN.1 representation of RSA private keys, so I could guess that this is some encoding (DER, CER, PER?) of this, wrapped in Base64. It could be something else, I didn't yet try to parse it (or look at the source). (It looks a bit strange that the private key has about 8 times the size of the public one, though.) Any hints? Pa?lo From rbyshko at gmail.com Sat Nov 19 05:02:57 2011 From: rbyshko at gmail.com (Roman B.) Date: Fri, 18 Nov 2011 19:02:57 +0100 Subject: Wrong permissions for $HOME Message-ID: Hi, today me and a friend of mine spent several hours figuring out why ssh still asked for a password after we set up public key authentication. We have tried to understand the problem by reading 'ssh -vvv ...', but unfortunately the output was not useful. In the end of the day we have found out that sshd actually was logging this problem.... So that's for the context. Now, can you please add some debugging information to ssh, so that the user is able to understand the problem by reading ssh -vvv which will be much mor helpful in comparison to sshd logging. Is there any reason you haven't done so already? Thanks Roman From dkg at fifthhorseman.net Sat Nov 19 05:11:21 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 18 Nov 2011 13:11:21 -0500 Subject: Wrong permissions for $HOME In-Reply-To: References: Message-ID: <4EC69FC9.5060208@fifthhorseman.net> On 11/18/2011 01:02 PM, Roman B. wrote: > Now, can you please add some debugging information to ssh, so that the > user is able to understand the problem by reading ssh -vvv which will > be much mor helpful in comparison to sshd logging. Is there any reason > you haven't done so already? the ssh client actually doesn't know what the problem is unless the server tells it. It's generally a bad idea for the server to publish that sort of detailed error message, especially when authentication has failed; this would be equivalent to publishing information about the user's home directory to anyone who asks. If the problem is on the server side, you'll need to read the server side logs to diagnose it, sorry! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From mloftis at wgops.com Sat Nov 19 05:13:21 2011 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 18 Nov 2011 11:13:21 -0700 Subject: Wrong permissions for $HOME In-Reply-To: References: Message-ID: On Fri, Nov 18, 2011 at 11:02 AM, Roman B. wrote: > Hi, > > today me and a friend of mine spent several hours figuring out why ssh > still asked for a password after we set up public key authentication. > We have tried to understand the problem by reading 'ssh -vvv ...', but > unfortunately the output was not useful. In the end of the day we have > found out that sshd actually was logging this problem.... So that's > for the context. > > Now, can you please add some debugging information to ssh, so that the > user is able to understand the problem by reading ssh -vvv which will > be much mor helpful in comparison to sshd logging. Is there any reason > you haven't done so already? Security mostly, also the fact that the error isn't on the client's side anyway, it's server side. The administrator would be able to find the error quickly, it's not user-solveable anyway. In the case ofa personal machine, you're both, so your responsibility is to check your logs. If you expose server side errors to the client you also give attackers more information. In this sort of a case the failure is ideally identical to wrong password and user does not exist from the clients point of view. Thus an attacker can't gain any information from this route. Yes yes yes, sounds silly, but, every layer helps. It's only a small part of a security model. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From rbyshko at gmail.com Sat Nov 19 05:26:59 2011 From: rbyshko at gmail.com (Roman B.) Date: Fri, 18 Nov 2011 19:26:59 +0100 Subject: Wrong permissions for $HOME In-Reply-To: References: Message-ID: Thank you guys for a quick answer! I suspected this motivation. There is one small case here when attacker still gets some information. If attacker has stolen valid key, then trying to log in with this key will give him either a shell or the information that user directory or .ssh is writable (if we assume there was no other problem), but I agree this is not a big deal anymore, after attacker has a valid key. On Fri, Nov 18, 2011 at 19:13, Michael Loftis wrote: > On Fri, Nov 18, 2011 at 11:02 AM, Roman B. wrote: >> Hi, >> >> today me and a friend of mine spent several hours figuring out why ssh >> still asked for a password after we set up public key authentication. >> We have tried to understand the problem by reading 'ssh -vvv ...', but >> unfortunately the output was not useful. In the end of the day we have >> found out that sshd actually was logging this problem.... So that's >> for the context. >> >> Now, can you please add some debugging information to ssh, so that the >> user is able to understand the problem by reading ssh -vvv which will >> be much mor helpful in comparison to sshd logging. Is there any reason >> you haven't done so already? > > Security mostly, also the fact that the error isn't on the client's > side anyway, it's server side. ?The administrator would be able to > find the error quickly, it's not user-solveable anyway. ?In the case > ofa ?personal machine, you're both, so your responsibility is to check > your logs. > > If you expose server side errors to the client you also give attackers > more information. ?In this sort of a case the failure is ideally > identical to wrong password and user does not exist from the clients > point of view. ?Thus an attacker can't gain any information from this > route. ?Yes yes yes, sounds silly, but, every layer helps. ?It's only > a small part of a security model. > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > From des at des.no Sat Nov 19 07:05:07 2011 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 18 Nov 2011 21:05:07 +0100 Subject: Wrong permissions for $HOME In-Reply-To: (Roman B.'s message of "Fri, 18 Nov 2011 19:26:59 +0100") References: Message-ID: <86y5vdmc24.fsf@ds4.des.no> "Roman B." writes: > If attacker has stolen valid key, then trying to log in with this key > will give him either a shell or the information that user directory or > .ssh is writable (if we assume there was no other problem), Uh, no. The only thing the attacker knows is that public-key authentication with that particular key did not succeed. There are a number of reasons why it would fail: there might not be a valid authorized_keys file at all, there might be one but the key is not listed there, it might be listed but with restrictions (e.g. "from") which the client does not satisfy, etc. DES -- Dag-Erling Sm?rgrav - des at des.no From djm at mindrot.org Mon Nov 21 15:16:20 2011 From: djm at mindrot.org (Damien Miller) Date: Mon, 21 Nov 2011 15:16:20 +1100 (EST) Subject: list/bugzilla downtime Message-ID: Hi, The mailing lists and bugzilla are going to be down for a bit while I move the server to a new, better connected and cheaper to operate home. I'll ping once they are back up again. -d From djm at mindrot.org Mon Nov 28 10:23:58 2011 From: djm at mindrot.org (Damien Miller) Date: Mon, 28 Nov 2011 10:23:58 +1100 (EST) Subject: Server moved Message-ID: Hi, The server move was completed over the weekend. Please let me know if anything is broken. -d From des at des.no Mon Nov 28 15:49:36 2011 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon, 28 Nov 2011 05:49:36 +0100 Subject: user creation before authentication In-Reply-To: (=?utf-8?Q?=22G=C3=A1bor_Z=C3=B6ld=22's?= message of "Thu, 24 Nov 2011 15:58:19 +0100") References: <20111123172807.GE5573@linux124.nas.nasa.gov> Message-ID: <86zkfgetr3.fsf@ds4.des.no> G?bor Z?ld writes: > I added the following line to /etc/pam.d/sshd to retrieve account > information and I modified nsswitch too.(passwd: files ldap, group: > files ldap) > account required /usr/local/lib/pam_ldap.so The "account" service is not used to "retrieve account information". It is used after authentication has succeeded to determine whether the account is valid, whether a password change is required etc. PAM only provides authentication and authorization; NSS is responsible for identification. Greatly simplified, identification is "who is Joe Bloggs?", authentication is "can you prove that you're Joe Bloggs?" and authorization is "is Joe Bloggs allowed to do this?" The following article is a decent introduction to PAM: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/article.html DES -- Dag-Erling Sm?rgrav - des at des.no From imorgan at nas.nasa.gov Tue Nov 29 05:09:13 2011 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 28 Nov 2011 10:09:13 -0800 Subject: Server moved In-Reply-To: References: Message-ID: <20111128180913.GG5573@linux124.nas.nasa.gov> On Sun, Nov 27, 2011 at 17:23:58 -0600, Damien Miller wrote: > Hi, > > The server move was completed over the weekend. Please let me know if > anything is broken. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Hi Damien, Anonymous cvs access seems to have broken during the move; even after updating my known_hosts file. % cd ~/src/openssh/openssh % cvs up Permission denied (publickey). cvs [update aborted]: end of file from server (consult above messages if any) % -- Iain Morgan From ondrej.caletka at gmail.com Tue Nov 29 19:53:32 2011 From: ondrej.caletka at gmail.com (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Tue, 29 Nov 2011 09:53:32 +0100 Subject: ssh-keygen -r should support SSHFP records for ECDSA (or at least return non-zero error code on failure) In-Reply-To: <4ECA6E4D.3030101@fifthhorseman.net> References: <4ECA6E4D.3030101@fifthhorseman.net> Message-ID: <4ED49D8C.1020600@gmail.com> FYI, there is a patch for linux port of OpenSSH to support draft-os-ietf-sshfp-ecdsa-sha2-02 https://github.com/oskar456/ietf/raw/master/ssh-sshfp-ecdsa.patch This patch is created against OpenSSH 5.8p1, but can be applied, after minor adjustments, even to latest snapshot openssh-SNAP-2011112, or non-portable version of OpenSSH. There is only one potential problem - if server offers a certificate and key embedded in certificate match a SSHFP record, host is considered authenticated without considering certificate. Maybe better would be to do all checks with certificate first and then continue on all checks with embedded key alone. But this would requre a major redesign of sshconnect.c. Also I think it would be nice to change default for option VerifyHostKeyDNS to ask. This setting should be always safe, regardless of local DNS resolver trustworthy. Regards, Ondrej Caletka Dne 21.11.2011 16:29, Daniel Kahn Gillmor napsal(a): > hi folks: > > it looks like ssh-keygen -r can't export SSHFP records for ECDSA keys: > > 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P '' > 0 dkg at pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub > export_dns_rr: unsupported algorithm > 0 dkg at pip:/tmp/cdtemp.oiRYAS$ > > the first number in my prompt is the return code of the last command; > note that ssh-keygen -r fails to produce an SSHFP DNS RR, but it returns 0. > > at the least, it should return non-zero on failure. > > > I note that the relevant RFC doesn't include an enumeration for ECDSA: > > https://tools.ietf.org/html/rfc4255#section-3.1.1 > > Could anyone on this list kick off the IETF process for allocating a new > ID in that registry for ECDSA? I'm not currently involved in the IETF's > Network Working Group so i don't really know the political landscape there. > > Regards, > > --dkg > > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4471 bytes Desc: Elektronick?? podpis S/MIME URL: From djm at mindrot.org Tue Nov 29 21:27:31 2011 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Nov 2011 21:27:31 +1100 (EST) Subject: Server moved In-Reply-To: <20111128180913.GG5573@linux124.nas.nasa.gov> References: <20111128180913.GG5573@linux124.nas.nasa.gov> Message-ID: On Mon, 28 Nov 2011, Iain Morgan wrote: > Hi Damien, > > Anonymous cvs access seems to have broken during the move; even after > updating my known_hosts file. > > % cd ~/src/openssh/openssh > % cvs up > Permission denied (publickey). > cvs [update aborted]: end of file from server (consult above messages if > any) Thanks for letting me know - I'd forgot to update the ListenAddress in sshd_config for anoncvs :( -d