aboutsummaryrefslogtreecommitdiff
path: root/man/man4/factotum.4
blob: 02466fcfb1a0f0bac1abdd1095b30f90253112dc (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
.TH FACTOTUM 4
.SH NAME
factotum \- authentication agent
.SH SYNOPSIS
.B factotum
[
.B -DdkSun
] [
.B -a authaddr
] [
.B -s
.I srvname
]
.\" [
.\" .B -m
.\" .I mtpt
.\" ]
.PP
.B factotum
.B -g
.IB attribute = value
.B ...
.IB attribute ?
.B ...
.\" .PP
.\" .B auth/fgui
.SH DESCRIPTION
.I Factotum
is a user-level file system that
acts as the authentication agent for a user.
It does so by managing a set of
.IR keys .
A key is a collection of information used to authenticate a particular action.
Stored as a list of
.IB attribute = value
pairs, a key typically contains a user, an authentication domain, a protocol, and
some secret data.
.PP
.I Factotum
presents the following files:
.TF needkey
.TP
.B rpc
each open represents a new private channel to
.I factotum
.TP
.B proto
when read lists the protocols available
.TP
.B confirm
for confiming the use of key
.TP
.B needkey
allows external programs to control the addition of new keys
.TP
.B log
a log of actions
.TP
.B ctl
for maintaining keys; when read, it returns a list of keys.
For secret attributes, only the attribute name follow by a
.L ?
is returned.
.PD
.PP
In any authentication, the caller typically acts as a client
and the callee as a server.  The server determines
the authentication domain, sometimes after a negotiation with
the client.  Authentication always requires the client to
prove its identity to the server.  Under some protocols, the
authentication is mutual.
Proof is accomplished using secret information kept by factotum
in conjunction with a cryptographic protocol.
.PP
.I Factotum
can act in the role of client for any process possessing the
same user id as it.  For select protocols such as
.B p9sk1
it can also act as a client for other processes provided
its user id may speak for the other process' user id (see
Plan 9's
.IR authsrv (6)).
.I Factotum
can act in the role of server for any process.
.PP
.IR Factotum 's
structure is independent of
any particular authentication protocol.
.I Factotum
supports the following protocols:
.TF mschap
.TP
.B p9any
a metaprotocol used to negotiate which actual protocol to use.
.TP
.B p9sk1
a Plan 9 shared key protocol.
.TP
.B p9sk2
a variant of
.B p9sk1.
.TP
.B p9cr
a Plan 9 protocol that can use either
.B p9sk1
keys or SecureID tokens.
.TP
.B apop
the challenge/response protocol used by POP3 mail servers.
.TP
.B cram
the challenge/response protocol also used by POP3 mail servers.
.TP
.B chap
the challenge/response protocols used by PPP and PPTP.
.TP
.B dsa
DSA signatures, used by SSH
.TP
.B mschap
a proprietary Microsoft protocol also used by PPP and PPTP.
.TP
.B rsa
RSA encryption and signatures, used by SSH and TLS.
.TP
.B pass
passwords in the clear.
.TP
.B vnc
.MR vnc (1) 's
challenge/response.
.TP
.B wep
WEP passwords for wireless ethernet cards.
.PD
The ``Protocols'' section below describes these protocols in more detail.
.PP
The options to
.I factotum
are:
.TP
.B \-a
supplies the address of the authentication server to use.
Without this option, it will attempt to find an authentication server by
querying the connection server, the file
.BR <mtpt>/ndb ,
and finally the network database in
.BR /lib/ndb .
.TP
.B \-m
specifies the mount point to use, by default
.BR /mnt .
.TP
.B \-s
specifies the service name to use.
Without this option,
.I factotum
does not create a service file in
.BR /srv .
.TP
.B \-D
turns on 9P tracing, written to standard error.
.TP
.B \-d
turns on debugging, written to standard error.
.TP
.B \-g
causes the agent to prompt for the key, write it
to the
.B ctl
file, and exit.
The agent will prompt for values for any of the
attributes ending with a question mark
.RB ( ? )
and will append all the supplied
.I attribute = value
pairs.  See the section on key templates below.
.TP
.B \-n
don't look for a secstore.
.TP
.B \-S
indicates that the agent is running on a
cpu server.  On starting, it will attempt to get a
.B 9psk1
key from NVRAM using
.B readnvram
(see
.MR authsrv (3) ),
prompting for anything it needs.
It will never subsequently prompt for a
key that it doesn't have.
This option is typically used by
the kernel at boot time.
.TP
.B \-k
causes the NVRAM to be written.
It is only valid with the
.B \-S
option.
This option is typically used by
the kernel at boot time.
.TP
.B \-u
causes the agent to prompt for user
id and writes it to
.BR /dev/hostowner .
It is mutually exclusive with
.B \-k
and
.BR \-S .
This option is typically used by
the kernel at boot time.
.PD
.\" .PP
.\" .I Fgui
.\" is a graphic user interface for confirming key usage and
.\" entering new keys.  It hides the window in which it starts
.\" and waits reading requests from
.\" .B confirm
.\" and
.\" .BR needkey .
.\" For each requests, it unhides itself and waits for
.\" user input.
.\" See the sections on key confirmation and key prompting below.
.SS "Key Tuples
.PP
A
.I "key tuple
is a space delimited list of
.IB attribute = value
pairs.  An attribute whose name begins with an exclamation point
.RB ( ! )
does not appear when reading the
.B ctl
file.
Here are some examples:
.EX
    proto=p9sk1 dom=avayalabs.com user=presotto !password=lucent
    proto=apop server=mit.edu user=rsc !password=nerdsRus
    proto=pass user=tb service=ssh !password=does.it.matter
.EE
The ``Protocols'' section below describes the attributes
specific to each supported protocol.
.PP
All keys can have additional attibutes that act either as comments
or as selectors to distinguish them in the
.MR auth (3)
library calls.
.PP
The factotum owner can use any key stored by factotum.
Any key may have one or more
.B owner
attributes listing the users who can use the key
as though they were the owner.
For example, the TLS and SSH host keys on a server
often have an attribute
.B owner=*
to allow any user (and in particular,
.L none )
to run the TLS or SSH server-side protocol.
.PP
Any key may have a
.B role
attribute for restricting how it can be used.
If this attribute is missing, the key can be used in any role.
Common values are:
.TP
.B client
for authenticating outbound calls
.TP
.B server
for authenticating inbound calls
.TP
.B speaksfor
for authenticating processes whose
user id does not match
.IR factotum 's.
.TP
.B encrypt
for encrypting data
.TP
.B decrypt
for decrypting data
.TP
.B sign
for cryptographically signing data
.TP
.B verify
for verifying cryptographic signatures
.PD
.PP
Whenever
.I factotum
runs as a server, it must have a
.B p9sk1
key in order to communicate with the authentication
server for validating passwords and challenge/responses of
other users.
.SS "Key Templates
Key templates are used by routines that interface to
.I factotum
such as
.B auth_proxy
and
.B auth_challenge
(see
.MR auth (3) )
to specify which key and protocol to use for an authentication.
Like a key tuple, a key template is also a list of
.IB attribute = value
pairs.
It must specify at least the protocol and enough
other attributes to uniquely identify a key, or set of keys, to use.
The keys chosen are those that match all the attributes specified
in the template.  The possible attribute/value formats are:
.TP 1i
.IB attr = val
The attribute
.I attr
must exist in the key and its value must exactly
match
.I val
.TP 1i
.IB attr ?
The attribute
.I attr
must exist in the key but its value doesn't matter.
.TP 1i
.I attr
The attribute
.I attr
must exist in the key with a null value
.PD
.PP
Key templates are also used by factotum to request a key either via
an RPC error or via the
.B needkey
interface.
The possible attribute/value formats are:
.TP 1i
.IB attr = val
This pair must remain unchanged
.TP 1i
.IB attr ?
This attribute needs a value
.TP 1i
.I attr
The pair must remain unchanged
.PD
.SS "Control and Key Management
.PP
A number of messages can be written to the control file.
The mesages are:
.TP
.B "key \fIattribute-value-list\fP
add a new key.  This will replace any old key whose
public, i.e. non ! attributes, match.
.TP
.B "delkey \fIattribute-value-list\fP
delete a key whose attributes match those given.
.TP
.B debug
toggle debugging on and off, i.e., the debugging also
turned on by the
.B \-d
option.
.PP
By default when factotum starts it looks for a
.MR secstore (1)
account on $auth for the user and, if one exists,
prompts for a secstore password in order to fetch
the file
.IR factotum ,
which should contain control file commands.
An example would be
.EX
  key dom=x.com proto=p9sk1 user=boyd !hex=26E522ADE2BBB2A229
  key proto=rsa service=ssh size=1024 ek=3B !dk=...
.EE
where the first line sets a password for
challenge/response authentication, strong against dictionary
attack by being a long random string, and the second line
sets a public/private keypair for ssh authentication,
generated by
.B ssh_genkey
(see
.MR ssh (1) ).
.PD
.SS "Confirming key use
.PP
The
.B confirm
file provides a connection from
.I factotum
to a confirmation server, normally the program
.IR auth/fgui .
Whenever a key with the
.B confirm
attribute is used,
.I factotum
requires confirmation of its use.  If no process has
.B confirm
opened, use of the key will be denied.
However, if the file is opened a request can be read from it
with the following format:
.PP
.B confirm
.BI tag= tagno
.I "<key template>
.PP
The reply, written back to
.BR confirm ,
consists of string:
.PP
.BI tag= tagno
.BI answer= xxx
.PP
If
.I xxx
is the string
.B yes
then the use is confirmed and the authentication will proceed.
Otherwise, it fails.
.PP
.B Confirm
is exclusive open and can only be opened by a process with
the same user id as
.IR factotum .
.SS "Prompting for keys
.PP
The
.B needkey
file provides a connection from
.I factotum
to a key server, normally the program
.IR auth/fgui .
Whenever
.I factotum
needs a new key, it first checks to see if
.B needkey
is opened.  If it isn't, it returns a error to its client.
If the file is opened a request can be read from it
with the following format:
.PP
.B needkey
.BI tag= tagno
.I "<key template>
.PP
It is up to the reader to then query the user for any missing fields,
write the key tuple into the
.B ctl
file, and then reply by writing into the
.B needkey
file the string:
.PP
.BI tag= tagno
.PP
.B Needkey
is exclusive open and can only be opened by a process with
the same user id as
.IR factotum .
.SS "The RPC Protocol
Authentication is performed by
.IP 1)
opening
.BR rpc
.IP 2)
setting up the protocol and key to be used (see the
.B start
RPC below),
.IP 3)
shuttling messages back and forth between
.IR factotum
and the other party (see the
.B read
and
.B write
RPC's) until done
.IP 4)
if successful, reading back an
.I AuthInfo
structure (see
.MR authsrv (3) ).
.PP
The RPC protocol is normally embodied by one of the
routines in
.MR auth (3) .
We describe it here should anyone want to extend
the library.
.PP
An RPC consists of writing a request message to
.B rpc
followed by reading a reply message back.
RPC's are strictly ordered; requests and replies of
different RPC's cannot be interleaved.
Messages consist of a verb, a single space, and data.
The data format depends on the verb.  The request verbs are:
.TP
.B "start \fIattribute-value-list\fP
start a new authentication.
.I Attribute-value-pair-list
must include a
.B proto
attribute, a
.B role
attribute with value
.B client
or
.BR server ,
and enough other attibutes to uniquely identify a key to use.
A
.B start
RPC is required before any others.    The possible replies are:
.RS
.TP
.B ok
start succeeded.
.TP
.B "error \fIstring\fP
where
.I string
is the reason.
.RE
.PD
.TP
.B read
get data from
.I factotum
to send to the other party.  The possible replies are:
.RS
.TP
.B ok
read succeeded, this is zero length message.
.TP
.B "ok \fIdata\fP
read succeeded, the data follows the space and is
unformatted.
.TP
.B "done
authentication has succeeded, no further RPC's are
necessary
.TP
.B "done haveai
authentication has succeeded, an
.B AuthInfo
structure (see
.MR auth (3) )
can be retrieved with an
.B authinfo
RPC
.TP
.B "phase \fIstring\fP
its not your turn to read, get some data from
the other party and return it with a write RPC.
.TP
.B "error \fIstring\fP
authentication failed,
.I string
is the reason.
.TP
.B "protocol not started
a
.B start
RPC needs to precede reads and writes
.TP
.B "needkey \fIattribute-value-list\fP
a key matching the argument is needed.  This argument
may be passed as an argument to
.I factotum
.B -g
in order to prompt for a key.  After that, the
authentication may proceed, i.e., the read restarted.
.PD
.RE
.TP
.B "write \fIdata\fP
send data from the other party to
.IR factotum .
The possible replies are:
.RS
.TP
.B "ok
the write succeeded
.TP
.B "needkey \fIattribute-value-list\fP
see above
.TP
.B "toosmall \fIn\fP
the write is too short, get more data from the
other party and retry the write.
.I n
specifies the maximun total number of bytes.
.TP
.B "phase \fIstring\fP
its not your turn to write, get some data from
.I factotum
first.
.TP
.B "done
see above
.TP
.B "done haveai
see above
.RE
.TP
.B readhex\fR, \fPwritehex
like
.B read
and
.BR write ,
except that an
.B ok
response to
.B readhex
returns the data encoded as
a long hexadecimal string,
and the argument to
.B writehex
is expected to be a long hexadecimal string.
These are useful for manually debugging of binary protocols.
.TP
.B authinfo
retrieve the AuthInfo structure.
The possible replies are:
.RS
.TP
.B "ok \fIdata\fP
.I data
is a marshaled form of the AuthInfo structure.
.TP
.B "error \fIstring\fP
where
.I string
is the reason for the error.
.PD
.RE
.TP
.B attr
retrieve the attributes used in the
.B start
RPC.
The possible replies are:
.RS
.TP
.B "ok \fIattribute-value-list\fP
.TP
.B "error \fIstring\fP
where
.I string
is the reason for the error.
.PD
.RE
.SS Protocols
Factotum supports many authentication types, each
with its own roles and required key attributes.
.PP
.IR P9any ,
.IR p9sk1 ,
.IR p9sk2 ,
and
.I p9cr
are used to authenticate to Plan 9 systems;
valid
.BR role s
are
.B client
and
.BR server .
All require
.B proto=p9sk1
keys with
.BR user ,
.B dom
(authentication domain),
and
.B !password
attributes.
.PP
.I P9sk1
and
.I p9sk2
are the Plan 9 shared-key authentication protocols.
.I P9sk2
is a deprecated form of
.I p9sk1
that neglects to authenticate the server.
.PP
.I P9any
is a meta-protocol that negotiates a protocol
.RB ( p9sk1
or
.BR p9sk2 )
and an authentication domain and then invokes the
given protocol with a
.B dom=
attribute.
.PP
.IR P9any ,
.IR p9sk1 ,
and
.I p9sk2
are intended to be proxied via
.I auth_proxy
(see
.MR auth (3) ).
.\" The protocols follow
.\" .IR p9any (7)
.\" and
.\" .IR p9sk1 (7).
.\" XXX - write about how server keys are selected and used
.\" XXX - write about protocol itself
.\" XXX - write about server ai
.PP
.I P9cr
is a textual challenge-response protocol;
roles are
.B client
and
.BR server .
It uses
.I p9sk1
keys as described above.
The protocol with
.I factotum
is textual:
client writes a user name,
server responds with a challenge,
client writes a response,
server responds with
.B ok
or
.BR bad .
Typically this information is wrapped in other protocols
before being sent over the network.
.PP
.I Vnc
is the challenge-response protocol used by
.MR vnc (1) ;
valid roles are
.B client
and
.BR server .
The client protocol requires a
.B proto=vnc
key with attribute
.BR !password .
Conventionally, client keys also have
.B user
and
.B server
attributes.
The server protocol requires a
.I p9sk1
key as described above.
The protocol with
.I factotum
is the same as
.IR p9cr ,
except that the challenge and response are not textual.
.PP
.I Apop
and
.I cram
are challenge-response protocols typically
used to authenticate
to mail servers.
The client protocols require
.B proto=apop
or
.B proto=cram
keys with
.B user
and
.B !password
attributes.
Conventionally, client keys also have
.B server
attributes.
The server protocol requires a
.I p9sk1
key as described above.
The protocol with
.I factotum
is textual:
server writes a challenge of the form
.IB random @ domain \fR,
client responds with user name
and then a hexadecimal response
(two separate writes),
and then the server responds with
.B ok
or
.BR bad .
.PP
.I Chap
and
.I mschap
are challenge-response protocols used in PPP sessions;
valid roles are
.B client
and
.BR server .
The client protocols require
.B proto=chap
or
.B proto=mschap
keys with
.B user
and
.B !password
attributes.
Conventionally, client keys also have
.B server
attributes.
The server protocol requires a
.I p9sk1
key as described above.
The protocol with factotum is:
server writes an 8-byte binary challenge,
client responds with user name
and then a
.B Chapreply
or
.B MSchapreply
structure (defined in
.B <auth.h> ).
.PP
.I Pass
is a client-only protocol that hands out passwords
from
.B proto=pass
keys with
.B user
and
.B !password
attributes.
The protocol is a single read that returns
a string: a space-separated quoted user name and password
that can be parsed with
.I tokenize
(see
.MR getfields (3) ).
Conventionally, client keys have distinguishing attributes
like
.B service
and
.B server
that can be specified in the
.B start
message to select a key.
.PP
.I Wep
is a client-only pseudo-protocol that initializes the encryption
key on a wireless ethernet device.
It uses
.B proto=wep
keys with
.BR !key1 ,
.BR !key2 ,
or
.B !key3
attributes.
The protocol with
.I factotum
is:
the client writes a device name
that must begin with
.LR #l .
In response,
.I factotum
opens the device's control file, sets the wireless secret using the key,
and turns on encryption.
If the key has an
.B essid
attribute,
.I factotum
uses it to set the wireless station ID.
.PP
.I Rsa
is an implementation of the RSA protocol.
Valid roles are
.BR decrypt ,
.BR encrypt ,
.BR sign ,
and
.BR verify .
.I Rsa
uses
.B proto=rsa
keys with
.B ek
and
.B n
attributes, large integers specifying the public half
of the key.
If a key is to be used for decryption or signing,
then it must also have attributes
.BR !p ,
.BR !q ,
.BR !kp ,
.BR !kq ,
.BR !c2 ,
and
.BR !dk
specifying the private half of the key;
see
.MR rsa (3) .
Conventionally,
.I rsa
keys also have
.B service
attributes specifying the context in which the key is used:
.B ssh
(SSH version 1),
.B ssh-rsa
(SSH version 2),
or
.B tls
(SSL and TLS).
If an SSH key has a
.B comment
attribute, that comment is presented to remote SSH servers
during key negotiation.
The protocol for
encryption (decryption) is:
write the message, then read back the encrypted (decrypted) form.
The protocol for signing is:
write a hash of the actual message,
then read back the signature.
The protocol for verifying a signature is:
write the message hash,
write the purported signature,
then read back
.B ok
or
.B bad
telling whether the signature could be verified.
The hash defaults to SHA1 but can be specified by a
.B hash
attribute on the key.
Valid hash functions are
.B md5
and
.BR sha1 .
The hash function must be known to
.I factotum
because the signature encodes the type of hash used.
The
.B encrypt
and
.B verify
operations are included as a convenience;
.I factotum
is not using any private information to perform them.
.PP
.I Dsa
is an implementation of the NIST digital signature algorithm.
Valid roles are
.B sign
and
.BR verify .
It uses
.B proto=dsa
keys with
.BR p ,
.BR q ,
.BR alpha ,
and
.B key
attributes.
If the key is to be used for signing, it must also have a
.B !secret
attribute; see
.MR dsa (3) .
Conventionally,
.I dsa
keys
also have
.B service
attributes specifying the context in which the key is used:
.B ssh-dss
(SSH version 2)
is the only one.
If an SSH key has a
.B comment
attribute, that comment is presented to SSH servers during
key negotiation.
The protocol for signing and verifying
is the same as the RSA protocol.
Unlike
.IR rsa ,
the
.I dsa
protocol ignores the
.B hash
attribute; it always uses SHA1.
.PP
.I Httpdigest
is a client-only MD5-based challenge-response protocol used in HTTP; see RFC 2617.
It uses
.B proto=httpdigest
keys with
.BR user ,
.BR realm ,
and
.BR !password
attributes.
The protocol with factotum is textual:
write the challenge, read the response.
The challenge is a string with three space-separated fields
.IR nonce ,
.IR method ,
and
.IR uri ,
parseable with
.IR tokenize .
The response is a hexadecimal string of length 32.
.SH SOURCE
.B \*9/src/cmd/auth/factotum
.SH SEE ALSO
.MR ssh-agent (1)